10-K

UNITED STATES SECURITIES AND EXCHANGE COMMISSION

Washington, D.C. 20549

Form 10-K

þ	ANNUAL REPORT PURSUANT TO SECTION 13 OR 15(d) OF THE SECURITIES EXCHANGE ACT OF 1934
	for the fiscal year ended December 31, 2005
Or
o	TRANSITION REPORT PURSUANT TO SECTION 13 OR 15(d) OF THE SECURITIES EXCHANGE ACT OF 1934
	for the transition period from           to

Commission File No. 001-32548

NeuStar, Inc.

(Exact name of registrant as specified in its charter)

Delaware	52-2141938
(State or other jurisdiction of	(I.R.S. Employer
incorporation or organization)	Identification No.)
46000 Center Oak Plaza	20166
Sterling, Virginia	(Zip Code)
(Address of principal executive offices)

(571) 434-5400

(Registrant’s telephone number, including area code)

Securities registered pursuant to Section 12(b) of the Act:

Title of Each Class	Name of Each Exchange on Which Registered
Class A Common Stock	New York Stock Exchange

Securities registered pursuant to Section 12(g) of the Act:

None

      Indicate by check mark if the registrant is a well-known seasoned issuer, as defined in Rule 405 of the Securities Act.     Yes o          No þ

      Indicate by check mark if the registrant is not required to file reports pursuant to Section 13 or Section 15(d) of the Act.     Yes o          No þ

      Indicate by check mark whether the registrant (1) has filed all reports required to be filed by Section 13 or 15(d) of the Securities Exchange Act of 1934 during the preceding 12 months (or for such shorter period that the registrant was required to file such reports), and (2) has been subject to such filing requirements for the past 90 days.     Yes þ          No o

      Indicate by check mark if disclosure of delinquent filers pursuant to Item 405 of Regulation S-K is not contained herein, and will not be contained, to the best of registrant’s knowledge, in definitive proxy or information statements incorporated by reference in Part III of this Form 10-K or any amendment to this Form 10-K     þ .

      Indicate by check mark whether the registrant is a large accelerated filer, an accelerated filer, or a non-accelerated filer. See definition of “accelerated filer and large accelerated filer” in Rule 12b-2 of the Exchange Act. (Check One):

Large accelerated filer o          Accelerated filer o          Non-accelerated filer þ .

      Indicate by check mark whether the registrant is a shell company (as defined in Rule 12b-2 of the Exchange Act).     Yes o          No þ

      On March 17, 2006, 71,078,245 shares of NeuStar Class A common stock were outstanding and 27,284 shares of NeuStar Class B common stock were outstanding. The aggregate market value of the NeuStar common equity held by non-affiliates as of June 30, 2005 was approximately $140.3 million.

      DOCUMENTS INCORPORATED BY REFERENCE:

      Information required by Part III (Items 10, 11, 12, 13 and 14) is incorporated by reference to portions of NeuStar’s definitive proxy statement for its 2006 Annual Meeting of Stockholders, which will be filed with the Securities and Exchange Commission within 120 days of December 31, 2005.

TABLE OF CONTENTS

Item	Description	Page
PART I
1.	Business		1
1A.	Risk Factors		15
1B.	Unresolved Staff Comments		25
2.	Properties		25
3.	Legal Proceedings		25
4.	Submission of Matters to a Vote of Security Holders		25
PART II
5.	Market for Registrant’s Common Equity, Related Stockholder Matters and Issuer Purchases of Equity Securities		25
6.	Selected Financial Data		27
7.	Management’s Discussion and Analysis of Financial Condition and Results of Operations		29
7A.	Quantitative and Qualitative Disclosures About Market Risk		44
8.	Financial Statements and Supplementary Data		45
9.	Changes in and Disagreements with Accountants on Accounting and Financial Disclosure		78
9A.	Controls and Procedures		78
9B.	Other Information		78
PART III
10.	Directors and Executive Officers of the Registrant		78
11.	Executive Compensation		78
12.	Security Ownership of Certain Beneficial Owners and Management and Related Stockholder Matters		79
13.	Certain Relationships and Related Transactions		79
14.	Principal Accounting Fees and Services		79
PART IV
15.	Exhibits, Financial Statement Schedule		79
Signatures			86

      Unless the context requires otherwise, references in this report to “NeuStar,” “we,” “us,” the “Company” and “our” refer to NeuStar, Inc. and its consolidated subsidiaries.

PART I

ITEM 1. BUSINESS.

Overview

      We provide the North American communications industry with essential clearinghouse services. Our customers use the databases we contractually maintain in our clearinghouse to obtain data required to successfully route calls in North America, to exchange information with other communications service providers and to manage technological changes in their own networks. We operate the authoritative directories that manage virtually all telephone area codes and numbers, and we enable the dynamic routing of calls among thousands of competing communications service providers, or CSPs, in the United States and Canada. All CSPs that offer telecommunications services to the public at large, or telecommunications service providers, such as Verizon Communications Inc., Sprint Nextel Corporation, AT&T Corp. and Cingular Wireless LLC, must access our clearinghouse as one of our customers to properly route virtually all of their customers’ calls. We also provide clearinghouse services to emerging CSPs, including Internet service providers, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, we manage the authoritative directories for the .us and .biz Internet domains, as well as for U.S. Common Short Codes, part of the short messaging service relied upon by the U.S. wireless industry.

      We provide our services from our clearinghouse, which includes unique databases and systems for workflow and transaction processing. Our customers access our clearinghouse databases through standard connections, which we believe is the most efficient and cost-effective way for CSPs to exchange operationally essential data in a secure environment that does not favor any particular customer or technology. In addition, we believe that our clearinghouse positions us well to meet the complex needs of the communications industry going forward. Today, our services allow our customers to manage competitive turnover of their customers, subscriber growth, technology change, network optimization, and industry consolidation. Furthermore, we believe our services are essential to the growth of new CSPs and new end-user services that will develop as the industry shifts from conventional circuit-switched communications to Internet protocol, or IP, and third generation wireless technology.

      We were founded to meet the technical and operational challenges of the communications industry when the U.S. government mandated local number portability in 1996. While we remain the provider of the authoritative solution that the communications industry relies upon to meet this mandate, we have developed a broad range of innovative services to meet an expanded range of customer needs. We provide the communications industry in North America with critical technology services that solve the addressing, interoperability and infrastructure needs of CSPs. These services are now used by CSPs to manage a range of their technical and operating requirements, including:

•  Addressing. We enable CSPs to use critical, shared addressing resources, such as telephone numbers, Internet top-level domain names, and U.S. Common Short Codes.

•  Interoperability. We enable CSPs to exchange and share critical operating data so that communications originating on one provider’s network can be delivered and received on the network of another CSP. We also facilitate order management and work flow processing among CSPs.

•  Infrastructure. We enable CSPs to more efficiently manage changes in their own networks by centrally managing certain critical data they use to route communications over their networks.

Company Information and History

      We were incorporated in Delaware in 1998 to acquire our business from Lockheed Martin Corporation. This acquisition was completed in November 1999. Our principal executive offices are located at 46000 Center Oak Plaza, Sterling, Virginia, 20166, and our telephone number at that address is (571) 434-5400.

      On June 28, 2005, we effected a recapitalization, which involved (i) payment of all accrued and unpaid dividends on all of the then-outstanding shares of preferred stock, followed by the conversion of all such shares into shares of common stock, (ii) the amendment of our certificate of incorporation to provide for Class A common stock and Class B common stock, and (iii) the split of each share of common stock into 1.4 shares and the reclassification of the common stock into shares of Class B common stock. We refer to these transactions collectively as the Recapitalization. Each share of Class B common stock is convertible at the option of the holder into one share of Class A common stock, and we anticipate that all holders of Class B common stock will ultimately convert their shares into shares of Class A common stock.

      On June 28, 2005, we made an initial public offering of 31,625,000 shares of Class A common stock, which included the underwriters’ over-allotment option exercise of 4,125,000 shares of Class A common stock. All the shares of Class A common stock sold in the initial public offering were sold by selling stockholders and, as such, we did not receive any proceeds from that offering. In December 2005, we completed an additional offering of 20,000,000 shares of Class A common stock, all of which were sold by selling stockholders. As such, we did not receive any proceeds from that offering.

Industry Background

      Changes in the structure of the communications industry over the past two decades have presented increasingly complex technical and operating challenges. Whereas the Bell Operating System once dominated the U.S. telecommunications industry, there are now thousands of service providers, all with disparate networks. Today these service providers must interconnect their networks and carry each other’s traffic to route phone calls, unlike in the past when a small number of incumbent wireline carriers used established, bilateral relationships. In addition, CSPs are delivering a broad set of new services using a diverse array of technologies. These services, which include voice, data and video, are used in combinations that are far more complex than the historical, uniform voice services of traditional carriers.

      The increasing complexity of the communications industry has produced operational challenges, as the legacy, in-house network management and back office systems of traditional carriers were not designed to capture all of the information necessary for provisioning, authorizing, routing and billing these new services. In particular, it has become significantly more difficult for service providers to:

•  Locate end-users. Identify the appropriate destination for a given communication among multiple networks and unique addresses, such as wireline and wireless phone numbers as well as IP and e-mail addresses;

•  Establish identity. Authenticate that the users of the communications networks are who they represent themselves to be and that they are authorized to use the services being provided;

•  Connect. Route the communication across disparate networks;

•  Provide services. Authorize and account for the exchange of communications traffic across multiple networks; and

•  Process transactions. Capture, process and clear accounting records for billing, and generate settlement data for inter-provider compensation.

Our Clearinghouse

      We provide our services through our clearinghouse, which has been designed to provide substantial advantages in meeting the challenges facing the communications industry for both traditional voice and IP networks. First, our clearinghouse databases and capabilities provide competing CSPs with fair, equal and

2

secure access to essential shared resources such as telephone numbers and domain names. This sharing of data is critical for locating end-users and establishing their identity. Second, our clearinghouse databases and capabilities serve as an authoritative directory to ensure proper routing of voice, advanced data applications and IP-based communications regardless of originating or terminating technologies. Third, CSPs access our clearinghouse through standard connections. Our clearinghouse also enables connections to authoritative operating data for CSPs and providers of other service elements, including content, entertainment and financial transactions. As a result, it facilitates advanced services, such as multi-media content services. Finally, our services facilitate the management of networks and services, including the deployment of new technologies and protocols, the balancing of communications traffic across a CSP’s internal networks, and network consolidation.

      To ensure our role as a provider of essential services to the North American communications industry, we designed our clearinghouse to be:

•  Reliable. Our clearinghouse services depend on complex technology that is designed to deliver reliability consistent with telecommunications industry standards. Under our contracts, we have committed to our customers to deliver high quality services across numerous measured and audited service levels, such as system availability, response times for help desk inquiries and billing accuracy, consistent with telecommunications industry standards.

•  Scalable. The modular design of our clearinghouse enables capacity expansion without service interruption, and with incremental investment that provides significant economies of scale.

•  Neutral. We provide our services in a competitively neutral way to ensure that no one telecommunications service provider, telecommunications industry segment or technology or group of telecommunications customers is favored over any other. Moreover, we have committed not to be a telecommunications service provider in competition with our customers.

•  Trusted. The data we collect are important and proprietary. Accordingly, we have appropriate procedures and systems to protect the privacy and security of customer data, restrict access to the system and generally protect the integrity of our clearinghouse. Our performance with respect to neutrality, privacy and security is independently audited regularly.

NeuStar Services

Addressing

      “Addresses” are a shared resource among CSPs. Each communications device must have a unique address so that communications can be routed properly to that device. With the development of new technologies, the number and type of addressing resources increase, and the advent of bundled services, such as voice plus text messaging, may require that multiple addresses be identified for what is intended to be a single, integrated communication to one or more devices used by a single user or a group of users.

      For communications to reliably reach the intended users, we believe that the communications industry requires a trusted, authoritative administrator of addressing directories to route communications. Moreover, we believe that CSPs must have fair access to shared addressing resources and must be able to access the administrator’s systems to ensure the proper routing of communications. We provide a range of addressing services to meet these needs, including:

•  Telephone Number Administration. As the North American Numbering Plan Administrator, we maintain the authoritative database of telephone numbering resources for North America. We allocate telephone numbers by geographic location and assign telephone numbers to telecommunications service providers. We administer area codes, including area code splits and overlays, and collect and forecast telephone number utilization rates by service providers. As the National Pooling Administrator, we also manage the administration of inventory and allocation of pooled blocks of unassigned telephone numbers by reassigning 1,000-number blocks of assigned but unused telephone numbers to telecommunications service providers requiring additional telephone numbers. We provide these

3

	services under fixed-fee annual and cost-plus contracts with the Federal Communications Commission, or FCC.
•	Telephone Number Pooling. In addition to the administrative functions associated with our role as the National Pooling Administrator, we also implement the administration of the allocation of pooled blocks of unassigned telephone numbers through our clearinghouse, including the reallocation of pooled blocks of telephone numbers to the consolidated network of consolidating carriers following a merger or other business combination. We are paid on a per transaction basis for this service.
•	Internet Domain Name Services.

•  .BIZ and .US Domains. We operate the authoritative registries of Internet domain names for the .biz and .us top level domains. All Internet communications routing to a .biz or .us address must query a copy of our directory to ensure that the communication is routed to the appropriate destination. We are paid on a subscription basis for each name in the registries, which together currently contain over two million registered domain names.

•  Registry Gateway Services. We are the exclusive provider of wholesale registration services to domain name retailers for the .cn (China) and .tw (Taiwan) Internet domains for all regions outside of the home countries. We are paid on a subscription basis for each name sold through the gateway.

•  U.S. Common Short Codes. We operate the authoritative U.S. Common Short Code registry on behalf of the leading wireless providers in the United States. A Common Short Code is a string of five or six numbers, which serves as the “address” for text messages that are sent from wireless devices to businesses or organizations on a many-to-one basis. U.S. Common Short Codes are often used to count votes using wireless devices in promotional marketing efforts, such as votes for sporting event MVPs, to register for contests, and even to download applications such as ring tones. We are paid on a subscription basis for each code in the registry.

Interoperability

      To provide communications across multiple networks involving multiple service providers, industry participants must exchange essential operating data. We believe that our clearinghouse is the most efficient, logistically practical and economical means for each CSP to exchange the large volumes of operating data that are required to deliver communications services between networks. Our services include:

•  Wireline and Wireless Number Portability. Our clearinghouse is the master, authoritative directory that allows end-users to change their telephone carrier without changing their telephone numbers. In addition, service providers use this service to change the network identification associated with their end users’ telephone numbers after a merger or consolidation. We have provided this service for wireline local number portability since 1997, and in 2003 we expanded our service to provide portability of telephone numbers between wireless telecommunications service providers and between wireline and wireless telecommunications service providers. We are paid on a per transaction basis for this service.

•  Order Management Services. We provide centralized clearinghouse services that permit our customers, through a single interface, to exchange essential operating data with multiple CSPs in order to provision services. We are typically paid on a per transaction basis for each order we process. For example:

•  Local Service Request. For a CSP to establish wireline local service to an end-consumer, it must access the wireline facility to that consumer’s location. Access is obtained through a local service request made to the CSP that controls the physical line to that consumer. Using our centralized clearinghouse, we have developed a series of services to facilitate this and similar types of order management needs, such as orders for high-capacity trunks and switching services.

•  Customer Account Record Exchange. Our clearinghouse services allow for the exchange of customer account records between competing local service providers and their interexchange carrier

4

trading partners. We are the largest clearinghouse provider for the exchange of customer account records in the communications industry. This record exchange service provides our customers with the necessary information to accurately bill and collect fees for services.

Infrastructure and Other

      Constant changes in the communications service industry require providers to make frequent and extensive changes in their own network infrastructure. Our infrastructure services are used by CSPs to efficiently reconfigure their networks and systems in response to changes in the market.

•  Network Management. Our customers use our clearinghouse to centrally process changes to essential network elements that are used to route telephone calls. We are paid on a per transaction basis for these services. Our network management services are used by our customers for a variety of different purposes, such as to replace and upgrade technologies, to balance network traffic and to reroute traffic on alternative networks in the event of a service disruption.

•  Connection Services. We provide standard connections for those CSPs that connect directly to our clearinghouse. We are paid an established fee based on the type of connection. CSPs both send and receive data through these connections.

•  Service Order Provisioning. We recently launched service order provisioning services that enable CSPs to manage their internal systems through an automated interface to our clearinghouse and other shared industry databases. This service eliminates the need for service providers to build and maintain their own internal service order provisioning system. We are paid on a per transaction basis for these services.

•  Public Safety and Security Services. Increasingly, CSPs are required to produce voluminous records and conduct clandestine electronic surveillance for public safety and homeland security. In the emerging IP environment, carrier obligations under the Communications Assistance for Law Enforcement Act of 1994, or CALEA, are challenging. Our services provide carriers with a single point of contact for all information and surveillance requests. We believe our services are the most efficient, logistically practical and economical way for service providers to manage their obligations under CALEA and other electronic surveillance laws. We are typically paid on a per transaction basis for these services.

Operations

Sales Force and Marketing

      As of December 31, 2005, our sales and marketing organization consisted of 94 people who work together to proactively deliver advanced technologies and solutions to serve our customers’ needs. Our sales teams work closely with our customers to identify and address their needs, while our marketing team works closely with our sales teams to deliver comprehensive services, develop a clear and consistent corporate image and offer a full customer support system.

      We have expert sales and marketing staff who offer knowledge and experience in the management of telephone numbers, number portability and IP clearinghouse services. We believe we have close relations with our customers, and we know their systems and operations. We have worked closely with our customers to develop solutions such as national pooling, U.S. Common Short Codes, number translation services, and the provisioning of service requests for VoIP providers. Our sales teams strive to increase the services purchased by existing customers and to expand the range of services we provide to our customers.

Customer Support

      Our customer support organization operates 24 hours a day, 7 days a week and 365 days a year. It is in charge of implementation of our service offerings from the point at which a contract is signed until the point at which our services are fully operational. Post-delivery, our staff works closely with our customers to ensure

5

that our service level agreements are being met. They continually solicit customer feedback and are in charge of bringing together the proper internal resources to troubleshoot any problems or issues that customers may have. Performance of the group is measured by customer satisfaction surveys as well by the group’s ability to limit service downtime.

Operational Capabilities

      We operate state-of-the-art data centers that support our clearinghouse services. Our data centers are custom designed for the processing and transmission of high volumes of transaction-related, time-sensitive data in a highly secure environment. We are committed to employing best-of-breed tools and equipment for application development, infrastructure management, operations management, and information security. These include equipment from International Business Machines Corporation, or IBM, Cisco Systems, Inc., Sun Microsystems, Inc., Dell Inc., and EMC Corporation, and database systems and software from Oracle Corporation and IBM. In each instance where we use a third-party vendor, we subscribe to the highest level of service and responsiveness available from that vendor. To protect the integrity of our systems, we utilize encryption and other security techniques that well exceed industry standards.

      We have configured the major components of our networks in a manner designed to eliminate any single point of failure. All of our data centers are equipped with uninterruptible power supplies and dedicated backup generators to ensure constant, uninterrupted power availability. Additionally, our data centers are located in different states and have state-of-the-art fire detection and suppression systems, and alarm monitoring of all vital operational parameters. Our data centers are interconnected with dedicated DS3 high-speed optical connections, which are provided by two separate service providers and are physically routed on diverse paths. Each data center is always “live” with real-time mirroring of databases to ensure no interruption of service in the case of an outage at one data center. Additionally, we provide multiple points of access for our customers. We have multiple DS3 connections from four distinct service providers for customers accessing our data center via the Internet. The reliability of our clearinghouse is enhanced significantly by these physical and logistical redundancies.

      Because our original mandate was to create a clearinghouse for use by telecommunications carriers, our network has been designed to meet carrier-grade performance standards since our inception. We consistently exceed our contractual service level requirements, and our performance results are monitored internally and subjected to independent audits on a regular basis for some of our services.

Research and Development

      Our first focus in research and development is to innovate. We understand our customers’ challenges in managing an expanding array of technologies and end-user services across a growing number of CSPs. We employ industry experts in areas of technology that we believe are key to solving these problems. We believe their work has had a profound impact on the communications industry. For instance, we led the industry effort to design the architecture that underlies local number portability, which today is necessary to route virtually all calls in North America.

      Our second focus in research and development is to promote open industry standards around innovative solutions that serve our customers’ needs. We are active in industry forums where our technical expertise and neutral position in the industry are valuable in promoting consensus among competing CSPs. We led the development of the Session Initiation Protocol (SIP) technology at the Internet Engineering Task Force. This technology has been adopted by most global industry communication groups, including wireline, wireless, and IP, as the standard for VoIP and other real-time multimedia transmission over IP, such as video, music, and multimedia conferencing, and other enhanced services.

      Once the standard has been adopted, our third focus is to develop the standards-based solution that can be delivered industry-wide as a service through our clearinghouse, yielding significant benefits both to the communications industry and us. The communications industry benefits from a uniform solution that can be delivered in a timely fashion in a cost-effective manner. We benefit by introducing new services that leverage our clearinghouse and expand the sources of our revenue. For example, in a collaborative effort with several of

6

the world’s largest Internet Exchange providers, we are currently in the development process for SIP-IX, the first comprehensive suite of services designed to enable direct network-to-network peering between trading partners for voice, video and content services using SIP-based technologies such as IP multimedia subsystem (IMS) and VoIP.

      As of December 31, 2005, we had 58 employees dedicated to research and development. We expense our research and development costs as incurred. Our research and development expense was $6.7 million, $7.4 million and $11.9 million for the years ended December 31, 2003, 2004 and 2005, respectively.

Customers

      We serve traditional providers of communications, including local exchange carriers, such as Verizon Communications Inc., AT&T, Inc. and BellSouth Corporation; competitive local exchange carriers, such as XO Communications, Inc. and Focal Communications Corporation; wireless service providers, such as Verizon Wireless Inc., Cingular Wireless LLC and Sprint Nextel Corporation; and long distance carriers. We also serve emerging CSPs, including Comcast Corporation, Time Warner Telecom Inc., Cox Communications, Inc. and Cbeyond Communications Inc., and fast-growing emerging providers of VoIP services, such as Vonage Holdings Corp. and SunRocket, Inc.

      In addition to serving CSPs, we also serve a growing number of customers who are either enablers of Internet services or providers of information and content to Internet and telephone users. All Internet service providers rely on our Internet registry service to route all communications to .biz and .us Internet addresses. Domain name registrars, including Network Solutions, Inc., The Go Daddy Group, Inc., and Register.com, pay us for each .biz and .us domain name they register on behalf of their customers. Wireless service providers rely on our registry to route all Common Short Code communications, but the bulk of our customers for U.S. Common Short Codes are the information and entertainment content providers who register codes with us to allow wireless subscribers to communicate with them via text messaging.

      Our customers include over 4,500 different entities, each of which is separately billed for the services we provide, regardless of whether it may be affiliated with one or more of our other customers. No single entity accounted for more than 10% of our total revenue in 2005. The amount of our revenue derived from customers inside the United States was $106.1 million, $159.8 million and $235.5 million for the years ended December 31, 2003, 2004 and 2005, respectively. The amount of our revenue derived from customers outside the United States was $5.6 million, $5.2 million and $7.0 million for the years ended December 31, 2003, 2004 and 2005, respectively. The amount of our revenue derived under our contracts with North American Portability Management LLC was $84.5 million, $130.0 million and $188.8 million for the years ended December 31, 2003, 2004 and 2005, respectively.

Competition

      Our services most frequently compete against the legacy in-house systems of our customers. We believe our services offer greater reliability and flexibility on a more cost-effective basis than these in-house systems.

      In our roles as the North American Numbering Plan Administrator, National Pooling Administrator, administrator of local number portability for the communications industry, operator of the sole authoritative registry for the .us and .biz Internet domain names, and operator of the sole authoritative registry for U.S. Common Short Codes, there are no other providers currently providing the services we offer. However, we were awarded the contracts to administer these services in open and competitive procurement processes where we competed against companies including Accenture Ltd, Computer Sciences Corporation, Hewlett-Packard Company, IBM, Intrado Inc., Mitretek Systems, Inc., Nortel Networks Corporation, Pearson NCS, Perot Systems Corporation, Telcordia Technologies, Inc. and VeriSign, Inc. We have renewed or extended the term of several of these contracts since we first entered into them. As the terms of these contracts expire, we expect that other companies may seek to bid on renewals or new contracts, and we may not be successful in renewing them. In addition, prior to the expiration of our contracts to provide number portability services, North American Portability Management LLC could solicit, or our competitors may submit, proposals to replace us, in whole or in part, as the provider of the services covered by these contracts. Similarly, with

7

respect to our contracts to act as the North American Number Plan Administrator, the National Pooling Administrator, operator of the authoritative registry for the .us and .biz Internet domain names, and the operator of the authoritative registry for U.S. Common Short Codes, the relevant counterparty could elect not to exercise the extension period under the contract, if applicable, or to terminate the contract in accordance with its terms, in which case we could be forced to compete with other providers to continue providing the services covered by the relevant contract. However, we believe that our position as the incumbent provider of these services will enable us to compete favorably for contract renewals or for new contracts to continue to provide these services.

      While we do not face direct competition for the registry of .us and .biz Internet domain names, we compete with other companies that maintain the registries for different domain names, including Afilias Limited, which manages the .org and .info registries, VeriSign, Inc., which manages the .com and .net registries, and a number of managers of country-specific domain name registries (such as .uk for domain names in the United Kingdom).

      For the remainder of our services, we compete against a range of providers of interoperability and infrastructure services and/or software, as well as the in-house network management and information technology organizations of our customers. Our competitors, other than in-house network systems, generally fall into three categories:

•  companies that develop and sell software solutions to CSPs, such as Evolving Systems, Inc., MetaSolv, Inc. and NetCracker Technology;

•  systems integrators such as Accenture Ltd, Electronic Data Systems Corporation, Hewlett-Packard Company, IBM, Oracle Corporation and Perot Systems Corporation, which develop customized solutions for CSPs and in some cases operate and manage certain back-office systems for CSPs on an outsourced basis; and

•  companies such as CGI Group Inc., Synchronoss Technologies, Inc., Syniverse Technologies, Inc., Telcordia Technologies, Inc. VeriSign, Inc. and Wisor Corporation, which offer communications interoperability services, including inter-CSP order processing and workflow management on an outsourced basis.

      We believe our clearinghouse has inherent advantages relative to discrete software solutions that require sales, customization and ongoing maintenance for CSPs on a one-customer-at-a-time basis. Many companies that have developed discrete software solutions have lacked the scale and financial resources necessary to develop carrier-grade solutions and achieve sufficiently broad customer acceptance to create viable business models. We also believe that our one-to-many clearinghouse can offer more economical services than in-house solutions or outsourcing to a systems integrator. However, many of our current and potential competitors have the financial, technical, marketing and other resources to develop a clearinghouse and compete with us directly with similar services and a similar delivery model.

      Competitive factors in the market for our services include breadth and quality of services offered, reliability, security, cost-efficiency, and customer support. Our ability to compete successfully depends on numerous factors, both within and outside our control, including:

•  our responsiveness to customers’ needs;

•  our ability to support existing and new industry standards and protocols;

•  our ability to continue development of technical innovations; and

•  the quality, reliability, security and price-competitiveness of our services.

      We may not be able to compete successfully against current or future competitors and competitive pressures that we face may materially adversely affect our business. The market for clearinghouse services may not continue to develop, and CSPs may not continue to use clearinghouse services rather than in-house systems and purchased or internally-developed software.

8

Employees

      As of December 31, 2005, we employed 502 persons worldwide. None of our employees is currently represented by a labor union. We have not experienced any work stoppages and consider our relationship with our employees to be good.

Contracts

      We provide many of our addressing, interoperability and infrastructure services pursuant to private commercial and government contracts. Specifically, we provide wireline and wireless number portability, implement the allocation of pooled blocks of telephone numbers and provide network management services pursuant to seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States. Although the FCC has plenary authority over the administration of telephone number portability, it is not a party to our contracts with North American Portability Management LLC. The North American Numbering Council, a federal advisory committee to which the FCC has delegated limited oversight responsibilities, reviews and oversees North American Portability Management LLC’s management of these contracts. See “— Regulatory Environment — Telephone Numbering.” We recognize revenue under our contracts with North American Portability Management LLC primarily on a per transaction basis. The aggregate fees for transactions processed under these contracts are determined by the total number of transactions, and these fees are billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share is based on each respective telecommunications service provider’s share of the aggregate end-user services revenues of all U.S. telecommunications service providers as determined by the FCC. On November 4, 2005, BellSouth Corporation filed a petition seeking changes in the way our customers are billed for services provided by us under our contracts with North American Portability Management LLC. Following this filing, the FCC requested comments from interested parties with respect to this petition. As of March 15, 2006, the FCC has not initiated a formal rulemaking process, and the BellSouth petition remains pending. We do not believe that this proposed change to the manner in which we bill for services under these contracts would have a material impact on our customers’ demand for these services. Under our contracts, we also bill a revenue recovery collections, or RRC, fee of a percentage of monthly billings to our customers, which is available to us if any telecommunications service provider fails to pay its allocable share of total transactions charges. If the RRC fee is insufficient for that purpose, these contracts also provide for the recovery of such differences from the remaining telecommunications service providers. Under these contracts, users of our clearinghouse also pay fees to connect to our data center and additional fees for reports that we generate at the user’s request. Our contracts with North American Portability Management LLC continue through May 2011.

      We also provide wireline number portability and network management services in Canada pursuant to a contract with the Canadian LNP Consortium, Inc., a private corporation composed of telecommunications service providers who participate in number portability in Canada. The Canadian Radio-television and Telecommunications Commission oversees the Canadian LNP Consortium’s management of this contract. We bill each telecommunications service provider for our services under this contract primarily on a per-transaction basis. This contract continues through December 2011. The services we provide under the contracts with North American Portability Management LLC and the Canadian LNP Consortium are subject to rigorous performance standards, and we are subject to corresponding penalties for failure to meet those standards.

      We serve as the North American Numbering Plan Administrator and the National Pooling Administrator pursuant to two separate contracts with the FCC. Under these contracts, we administer the assignment and implementation of new area codes in North America, the allocation of central office codes (which are the prefixes following the area codes) to telecommunications service providers in the United States, and the assignment and allocation of pooled blocks of telephone numbers in the United States in a manner designed to conserve telephone number resources. The North American Numbering Plan Administration contract is a fixed-fee government contract that was awarded by the FCC in 2003. The contract is structured as a one-year agreement with four one-year options exercisable by the FCC. The FCC has exercised two of these one-year extension options and may extend the contract for two additional one-year periods continuing through

9

July 8, 2008. The National Pooling Administration contract is a cost-plus government contract that was awarded by the FCC in 2001. This contract also is structured as a one-year agreement with four one-year options exercisable by the FCC. The FCC has exercised each of the four options, and this contract is due to expire on June 14, 2006. We expect to compete for a renewal of this contract when it is submitted by the FCC for rebid.

      Through our NeuLevel subsidiary, we are the operator of the .biz Internet top-level domain by contract with the Internet Corporation for Assigned Names and Numbers, or ICANN. The .biz contract was granted in May 2001 and continues through September 2007. Similarly, pursuant to a contract with the U.S. Department of Commerce, we operate the .us Internet domain registry. This contract was awarded in October 2001 for a period of four years, which may be extended by the government for two additional one-year periods. The government exercised the first one-year option in October 2005. These contracts allow us to provide domain name registration services to domain name registrars, who pay us on a per-name basis.

      We have an exclusive contract with the CTIA — The Wireless Association^® to serve as the registry operator for the administration of U.S. Common Short Codes. U.S. Common Short Codes are short strings of numbers to which text messages can be addressed — a common addressing scheme that works across all participating wireless networks. We were awarded this contract in October 2003 through an open procurement process by the major wireless carriers. The initial term of the contract continues through April 21, 2006. The contract automatically renews for additional two-year terms unless terminated in accordance with its terms. In addition to the five-digit U.S. Common Short Codes authorized in our original agreement with the CTIA, this agreement was amended in February 2006 to authorize the use of six-digit U.S. Common Short Codes, the use of which is scheduled to commence in the Spring of 2006. We provide U.S. Common Short Code registration services to wireless content providers, who pay us subscription fees per U.S. Common Short Code registered.

Regulatory Environment

Telephone Numbering

      Overview. The Telecommunications Act of 1996 was enacted to remove barriers to entry in the communications market. Among other things, the Telecommunications Act mandates portability of telephone numbers and requires traditional telephone companies to provide non-discriminatory access and interconnection to potential competitors. The FCC has plenary jurisdiction over issues relating to telephone numbers, including telephone number portability and the administration of telephone number resources. Under this authority, the FCC promulgated regulations governing the administration of telephone numbers and telephone number portability. In 1995, the FCC established the North American Numbering Council, a federal advisory committee, to advise and make recommendations to the FCC on telephone numbering issues, including telephone number resources administration and telephone number portability. The members of the North American Numbering Council include representatives from local exchange carriers, interexchange carriers, wireless providers, manufacturers, state regulators, consumer groups and telecommunications associations.

      Telephone Number Portability. The Telecommunications Act requires telephone number portability, which is the ability of users of telecommunications services to retain existing telephone numbers without impairment of quality, reliability, or convenience when switching from one telecommunications service provider to another. Through a series of competitive procurements, we were selected by a consortium of service providers representing the telecommunications industry to develop, build and operate a solution to enable telephone number portability in the United States. We ultimately entered into seven regional contracts to administer the system that we developed, after which the North American Numbering Council recommended to the FCC, and the FCC approved, our selection to serve as a neutral administrator of telephone number portability. The FCC also directed the seven original regional entities, each comprising a consortium of service providers operating in the respective regions, to manage and oversee the administration of telephone number portability in their respective regions, subject to North American Numbering Council oversight. Under the rules and policies adopted by the FCC, North American Portability Management LLC, as

10

successor in interest to the seven regional consortiums, has the power and authority to negotiate master agreements with an administrator of telephone number portability, so long as that administrator is neutral.

      North American Numbering Plan Administrator and National Pooling Administrator. We have contracts with the FCC to act as the North American Numbering Plan Administrator and the National Pooling Administrator, and we must comply with the rules and regulations of the FCC that govern our operations in each capacity. We are charged with administering numbering resources in an efficient and non-discriminatory manner, in accordance with FCC rules and industry guidelines developed primarily by the Industry Numbering Committee. These guidelines provide governing principles and procedures to be followed in the performance of our duties under these contracts. The communications industry regularly reviews and revises these guidelines to adapt to changed circumstances or as a result of the experience of industry participants in applying the guidelines. A committee of the North American Numbering Council evaluates our performance against these rules and guidelines each year and provides an annual review to the North American Numbering Council and the FCC. If we violate these rules and guidelines, or if we fail to perform at required levels, the FCC may reevaluate our fitness to serve as the North American Numbering Plan Administrator and the National Pooling Administrator and may terminate our contracts or impose fines on us. The division of the North American Numbering Council responsible for reviewing the performance of the North American Numbering Plan Administrator and the National Pooling Administrator has reviewed our performance as the North American Numbering Plan Administrator in each of the five years from 1999 through 2003 and as the National Pooling Administrator in 2003 and has determined that we met or more than met our performance guidelines under each such review. In its reviews of our performance in 2004 as the North American Numbering Plan Administrator and as the National Pooling Administrator, the North American Numbering Council determined that we more than met our performance guidelines for 2004 in each such capacity. Similar reviews of our performance in 2005 have not yet been completed.

      Neutrality. Under FCC rules and orders establishing the qualifications and obligations of the North American Numbering Plan Administrator and National Pooling Administrator, and under our contracts with North American Portability Management LLC to provide telephone number portability services, we are required to comply with neutrality regulations and policies. Under these neutrality requirements, we are required to operate our numbering plan, pooling administration and number portability functions in a neutral and impartial manner, which means that we cannot favor any particular telecommunications service provider, telecommunications industry segment or technology or group of telecommunications consumers over any other telecommunications service provider, industry segment, technology or group of consumers in the conduct of those businesses. We are examined periodically on our compliance with these requirements by independent third parties. The combined effect of our contracts and the FCC’s regulations and orders requires that we:

•  not be a telecommunications service provider, which is generally defined by the FCC as an entity that offers telecommunications services to the public at large, and is, therefore, providing telecommunications services on a common carrier basis;

•  not be an affiliate of a telecommunications service provider, which means, among other things, that we:

•  must restrict the beneficial ownership of our capital stock by telecommunications service providers or affiliates of a telecommunications service provider; and

•  may not otherwise, directly or indirectly, control, be controlled by, or be under common control with, a telecommunications service provider;

•  not derive a majority of our revenue from any single telecommunications service provider; and

•  not be subject to undue influence by parties with a vested interest in the outcome of numbering administration and activities. Notwithstanding our satisfaction of the other neutrality criteria above, the North American Numbering Council or the FCC could determine that we are subject to such undue influence. The North American Numbering Council may conduct an evaluation to determine whether we meet this “undue influence” criterion.

11

      We are required to maintain complete confidentiality of all competitive customer information obtained during the conduct of our business. In addition, as part of our neutrality framework, we are required to comply with a code of conduct that is designed to ensure our continued neutrality. Among other things, our code of conduct, which was approved by the FCC, requires that:

•  we never, directly or indirectly, show any preference or provide any special consideration to any telecommunications service provider;

•  we prohibit access by our stockholders to user data and proprietary information of telecommunications service providers served by us (other than access of employee stockholders that is incident to the performance of our numbering administration duties);

•  our shareholders take steps to ensure that they do not disclose to us any user data or proprietary information of any telecommunications service provider in which they hold an interest, other than the sharing of information in connection with the performance of our numbering administration duties;

•  we not share confidential information about our business services and operations with employees of any telecommunications service provider;

•  we refrain from simultaneously employing, whether full-time or part-time, any individual who is an employee of a telecommunications service provider and that none of our employees hold any interest, financial or otherwise, in any company that would violate these neutrality standards;

•  we prohibit any individual who serves in the management of any of our stockholders to be involved directly in our day-to-day operations;

•  we implement certain requirements regarding the composition of our board of directors;

•  no member of our board of directors simultaneously serve on the board of directors of a telecommunications service provider; and

•  we hire an independent party to conduct a quarterly neutrality audit to ensure that we and our stockholders comply with all the provisions of our code of conduct.

      In connection with the neutrality requirements imposed by our code of conduct and under our contracts, we are subject to a number of neutrality audits that are performed on a quarterly and semi-annual basis. In connection with these audits, all of our employees, directors and officers must sign a neutrality certification that states that they are familiar with our neutrality requirements and have not violated them. Failure to comply with applicable neutrality requirements could result in government fines, corrective measures, curtailment of contracts or even the revocation of contracts. See “Risk Factors — Risks Related to Our Business — Failure to comply with neutrality requirements could result in loss of significant contracts” in Item 1A of this report.

      To ensure that the previously controlling interest held by affiliates of Warburg Pincus would not compromise our neutrality, the FCC requires that all shares collectively held by Warburg Pincus and its affiliates representing in excess of 9.9% of the voting power of our outstanding shares of capital stock be held in an irrevocable voting trust. As of December 31, 2005, this voting trust also contained shares beneficially owned by members and former members of our management. This voting trust controls the voting rights of the shares held in trust, except that the investors may direct the manner in which the shares held in trust are to be voted in connection with matters relating to significant business combinations and similar transactions, issuance of capital stock, liquidation and incurrence of indebtedness in excess of $10,000,000.

      In connection with the initial public offering of our securities, we sought and obtained FCC approval for a “safe harbor” from previous orders of the FCC that required us to seek prior approval from the FCC for any change in our overall ownership structure, corporate structure, bylaws, or distribution of equity interests, as well as certain types of transactions, including the issuance of indebtedness by us. Under the safe harbor order, we are required to maintain provisions in our organizational and other corporate documents that require us to comply with all applicable neutrality rules and orders. However, we are no longer required to seek prior

12

approval from the FCC for many of these changes and transactions, although we are required to provide notice of such changes or transactions. In addition, we are subject to the following requirements:

•  we may not issue indebtedness to any entity that is a telecommunications service provider or an affiliate of a telecommunications service provider without prior approval of the FCC;

•  we may not acquire any equity interest in a telecommunications service provider or an affiliate of a telecommunications service provider without prior approval of the FCC;

•  we must restrict any telecommunications service provider or affiliate of a telecommunications service provider from acquiring or beneficially owning 5% or more of our outstanding capital stock;

•  we must report to the FCC the names of any telecommunications service providers or telecommunications service provider affiliates that own a 5% or greater interest in our company; and

•  we must make beneficial ownership records available to our auditors, and must certify upon request that we have no actual knowledge of any ownership of our outstanding capital stock by a telecommunications service provider or telecommunications service provider affiliate other than as previously disclosed.

Internet Domain Name Registrations

      We are also subject to government and industry regulation under our Internet registry contracts with the U.S. government and ICANN, the industry organization responsible for regulation of Internet top-level domains. We are the operator of the .biz Internet domain under a contract with ICANN granted to us in May 2001, which expires in September 2007. Similarly, pursuant to a contract with the U.S. Department of Commerce, we operate the .us Internet domain registry. This contract was granted in October 2001 for a period of four years, with two one-year extension periods exercisable at the option of the U.S. Department of Commerce. The Department of Commerce exercised the first one-year option in October 2005. Under each of these registry service contracts, we are required to:

•  provide equal access to all registrars of domain names;

•  comply with Internet standards established by the industry;

•  implement additional policies as they are adopted by the U.S. government or ICANN; and

•  with respect to the .us registry, establish, operate and ensure appropriate content on a kids.us domain to serve as a haven for material that promotes positive experiences for children and families using the Internet.

Intellectual Property

      Our success depends in part upon our proprietary technology. We rely principally upon trade secret and copyright law to protect our technology, including our software, network design, and subject matter expertise. We enter into confidentiality or license agreements with our employees, distributors, customers, and potential customers and limit access to and distribution of our software, documentation, and other proprietary information. We believe, however, that because of the rapid pace of technological change in the communications industry, the legal protections for our services are less significant factors in our success than the knowledge, ability, and experience of our employees and the timeliness and quality of services provided by us.

Available Information and Exchange Certifications

      We maintain an Internet website at www.neustar.biz. Information contained on, or that may be accessed through, our website is not part of this report. Our annual report on Form 10-K, quarterly reports on Form 10-Q, current reports on Form 8-K and amendments to reports filed or furnished pursuant to Sections 13(a) and 15(d) of the Securities Exchange Act of 1934, as amended, are available on the Investor Relations section of our website under the heading “SEC Filings by NeuStar,” as soon as reasonably practicable after we electronically file such reports with, or furnish those reports to, the Securities and

13

Exchange Commission. Our Principles of Corporate Governance, Board of Directors committee charters (including the charters of the Audit Committee, Compensation Committee, and Nominating and Corporate Governance Committee) and code of ethics entitled “Corporate Code of Business Conduct” also are available on the Investor Relations section of our website. Stockholders may request free copies of these documents, including a copy of our annual report on Form 10-K, by sending a written request to our Corporate Secretary at NeuStar, Inc., 46000 Center Oak Plaza, Sterling, VA 20166. In the event that we make any changes to, or provide any waivers from, the provisions of our Corporate Code of Business Conduct, we intend to disclose these events on our website or in a report on Form 8-K within four business days of such event.

      Because our common stock is listed on the NYSE, our Chief Executive Officer is required to make an annual certification to the NYSE stating that he is not aware of any violation by us of the corporate governance listing standards of the NYSE. Our Chief Executive Officer will make his annual certification to that effect to the NYSE within 30 days after the first anniversary of the listing of our Class A common stock on the NYSE as required by the NYSE’s rules. In addition, we have filed, as an exhibit to this Annual Report on Form 10-K, the certification of our principal executive officer and principal financial officer required under Section 302 and Section 906 of the Sarbanes-Oxley Act of 2002 to be filed with the Securities and Exchange Commission regarding the quality of our public disclosure.

Cautionary Note Regarding Forward-Looking Statements

      This report contains forward-looking statements. In some cases, you can identify forward-looking statements by terminology such as “may,” “will,” “should,” “expects,” “intends,” “plans,” “anticipates,” “believes,” “estimates,” “predicts,” “potential,” “continue” or the negative of these terms or other comparable terminology. These statements relate to future events or our future financial performance and involve known and unknown risks, uncertainties and other factors that may cause our actual results, levels of activity, performance or achievements to differ materially from any future results, levels of activity, performance or achievements expressed or implied by these forward-looking statements. Many of these risks are beyond our ability to control or predict. These risks and other factors include those listed under “Risk Factors” in Item 1A of this report and elsewhere in this report and include:

•  failures or interruptions of our systems and services;

•  security or privacy breaches;

•  loss of, or damage to, a data center;

•  termination, modification or non-renewal of our contracts to provide telephone number portability and other clearinghouse services;

•  adverse changes in statutes or regulations affecting the communications industry;

•  our failure to adapt to rapid technological change in the communications industry;

•  competition from our customers’ in-house systems or from other providers of addressing, interoperability or infrastructure services;

•  our failure to achieve or sustain market acceptance at desired pricing levels;

•  a decline in the volume of transactions we handle;

•  inability to manage our growth;

•  economic, political, regulatory and other risks associated with our potential expansion into international markets;

•  inability to obtain sufficient capital to fund our operations, capital expenditures and expansion; and

•  loss of members of senior management, or inability to recruit and retain skilled employees.

      Although we believe that the expectations reflected in the forward-looking statements are reasonable, we cannot guarantee future results, levels of activity, performance or achievements. We caution you not to place

14

undue reliance on forward-looking statements, which reflect only our expectations as of the date of this report. We undertake no obligation to publicly update the forward-looking statements to reflect subsequent events or circumstances. All subsequent written and oral forward-looking statements attributable to us, or persons acting on our behalf, are expressly qualified in their entirety by the cautionary statements contained throughout this report.

ITEM 1A.     RISK FACTORS.

Risks Related to Our Business

Failures or interruptions of our clearinghouse could materially harm our revenue and impair our ability to conduct our operations.

      We provide addressing, interoperability and infrastructure services that are critical to the operations of our customers. Notably, our clearinghouse is essential to the orderly operation of the national telecommunications system because it enables CSPs to ensure that telephone calls are routed to the appropriate destinations. Our system architecture is integral to our ability to process a high volume of transactions in a timely and effective manner. We could experience failures or interruptions of our systems and services, or other problems in connection with our operations, as a result of:

•  damage to, or failure of, our computer software or hardware or our connections and outsourced service arrangements with third parties;

•  errors in the processing of data by our system;

•  computer viruses or software defects;

•  physical or electronic break-ins, sabotage, intentional acts of vandalism and similar events;

•  increased capacity demands or changes in systems requirements of our customers; or

•  errors by our employees or third-party service providers.

      If we cannot adequately protect the ability of our clearinghouse to perform consistently at a high level or otherwise fail to meet our customers’ expectations:

•  we may experience damage to our reputation, which may adversely affect our ability to attract or retain customers for our existing services, and may also make it more difficult for us to market our services;

•  we may be subject to significant damages claims, under our contracts or otherwise, including the requirement to pay substantial penalties related to service level requirements in our contracts;

•  our operating expenses or capital expenditures may increase as a result of corrective efforts that we must perform;

•  our customers may postpone or cancel subsequently scheduled work or reduce their use of our services; or

•  one or more of our significant contracts may be terminated early, or may not be renewed.

      Any of these consequences would adversely affect our revenue and performance.

Security breaches could result in an interruption of service or reduced quality of service, which could increase our costs or result in a reduction in the use of our services by our customers.

      Our systems may be vulnerable to physical break-ins, computer viruses, attacks by computer hackers or similar disruptive problems. If unauthorized users gain access to our databases, they may be able to steal, publish, delete or modify sensitive information that is stored or transmitted on our networks and that we are required by our contracts and FCC rules to keep confidential. A security or privacy breach could result in an interruption of service or reduced quality of service and we may be required to make significant expenditures in connection with corrective efforts we are required to perform. In addition, a security or privacy breach may

15

harm our reputation and cause our customers to reduce their use of our services, which could harm our revenue and business prospects.

The loss of, or damage to, a data center could interrupt our operations and materially harm our revenue and growth.

      Because telecommunications service providers must query a copy of our continuously updated databases to route virtually every telephone call in North America, the integrity of our data centers is essential to our business. We may not have sufficient redundant systems or back-up facilities to allow us to receive and process data in the event of a loss of, or damage to, a data center. We could lose, or suffer damage to, a data center in the event of power loss; natural disasters such as fires, earthquakes, floods and tornadoes; telecommunications failures, such as transmission cable cuts; or other similar events that could adversely affect our customers’ ability to access our clearinghouse. We may be required to make significant expenditures to repair or replace a data center. Any interruption to our operations due to the loss of, or damage to, a data center could harm our reputation and cause our customers to reduce their use of our services, which could harm our revenue and business prospects.

The failure of the third-party software and equipment used by our customers or that we use in our clearinghouse could cause interruptions or failures of our systems.

      We incorporate hardware, software and equipment developed by third parties in our clearinghouse. Our third-party vendors include, among others, IBM, and Oracle Corporation for database systems and software, and EMC Corporation and Sun Microsystems, Inc. for equipment. Similarly, to access our clearinghouse and utilize our services, many of our customers rely on hardware, software and other equipment developed, supported and maintained by third-party providers. As a result, our ability to provide clearinghouse services depends in part on the continued performance and support of the third-party products on which we and our customers rely. If these products experience failures or have defects and the third parties that supply the products fail to provide adequate support, this could result in or exacerbate an interruption or failure of our systems or services.

Our seven contracts with North American Portability Management LLC represent in the aggregate a substantial portion of our revenue, are not exclusive and could be terminated or modified in ways unfavorable to us, and we may be unable to renew these contracts at the end of their term.

      Our seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States, to provide telephone number portability and other clearinghouse services are not exclusive and could be terminated or modified in ways unfavorable to us. These seven separate contracts, each of which represented between 8.5% and 14.8% of our total revenue in 2005, represented in the aggregate approximately 77.9% of our total revenue in 2005. North American Portability Management LLC could, at any time, solicit or receive proposals from other providers to provide services that are the same as or similar to ours. In addition, these contracts have finite terms and are currently scheduled to expire in May 2011. Furthermore, any of these contracts could be terminated in advance of its scheduled expiration date in limited circumstances, most notably if we are in default of these agreements. Although these contracts do not contain cross-default provisions, conditions leading to a default by us under one of our contracts could lead to a default under others, or all seven.

      We may be unable to renew these contracts on acceptable terms when they are being considered for renewal if we fail to meet our customers’ expectations, including for performance and other reasons, or if another provider offers to provide the same or similar services at a lower cost. In addition, competitive forces resulting from the possible entrance of a competitive provider could create significant pricing pressure, which could then cause us to reduce the selling price of our services under our contracts. If these contracts are terminated or modified in a manner that is adverse to us, or if we are unable to renew these contracts on acceptable terms upon their expiration, it would have a material adverse effect on our business, prospects, financial condition and results of operations. See “Business — Contracts” in Item 1 of this report.

16

Our contracts with North American Portability Management LLC contain provisions that may restrict our ability to use data that we administer in our clearinghouse, which may limit our ability to offer services that we currently, or intend to, offer.

      In addition to offering telephone number portability and other clearinghouse services under our contracts with North American Portability Management LLC, some of our service offerings not related to these contracts require that we use certain data from our clearinghouse. We have been informed by North American Portability Management LLC that they believe that use of this data, which is unrelated to our performance under these contracts, may not be permissible under the current agreements. If we are subject to burdensome terms of access or are not permitted to use this data, our ability to offer new services requiring the use of this data may be limited.

Certain of our other contracts may be terminated or we may be unable to renew these contracts, which may reduce the number of services we can offer and damage our reputation.

      In addition to our contracts with North American Portability Management LLC, we rely on other contracts to provide some of the services that we offer, including the contracts that appoint us to serve as the:

•  North American Numbering Plan Administrator, under which we maintain the authoritative database of telephone numbering resources in North America;

•  National Pooling Administrator, under which we perform the administrative functions associated with the administration and management of telephone number inventory and allocation of pooled blocks of unassigned telephone numbers;

•  provider of number portability services in Canada;

•  operator of the .us registry;

•  operator of the .biz registry; and

•  operator of the registry of U.S. Common Short Codes.

      Each of these contracts provides for early termination in limited circumstances, most notably if we are in default. In addition, our contracts to serve as the North American Numbering Plan Administrator and as the National Pooling Administrator and to operate the .us registry, each of which is with the U.S. government, may be terminated by the government at will. If we fail to meet the expectations of the FCC, the U.S. Department of Commerce or our customers, as the case may be, for any reason, including for performance-related or other reasons, or if another provider offers to perform the same or similar services for a lower price, we may be unable to extend or renew these contracts. In that event, the number of services we are able to offer may be reduced, which would adversely affect our revenue from the provision of these services. Each of the contracts listed above establishes us as the sole provider of the particular services covered by that contract during its term. If one of these contracts were terminated, or if we were unable to renew or extend the term of any particular contract, we would no longer be able to provide the services covered by that contract and could suffer a loss of prestige that would make it more difficult for us to compete for contracts to provide similar services in the future.

Failure to comply with neutrality requirements could result in loss of significant contracts.

      Pursuant to orders and regulations of the U.S. government and provisions contained in our material contracts, we must continue to comply with certain neutrality requirements, meaning generally that we cannot favor any particular telecommunications service provider, telecommunications industry segment or technology or group of telecommunications consumers over any other telecommunications service provider, industry segment, technology or group of consumers in the conduct of our business. See “Business — Regulatory Environment — Telephone Numbering — Neutrality” in Item 1 of this report. The FCC oversees our compliance with the neutrality requirements applicable to us in connection with some of the services we provide. We provide to the FCC and the North American Numbering Council, a federal advisory committee established by the FCC to advise and make recommendations on telephone numbering issues, regular

17

certifications relating to our compliance with these requirements. Our ability to comply with the neutrality requirements to which we are subject may be affected by the activities of our stockholders or other parties. For example, if the ownership of our capital stock subjects us to undue influence by parties with a vested interest in the outcome of numbering administration, the FCC could determine that we are not in compliance with our neutrality obligations. Our failure to continue to comply with the neutrality requirements to which we are subject under applicable orders and regulations of the U.S. government and commercial contracts may result in fines, corrective measures or termination of our contracts, any one of which could have a material adverse effect on our results of operations.

Regulatory and statutory changes that affect us or the communications industry in general may increase our costs or impair our growth.

      The FCC has regulatory authority over certain aspects of our operations, most notably our compliance with our neutrality requirements. We are also affected by business risks specific to the regulated communications industry. Moreover, the business of our customers is subject to regulation that indirectly affects our business. As communications technologies and the communications industry continue to evolve, the statutes governing the communications industry or the regulatory policies of the FCC may change. If this were to occur, the demand for our clearinghouse services could change in ways that we cannot easily predict and our revenue could decline. These risks include the ability of the federal government, most notably the FCC, to:

•  increase regulatory oversight over the services we provide;

•  adopt or modify statutes, regulations, policies, procedures or programs that are disadvantageous to the services we provide, or that are inconsistent with our current or future plans, or that require modification of the terms of our existing contracts, including the manner in which we charge for certain of our services. For example, in November 2005, BellSouth Corporation filed a petition with the FCC seeking changes in the way our customers are billed for services provided by us under our contracts with North American Portability Management LLC;

•  prohibit us from entering into new contracts or extending existing contracts to provide services to the communications industry based on actual or suspected violations of our neutrality requirements, business performance concerns, or other reasons;

•  adopt or modify statutes, regulations, policies, procedures or programs in a way that could cause changes to our operations or costs or the operations of our customers;

•  appoint, or cause others to appoint, substitute or add additional parties to perform the services that we currently provide; and

•  prohibit or restrict the provision or export of new or expanded services under our contracts, or prevent the introduction of other services not under the contracts based upon restrictions within the contracts or in FCC policies.

      In addition, we are subject to risks arising out of the delegation of the Department of Commerce’s responsibilities for the domain name system to the International Corporation for Assigned Names and Numbers, or ICANN. Changes in the regulations or statutes to which our customers are subject could cause our customers to alter or decrease the services they purchase from us. We cannot predict when, or upon what terms and conditions, further regulation or deregulation might occur or the effect future regulation or deregulation may have on our business.

If we do not adapt to rapid technological change in the communications industry, we could lose customers or market share.

      Our industry is characterized by rapid technological change and frequent new service offerings. Significant technological changes could make our technology and services obsolete. We must adapt to our rapidly changing market by continually improving the features, functionality, reliability and responsiveness of our addressing, interoperability and infrastructure services, and by developing new features, services and

18

applications to meet changing customer needs. We cannot guarantee that we will be able to adapt to these challenges or respond successfully or in a cost-effective way. Our failure to do so would adversely affect our ability to compete and retain customers or market share. Although we currently provide our services primarily to traditional telecommunications companies, many existing and emerging companies are providing, or propose to provide, IP-based voice services. Our future revenue and profits will depend, in part, on our ability to provide services to IP-based service providers. For example, we are currently conducting trial tests of SIP-IX, a comprehensive suite of services designed to enable direct network-to-network peering between trading partners for voice, video and content services using Session Initiation Protocol (SIP)-based technologies such as IP multimedia subsystem (IMS) and Voice over Internet Protocol (VoIP). There can be no assurance that IP communications will grow in any meaningful fashion, or that SIP-IX will be adopted by potential customers, nor can we guarantee that we will be able to reach acceptable contract terms with customers to provide this service. In addition, we may experience delays in the development of one or more features of SIP-IX, which could materially reduce the potential benefits to us for providing this service.

The market for certain of our addressing, interoperability, and infrastructure services is competitive, which could result in fewer customer orders, reduced revenue or margins or loss of market share.

      Our services most frequently compete against the legacy in-house systems of our customers. In addition, although we are not a telecommunications service provider, we compete in some areas against communications service companies, communications software companies and system integrators that provide systems and services used by CSPs to manage their networks and internal operations in connection with telephone number portability and other telecommunications transactions. We face competition from large, well-funded providers of addressing, interoperability and infrastructure services. Moreover, we are aware of other companies that are focusing significant resources on developing and marketing services that will compete with us. We anticipate continued growth of competition. Some of our current and potential competitors have significantly more employees and greater financial, technical, marketing and other resources than we have. Our competitors may be able to respond more quickly to new or emerging technologies and changes in customer requirements than we can. Also, many of our current and potential competitors have greater name recognition that they can use to their advantage. Increased competition could result in fewer customer orders, reduced revenue, reduced gross margins and loss of market share, any of which could harm our business.

Our failure to achieve or sustain market acceptance at desired pricing levels could impact our ability to maintain profitability or positive cash flow.

      Our competitors and customers may cause us to reduce the prices we charge for services. The primary sources of pricing pressure include:

•  competitors offering our customers services at reduced prices, or bundling and pricing services in a manner that makes it difficult for us to compete. For example, a competing provider of interoperability services might offer its services at lower rates than we do, or a competing domain name registry provider may reduce its prices for domain name registration;

•  customers with a significant volume of transactions may have enhanced leverage in pricing negotiations with us; and

•  if our prices are too high, potential customers may find it economically advantageous to handle certain functions internally instead of using us.

      We may not be able to offset the effects of any price reductions by increasing the number of transactions we handle or the number of customers we serve, by generating higher revenue from enhanced services or by reducing our costs.

19

A decline in the volume of transactions we handle could have a material adverse effect on our results of operations.

      We earn revenue for the vast majority of the services that we provide on a per transaction basis. There are no minimum revenue requirements in our contracts, which means that there is no limit to the potential adverse effect on our revenue from a decrease in our transaction volumes. As a result, if industry participants reduce their usage of our services from their current levels, our revenue and results of operations will suffer. For example, if customer churn between CSPs in the industry stabilizes or declines, or if CSPs do not compete vigorously to lure customers away from their competitors, use of our telephone number portability and other services may decline. In addition, if CSPs develop internal systems to address their infrastructure needs, or if the cost of such transactions makes it impractical for a given carrier to use our services for these purposes, we may experience a reduction in transaction volumes. Finally, the trends that we believe will drive the future demand for our clearinghouse services, such as the emergence of IP services, growth of wireless services, consolidation in the industry, and pressure on carriers to reduce costs, may not actually result in increased demand for our services, which would harm our future revenue and growth prospects.

If we are unable to manage our growth, our revenue and profits could be adversely affected.

      Sustaining our growth has placed significant demands on our management as well as on our administrative, operational and financial resources. For us to continue to manage our growth, we must continue to improve our operational, financial and management information systems and expand, motivate and manage our workforce. If we are unable to successfully manage our growth without compromising our quality of service and our profit margins, or if new systems that we implement to assist in managing our growth do not produce the expected benefits, our revenue and profits could be adversely affected.

We may be unable to complete suitable acquisitions, or we may undertake acquisitions that could increase our costs or liabilities or be disruptive to our business.

      We have made a number of acquisitions in the past, and one of our strategies is to pursue acquisitions selectively in the future. We may not be able to locate suitable acquisition candidates at prices that we consider appropriate or to finance acquisitions on terms that are satisfactory to us. If we do identify an appropriate acquisition candidate, we may not be able to successfully negotiate the terms of an acquisition, finance the acquisition or, if the acquisition occurs, integrate the acquired business into our existing business. Acquisitions of businesses or other material operations may require additional debt or equity financing, resulting in additional leverage or dilution to our stockholders. Integration of acquired business operations could disrupt our business by diverting management away from day-to-day operations. The difficulties of integration may be increased by the necessity of coordinating geographically dispersed organizations, integrating personnel with disparate business backgrounds and combining different corporate cultures. We also may not realize cost efficiencies or synergies or other benefits that we anticipated when selecting our acquisition candidates. In addition, we may need to record write-downs from future impairments of intangible assets, which could reduce our future reported earnings. At times, acquisition candidates may have liabilities, neutrality-related risks or adverse operating issues that we fail to discover through due diligence prior to the acquisition. The failure to discover such issues prior to such acquisition could have a material adverse effect on our business and results of operations.

Our potential expansion into international markets may be subject to uncertainties that could increase our costs to comply with regulatory requirements in foreign jurisdictions, disrupt our operations, and require increased focus from our management.

      We intend to pursue international business opportunities, which could involve the growth of our operations in foreign jurisdictions. International operations and business expansion plans are subject to numerous additional risks, including economic and political risks in foreign jurisdictions in which we operate or seek to operate, the difficulty of enforcing contracts and collecting receivables through some foreign legal systems, unexpected changes in regulatory requirements and the difficulties associated with managing a large organization spread throughout various countries. If we continue to expand our business globally, our success

20

will depend, in large part, on our ability to anticipate and effectively manage these and other risks associated with our international operations. However, any of these factors could adversely affect our international operations and, consequently, our operating results.

Our senior management is important to our customer relationships, and the loss of one or more of our senior managers could have a negative impact on our business.

      We believe that our success depends in part on the continued contributions of our Chief Executive Officer, Jeffrey Ganek, and other members of our senior management. We rely on our executive officers and senior management to generate business and execute programs successfully. In addition, the relationships and reputation that members of our management team have established and maintain with our customers and our regulators contribute to our ability to maintain good customer relations. The loss of Jeffrey Ganek or any other member of senior management could impair our ability to identify and secure new contracts and otherwise to manage our business.

We must recruit and retain skilled employees to succeed in our business, and our failure to recruit and retain qualified employees could harm our ability to maintain and grow our business.

      We believe that an integral part of our success is our ability to recruit and retain employees who have advanced skills in the addressing, interoperability and infrastructure services that we provide and who work well with our customers in the regulated environment in which we operate. In particular, we must hire and retain employees with the technical expertise and industry knowledge necessary to maintain and continue to develop our operations and must effectively manage our growing sales and marketing organization to ensure the growth of our operations. Our future success depends on the ability of our sales and marketing organization to establish direct sales channels and to develop multiple distribution channels with Internet service providers and other third parties. The employees with the skills we require are in great demand and are likely to remain a limited resource in the foreseeable future. If we are unable to recruit and retain a sufficient number of these employees at all levels, our ability to maintain and grow our business could be negatively impacted.

We will continue to incur increased costs as a public company as a result of recently enacted and proposed changes in laws and regulations.

      Recently enacted and proposed changes in the laws and regulations affecting public companies, including the provisions of the Sarbanes-Oxley Act of 2002 and rules of the Securities and Exchange Commission and the New York Stock Exchange, have resulted and will continue to result in increased costs to us, including those related to corporate governance and the costs to operate as a public company. Section 404 of the Sarbanes-Oxley Act of 2002 requires companies to perform a comprehensive and costly evaluation and obtain an audit of their internal controls. The new rules could also make it more difficult or more costly for us to maintain certain types of insurance, including directors’ and officers’ liability insurance. The impact of these events could make it more difficult for us to attract and retain qualified persons to serve on our board of directors, our board committees or as executive officers.

We may need additional capital in the future and it may not be available on acceptable terms.

      We have historically relied on outside financing and cash flow from operations to fund our operations, capital expenditures and expansion. However, we may require additional capital in the future to fund our operations, finance investments in equipment or infrastructure, or respond to competitive pressures or strategic opportunities. Additional financing may not be available on terms favorable to us, or at all. In addition, the terms of available financing may place limits on our financial and operating flexibility. If we are unable to obtain sufficient capital in the future, we may:

•  not be able to continue to meet customer demand for service quality, availability and competitive pricing;

•  be forced to reduce our operations;

21

•  not be able to expand or acquire complementary businesses; and

•  not be able to develop new services or otherwise respond to changing business conditions or competitive pressures.

Risks Related to Our Common Stock

Our common stock price may be volatile.

      The market price of our Class A common stock may fluctuate widely. Fluctuations in the market price of our Class A common stock could be caused by many things, including:

•  our perceived prospects and the prospects of the telephone and Internet industries in general;

•  differences between our actual financial and operating results and those expected by investors and analysts;

•  changes in analysts’ recommendations or projections;

•  changes in general valuations for communications companies;

•  adoption or modification of regulations, policies, procedures or programs applicable to our business;

•  sales of our Class A common stock by our officers, directors or principal stockholders;

•  sales of significant amounts of our Class A common stock in the public market, or the perception that such sales may occur;

•  sales of our Class A common stock due to a required divestiture under the terms of our certificate of incorporation; and

•  changes in general economic or market conditions and broad market fluctuations.

      Each of these factors, among others, could have a material adverse effect on the market price of our Class A common stock. In addition, in recent years, the stock market in general and the shares of technology companies in particular have experienced extreme price fluctuations. This volatility has had a substantial effect on the market prices of securities issued by many companies for reasons unrelated to the operating performance of the specific companies. Some companies that have had volatile market prices for their securities have had securities class action suits filed against them. If a suit were to be filed against us, regardless of the outcome, it could result in substantial costs and a diversion of our management’s attention and resources. This could have a material adverse effect on our business, prospects, financial condition and results of operations.

One of our stockholders holds a significant block of shares in our company and, as a result, may have significant influence over our company.

      Our board of directors includes one representative of Warburg Pincus. Pursuant to an agreement between us and certain holders of our Class A common stock, we anticipate that one representative of Warburg Pincus will continue to serve on our board of directors. In addition, as of December 31, 2005, affiliates of Warburg Pincus owned or controlled approximately 10.9% of the outstanding shares of our Class A common stock. A portion of the shares owned by these stockholders is held in a voting trust that controls the voting rights with respect to some actions that are subject to the approval of our stockholders under applicable law. However, under the terms of the trust agreement, these stockholders may hold up to 9.9% of the voting power of our outstanding shares of capital stock directly, and they have full voting power over such shares. In addition, they have the right to direct the voting trust as to how to vote their shares held in trust with respect to, among other things, any merger, sale or similar transaction involving NeuStar, the issuance of capital stock and the incurrence of substantial indebtedness. As a result of their ownership interest, these affiliates of Warburg Pincus may have the ability to significantly influence the outcome of a vote by our stockholders, and their interests could conflict with the interests of our other stockholders. Additionally, they and their affiliates are in the business of making investments in companies and may from time to time acquire and hold interests in

22

businesses that compete or could in the future compete, directly or indirectly, with us. For example, another Warburg Pincus fund has a significant investment in Telcordia Technologies, Inc., which has competed (and may compete in the future) with us. Warburg Pincus and its affiliates may also pursue acquisition opportunities that may be complementary to our business, and as a result, those acquisition opportunities may not be available to us.

Delaware law and provisions in our certificate of incorporation and bylaws could make a merger, tender offer or proxy contest difficult, and the market price of our Class A common stock may be lower as a result.

      We are a Delaware corporation, and the anti-takeover provisions of the Delaware General Corporation Law may discourage, delay or prevent a change in control by prohibiting us from engaging in a business combination with an interested stockholder for a period of three years after the person becomes an interested stockholder, even if a change of control would be beneficial to our existing stockholders. In addition, our certificate of incorporation and bylaws may discourage, delay or prevent a change in our management or control over us that stockholders may consider favorable. Our certificate of incorporation and bylaws:

•  authorize the issuance of “blank check” preferred stock that could be issued by our board of directors to thwart a takeover attempt;

•  prohibit cumulative voting in the election of directors, which would otherwise enable holders of less than a majority of our voting securities to elect some of our directors;

•  establish a classified board of directors, as a result of which the successors to the directors whose terms have expired will be elected to serve from the time of election and qualification until the third annual meeting following election;

•  require that directors only be removed from office for cause;

•  provide that vacancies on the board of directors, including newly-created directorships, may be filled only by a majority vote of directors then in office;

•  disqualify any individual from serving on our board if such individual’s service as a director would cause us to violate our neutrality requirements;

•  limit who may call special meetings of stockholders;

•  prohibit stockholder action by written consent, requiring all actions to be taken at a meeting of the stockholders; and

•  establish advance notice requirements for nominating candidates for election to the board of directors or for proposing matters that can be acted upon by stockholders at stockholder meetings.

In order to comply with our neutrality requirements, our certificate of incorporation contains ownership and transfer restrictions relating to telecommunications service providers and their affiliates, which may inhibit potential acquisition bids that our stockholders may consider favorable, and the market price of our Class A common stock may be lower as a result.

      In order to comply with neutrality requirements imposed by the FCC in its orders and rules, no entity that qualifies as a “telecommunications service provider” or affiliate of a telecommunications service provider, as such terms are defined under the Communications Act of 1934 and FCC rules and orders, may beneficially own 5% or more of our capital stock. As a result, subject to limited exceptions, our certificate of incorporation prohibits any telecommunications service provider or affiliate of a telecommunications service provider from beneficially owning, directly or indirectly, 5% or more of our outstanding capital stock. Among other things, our certificate of incorporation provides that:

•  if one of our stockholders experiences a change in status or other event that results in the stockholder violating this restriction, or if any transfer of our stock occurs that, if effective, would violate the 5% restriction, we may elect to purchase the excess shares (i.e., the shares that cause the violation of the

23

	restriction) or require that the excess shares be sold to a third party whose ownership will not violate the restriction;
•	pending a required divestiture of these excess shares, the holder whose beneficial ownership violates the 5% restriction may not vote the shares in excess of the 5% threshold; and
•	if our board of directors, or its permitted designee, determines that a transfer, attempted transfer or other event violating this restriction has taken place, we must take whatever action we deem advisable to prevent or refuse to give effect to the transfer, including refusal to register the transfer, disregard of any vote of the shares by the prohibited owner, or the institution of proceedings to enjoin the transfer.

      Our board of directors has the authority to make determinations as to whether any particular holder of our capital stock is a telecommunications service provider or an affiliate of a telecommunications service provider. Any person who acquires, or attempts or intends to acquire, beneficial ownership of our stock that will or may violate this restriction must notify us as provided in our certificate of incorporation. In addition, any person who becomes the beneficial owner of 5% or more of our stock must notify us and certify that such person is not a telecommunications service provider or an affiliate of a telecommunications service provider. If a 5% stockholder fails to supply the required certification, we are authorized to treat that stockholder as a prohibited owner — meaning, among other things, that we may elect to purchase the excess shares or require that the excess shares be sold to a third party whose ownership will not violate the restriction. We may request additional information from our stockholders to ensure compliance with this restriction. Our board will treat any “group,” as that term is defined in Section 13(d)(3) of the Securities Exchange Act of 1934, as a single person for purposes of applying the ownership and transfer restrictions in our certificate of incorporation.

      Nothing in our certificate of incorporation restricts our ability to purchase shares of our capital stock. If a purchase by us of shares of our capital stock results in a stockholder’s percentage interest in our outstanding capital stock increasing to over the 5% threshold, such stockholder must deliver the required certification regarding such stockholder’s status as a telecommunications service provider or affiliate of a telecommunications service provider. In addition, to the extent that a repurchase by us of shares of our capital stock causes any stockholder to violate the restrictions on ownership and transfer contained in our certificate of incorporation, that stockholder will be subject to all of the provisions applicable to prohibited owners, including required divestiture and loss of voting rights.

      These restrictions and requirements may:

•  discourage industry participants that might have otherwise been interested in acquiring us from making a tender offer or proposing some other form of transaction that could involve a premium price for our shares or otherwise be in the best interests of our stockholders; and

•  discourage investment in us by other investors who are telecommunications service providers or who may be deemed to be affiliates of a telecommunications service provider.

      The standards for determining whether an entity is a “telecommunications service provider” are established by the FCC. In general, a telecommunications service provider is an entity that offers telecommunications services to the public at large, and is, therefore, providing telecommunications services on a common carrier basis. Moreover, a party will be deemed to be an affiliate of a telecommunications service provider if that party controls, is controlled by, or is under common control with, a telecommunications service provider. A party is deemed to control another if that party, directly or indirectly:

•  owns 10% or more of the total outstanding equity of the other party;

•  has the power to vote 10% or more of the securities having ordinary voting power for the election of the directors or management of the other party; or

•  has the power to direct or cause the direction of the management and policies of the other party.

      The standards for determining whether an entity is a telecommunications service provider or an affiliate of a telecommunications service provider and the rules applicable to telecommunications service providers and

24

their affiliates are complex and may be subject to change. Each stockholder is responsible for notifying us if it is a telecommunications service provider or an affiliate of a telecommunications service provider.

ITEM 1B.     UNRESOLVED STAFF COMMENTS.

      Not applicable.

ITEM 2. PROPERTIES.

      Our corporate headquarters are located in Sterling, Virginia under leases that are scheduled to expire in July and August 2010. We have two five-year renewal options on these leases. We also lease operating space in Concord, California; Charlotte, North Carolina; and the District of Columbia under leases that expire in August 2006, November 2007 and November 2009, respectively.

      All of our facility leases are with unaffiliated third parties. We believe that our existing facilities are sufficient to meet our requirements.

ITEM 3. LEGAL PROCEEDINGS.

      From time to time, we are subject to claims in legal proceedings arising in the normal course of our business. We do not believe that we are party to any pending legal action that could reasonably be expected to have a material adverse effect on our business or operating results.

      On April 9, 2004, Douglas Armentrout, the former chief executive officer of NeuLevel, Inc. filed a complaint against us, NeuLevel, Inc. and Jeffrey Ganek, our Chairman and Chief Executive Officer, in the Superior Court of the District of Columbia (Civil Action No. 04-0002814). The complaint alleges, among other things, that we, NeuLevel and Mr. Ganek convinced Mr. Armentrout to leave his former employment in January 2001 and forfeit substantial compensation benefits by means of false promises regarding the employment benefits he would enjoy with us or NeuLevel, and/or otherwise breached certain agreements with Mr. Armentrout regarding his employment status and benefits. In addition, the complaint alleges that Mr. Armentrout was wrongfully terminated in January 2002 to prevent him from investigating alleged fraudulent accounting practices as between us and NeuLevel. The complaint seeks approximately $20 million in damages, $15 million of which are alleged emotional distress and punitive damages. We, NeuLevel and Mr. Ganek dispute all of these claims and are vigorously defending ourselves against the allegations in the complaint. We are paying our, NeuLevel’s and Mr. Ganek’s legal expenses relating to this complaint.

ITEM 4. SUBMISSION OF MATTERS TO A VOTE OF SECURITY HOLDERS.

      None.

PART II

ITEM 5. MARKET FOR REGISTRANT’S COMMON EQUITY, RELATED STOCKHOLDER MATTERS AND ISSUER PURCHASES OF EQUITY SECURITIES.

Market for Our Common Stock

      Prior to June 29, 2005, there was no established public trading market for our Class A common stock. Since June 29, 2005, our Class A common stock has traded on the New York Stock Exchange under the symbol “NSR.” As of March 17, 2006, our Class A common stock was held by 66 stockholders of record. The

25

following table sets forth the per-share range of the high and low sales prices of our Class A common stock as reported on the New York Stock Exchange for the periods indicated:

	High		Low
Fiscal year ended December 31, 2005
First quarter		N/A		N/A
Second quarter	$	26.67	$	24.50
Third quarter	$	33.02	$	25.35
Fourth quarter	$	32.95	$	28.85

      There is no established public trading market for our Class B common stock. As of March 17, 2006, our Class B common stock was held by 15 stockholders of record.

Dividends

      We did not pay any cash dividends on our Class A or Class B common stock in 2004 or 2005 and we do not expect to pay any cash dividends on our common stock for the foreseeable future. We currently intend to retain any future earnings to finance our operations and growth. Our revolving credit facility limits our ability to declare or pay dividends. We are also limited by Delaware law in the amount of dividends we can pay. Any future determination to pay cash dividends will be at the discretion of our board of directors and will depend on earnings, financial condition, operating results, capital requirements, any contractual restrictions and other factors that our board of directors deems relevant.

Recent Sales of Unregistered Securities

      Share numbers in the following discussion have been adjusted to give effect to the stock split effected as part of the Recapitalization.

      In February 2005, we issued 35,745 shares of common stock in partial consideration for an acquisition. This issuance was undertaken in reliance upon the exemptions from the registration requirements of the Securities Act of 1933, as amended, afforded by Rule 505 promulgated thereunder, as a limited offering that, among other things, did not exceed $5.0 million. We believe that exemptions other than the foregoing exemption may exist for this transaction.

      Between January 1, 2005 and September 19, 2005, under our equity incentive plans we issued to directors, officers, employees and consultants options to purchase 1,024,844 shares of common stock with per share exercise prices ranging from $10.86 to $27.85, and issued 1,031,155 shares of common stock upon exercise of options during that time. We received aggregate proceeds of $2,096,384 from the payment of the exercise price with respect to such options. These issuances were undertaken in reliance upon the exemptions from the registration requirements of the Securities Act of 1933, including by Rule 701 promulgated thereunder, as transactions pursuant to the compensatory benefit plans and contracts relating to compensation. From January 2005 through February 2005, however, we did not supply the holders of options granted under our equity incentive plan with our financial statements or information about the risks associated with investment in our securities, as required to comply with Rule 701. As a result, shares issued upon exercise of these options were issued in violation of Section 5 of the Securities Act of 1933, and holders of such shares have the right to rescind their purchases, subject to applicable statutes of limitations.

      In December 1999, we issued warrants to acquire 6,361,383 shares of our common stock to affiliates of Warburg Pincus for an aggregate exercise price of approximately $424,000. In connection with the public offering of our common stock in December 2005, these affiliates of Warburg Pincus exercised these warrants. The issuance of the 6,361,383 shares of our Class A common stock upon the exercise of the warrants was undertaken in reliance upon the exemption from the registration requirements of the Securities Act provided by Section 3(a)(9) of the Securities Act. No commission or other remuneration was paid in connection with the issuance of the shares upon the exercise of the warrants. The shares issued upon exercise of these warrants were resold in the public offering of our Class A common stock in December 2005 pursuant to the

26

Registration Statement on Form S-1 (File No. 333-129700), which was declared effective on December 6, 2005, and the Registration Statement on Form S-1 (File No. 333-130176), which was effective upon filing on December 7, 2005 in accordance with Rule 462(b) under the Securities Act of 1933. We believe that exemptions other than the foregoing exemption may exist for this transaction.

ITEM 6. SELECTED FINANCIAL DATA.

      The tables below present selected consolidated statements of operations data for each of the five years ended December 31, 2005 and selected consolidated balance sheet data as of December 31, 2001, 2002, 2003, 2004 and 2005. The selected consolidated statements of operations data for each of the three years ended December 31, 2003, 2004 and 2005, and the selected consolidated balance sheet data as of December 31, 2004 and 2005, have been derived from, and should be read together with, our audited consolidated financial statements and related notes appearing in this report. The selected consolidated statements of operations data for each of the two years ended December 31, 2001 and 2002, and the selected consolidated balance sheet data as of December 31, 2001, 2002 and 2003, have been derived from our audited consolidated financial statements and related notes not included in this report. The share and per share data included in the selected consolidated statements of operations data for the years ended December 31, 2001, 2002, 2003, and 2004 reflect the 1.4-for-1 split of our common stock effected as part of the Recapitalization, but do not reflect other aspects of the Recapitalization.

27

      The following information should be read together with, and is qualified in its entirety by reference to, the more detailed information contained in “Management’s Discussion and Analysis of Financial Condition and Results of Operations” in Item 7 of this report and our consolidated financial statements and related notes in Item 8 of this report.

			Year Ended December 31,
			2001			2002			2003			2004			2005
			(In thousands, except per share data)
Consolidated Statements of Operations Data:
	Total revenue		$	74,176		$	90,972		$	111,693		$	165,001		$	242,469
	Operating expense:
		Cost of revenue (excluding depreciation and amortization shown separately below)		40,770			36,677			37,846			49,261			64,891
		Sales and marketing		27,362			13,855			14,381			22,743			29,543
		Research and development		8,621			6,256			6,678			7,377			11,883
		General and administrative		16,372			13,366			11,359			21,144			28,048
		Depreciation and amortization		10,857			27,020			16,051			17,285			16,025
		Restructuring charges (recoveries)		8,928			7,332			(1,296	)		(220	)		(389	)
		Asset impairment charge		—			13,190			—			—			—
		Amortization of goodwill		3,510			—			—			—			—
				116,420			117,696			85,019			117,590			150,001
	(Loss) income from operations			(42,244	)		(26,724	)		26,674			47,411			92,468
	Other (expense) income:
		Interest expense		(3,416	)		(6,260	)		(3,119	)		(2,498	)		(2,121	)
		Interest income		4,089			1,876			1,299			1,629			2,406
	(Loss) income before minority interest and income taxes			(41,571	)		(31,108	)		24,854			46,542			92,753
	Minority interest			1,326			1,908			10			—			(104	)
	(Loss) income before income taxes			(40,245	)		(29,200	)		24,864			46,542			92,649
	Provision for income taxes			1,250			—			836			1,166			37,251
	Net (loss) income			(41,495	)		(29,200	)		24,028			45,376			55,398
	Dividends on and accretion of preferred stock			(4,888	)		(9,102	)		(9,583	)		(9,737	)		(4,313	)
	Net (loss) income		$	(46,383	)	$	(38,302	)	$	14,445		$	35,639		$	51,085
	Net (loss) income attributable to common stockholders per common share:
		Basic	$	(12.13	)	$	(9.04	)	$	3.09		$	6.33		$	1.48
		Diluted	$	(12.13	)	$	(9.04	)	$	0.31		$	0.57		$	0.72
	Weighted average common shares outstanding:
		Basic		3,825			4,236			4,680			5,632			34,437
		Diluted		3,825			4,236			76,520			80,237			77,046

	As of December 31,
	2001			2002			2003			2004			2005
	(In thousands)
Consolidated Balance Sheet Data:
Cash, cash equivalents and short-term investments	$	33,663		$	21,347		$	63,987		$	63,929		$	103,475
Working capital		3,098			3,633			23,630			38,441			113,296
Goodwill and intangible assets		44,087			44,087			54,751			50,703			54,150
Total assets		199,067			132,544			190,245			211,454			281,771
Deferred revenue and customer credits, excluding current portion		2,175			2,910			14,840			13,892			18,463
Long-term debt and capital lease obligations, excluding current portion		25,234			7,722			5,996			7,964			4,459
Convertible preferred stock, Series B, Series C and Series D		142,356			151,458			161,041			140,454			—
Total stockholders’ (deficit) equity		(49,265	)		(87,300	)		(68,581	)		(31,858	)		186,163

28

ITEM 7. MANAGEMENT’S DISCUSSION AND ANALYSIS OF FINANCIAL CONDITION AND RESULTS OF OPERATIONS.

      You should read the following discussion and analysis in conjunction with the information set forth under “Selected Financial Data” in Item 6 of this report and our consolidated financial statements and related notes in Item 8 of this report. The statements in this discussion related to our expectations regarding our future performance, liquidity and capital resources, and other non-historical statements in this discussion, are forward-looking statements. These forward-looking statements are subject to numerous risks and uncertainties, including, but not limited to, the risks and uncertainties described in “Risk Factors” in Item 1A of this report and “Business — Cautionary Note Regarding Forward-Looking Statements” in Item 1 of this report. Our actual results may differ materially from those contained in or implied by any forward-looking statements.

Overview

      We provide the North American communications industry with essential clearinghouse services. We operate the authoritative directories that manage virtually all telephone area codes and numbers, and we enable the dynamic routing of calls among thousands of competing communications service providers, or CSPs, in the United States and Canada. All CSPs that offer telecommunications services to the public at large, or telecommunications service providers, such as Verizon Communications Inc., Sprint Nextel Corporation, AT&T Corp. and Cingular Wireless LLC, must access our clearinghouse as one of our customers to properly route virtually all of their customers’ calls. We also provide clearinghouse services to emerging CSPs, including Internet service providers, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, we manage the authoritative directories for the .us and .biz Internet domains, as well as for U.S. Common Short Codes, part of the short messaging service relied upon by the U.S. wireless industry.

Our Company

      We were founded to meet the technical and operational challenges of the communications industry when the U.S. government mandated local number portability in 1996. While we remain the provider of the authoritative solution that the communications industry relies upon to meet this mandate, we have developed a broad range of innovative services to meet an expanded range of customer needs. We provide the communications industry in North America with critical technology services that solve the industry’s addressing, interoperability and infrastructure needs of CSPs.

      These services are now used by CSPs to manage a range of their technical and operating requirements, including:

•  Addressing. We enable CSPs to use critical, shared addressing resources, such as telephone numbers, Internet top-level domain names, and U.S. Common Short Codes.

•  Interoperability. We enable CSPs to exchange and share critical operating data so that communications originating on one provider’s network can be delivered and received on the network of another CSP. We also facilitate order management and work flow processing among CSPs.

•  Infrastructure and Other. We enable CSPs to more efficiently manage changes in their own networks by centrally managing certain critical data they use to route communications over their own networks.

      We derive a substantial portion of our annual revenue on a transaction basis, most of which is derived from long-term contracts.

      Our costs and expenses consist of cost of revenue, sales and marketing, research and development, general and administrative, and depreciation and amortization.

      Cost of revenue includes all direct materials, direct labor, and those indirect costs related to generation of revenue such as indirect labor, materials and supplies. Our primary cost of revenue is related to our information technology and systems department, including network costs, data center maintenance, database

29

management, data processing costs, and facilities costs. In addition, cost of revenue includes personnel costs associated with service implementation, product maintenance, customer deployment and customer care, including salaries, stock-based compensation and other personnel-related expense. Cost of revenue also includes costs relating to developing modifications and enhancements of our existing technology and services, as well as royalties paid related to our Common Short Code services.

      Sales and marketing expense consists of personnel costs, advertising costs and relationship marketing costs. This expense includes personnel costs, such as salaries, sales commissions, travel, stock-based compensation, and other personnel-related expense; trade shows; costs of computer and communications equipment and support services; facilities costs; consulting fees; costs of marketing programs, such as Internet and print, including product branding, market analysis and forecasting; and customer relationship management.

      Research and development expense consists primarily of personnel costs, including salaries, stock-based compensation and other personnel-related expense; consulting fees; and the costs of facilities, computer and support services used in service and technology development.

      General and administrative expense consists primarily of personnel costs, including salaries, stock-based compensation, and other personnel-related expense, for our executive, administrative, legal, finance, and human resources functions. General and administrative expense also includes facilities, management information systems, support services, professional services fees, certain audit, tax and license fees, and bad debt expense.

      Depreciation and amortization relates primarily to our property and equipment and includes our network infrastructure and facilities related to our services and the amortization of identifiable intangibles.

Critical Accounting Policies and Estimates

      The discussion and analysis of our financial condition and results of operations are based on our consolidated financial statements, which have been prepared in accordance with U.S. generally accepted accounting principles, or U.S. GAAP. The preparation of these financial statements in accordance with U.S. GAAP requires us to utilize accounting policies and make certain estimates and assumptions that affect the reported amounts of assets and liabilities, the disclosure of contingencies as of the date of the financial statements and the reported amounts of revenue and expense during a fiscal period. The Securities and Exchange Commission considers an accounting policy to be critical if it is important to a company’s financial condition and results of operations, and if it requires significant judgment and estimates on the part of management in its application. We have discussed the selection and development of the critical accounting policies with the audit committee of our board of directors, and the audit committee has reviewed our related disclosures in this report. Although we believe that our judgments and estimates are appropriate and correct, actual results may differ from those estimates.

      We believe the following to be our critical accounting policies because they are important to the portrayal of our financial condition and results of operations and they require critical management judgments and estimates about matters that are uncertain. If actual results or events differ materially from those contemplated by us in making these estimates, our reported financial condition and results of operation for future periods could be materially affected. See Item 1A of this report, “Risk Factors,” for certain matters that may bear on our future results of operations.

Revenue Recognition

      Our revenue recognition policies are in accordance with Securities and Exchange Commission Staff Accounting Bulletin No. 104, Revenue Recognition. We provide the following services pursuant to various private commercial and government contracts.

      Addressing. Our addressing services include telephone number administration, implementing the allocation of pooled blocks of telephone numbers, and directory services for Internet domain names and U.S. Common Short Codes. We generate revenue from our telephone number administration services under

30

two government contracts. Under our contract to serve as the North American Numbering Plan Administrator, we earn a fixed annual fee, and we recognize this fee as revenue on a straight-line basis as services are provided. In the event we estimate losses on our fixed fee contract, we recognize these losses in the period in which a loss becomes apparent. Under our contract to serve as the National Pooling Administrator, we are reimbursed for costs incurred plus a fixed fee associated with administration of the pooling system. We recognize revenue for this contract based on costs incurred plus a pro rata amount of the fixed fee.

      In addition to the administrative functions associated with our role as the National Pooling Administrator, we also generate revenue from implementing the allocation of pooled blocks of telephone numbers under our long-term contracts with North American Portability Management LLC, and we recognize revenue on a per transaction fee basis as the services are performed. For our Internet domain name services, we generate revenue for Internet domain name registrations, which generally have contract terms between one and ten years. We recognize revenue on a straight-line basis over the lives of the related customer contracts. We generate revenue from our Common Short Code services under short-term contracts ranging from three to twelve months, and we recognize revenue on a straight-line basis over the term of the customer contracts.

      Interoperability. Our interoperability services consist primarily of wireline and wireless number portability and order management services. We generate revenue from number portability under our long-term contracts with North American Portability Management LLC and Canadian LNP Consortium, Inc. We recognize revenue on a per transaction fee basis as the services are performed. We provide order management services consisting of customer set-up and implementation followed by transaction processing under contracts with terms ranging from one to three years. Customer set-up and implementation is not considered a separate deliverable; accordingly, the fees are deferred and recognized as revenue on a straight-line basis over the term of the contract. Per-transaction fees are recognized as the transactions are processed.

      Infrastructure and Other. Our infrastructure services consist primarily of network management and connection services. We generate revenue from network management services under our long-term contracts with North American Portability Management LLC. We recognize revenue on a per transaction fee basis as the services are performed. In addition, we generate revenue from connection fees and system enhancements under our contracts with North American Portability Management LLC. We recognize our connection fee revenue as the service is performed. System enhancements are provided under contracts in which we are reimbursed for costs incurred plus a fixed fee. Revenue is recognized based on costs incurred plus a pro rata amount of the fee.

Significant Contracts

      We provide wireline and wireless number portability, implement the allocation of pooled blocks of telephone numbers and provide network management services pursuant to seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States. We recognize revenue under our contracts with North American Portability Management LLC primarily on a per-transaction basis. The aggregate fees for transactions processed under these contracts are determined by the total number of transactions, and these fees are billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share is based on each respective telecommunications service provider’s share of the aggregate end-user services revenues of all U.S. telecommunications service providers as determined by the FCC. On November 4, 2005, BellSouth Corporation filed a petition seeking changes in the way our customers are billed for services provided by us under our contracts with North American Portability Management LLC. Following this filing, the FCC requested comments from interested parties with respect to this petition. As of March 15, 2006, the FCC has not initiated a formal rulemaking process, and the BellSouth petition remains pending. We do not believe that this proposed change to the manner in which we bill for services under these contracts would have a material impact on our customers’ demand for these services. Under our contracts, we also bill a revenue recovery collections, or RRC, fee of a percentage of monthly billings to our customers, which is available to us if any telecommunications service provider fails to pay its allocable share of total transactions charges. If the RRC fee is insufficient for that purpose, these contracts also provide for the recovery of such differences from the remaining telecommunications service providers.

31

      The per-transaction pricing under these contracts provides for annual volume credits that are earned on all transactions in excess of the pre-determined annual volume threshold. For 2005, the maximum aggregate volume credit was $7.5 million, which was applied via a reduction in per-transaction pricing once the pre-determined annual volume threshold was surpassed. When the aggregate credit was fully satisfied, the per-transaction pricing was restored to the prevailing contractual rate. In August 2005, the pre-determined annual transaction volume threshold under these contracts was exceeded, which resulted in the issuance of $7.5 million of volume credits for the year ended December 31, 2005.

      Conversely, billings in 2003 and 2004 continued at the original contractual rate after the annual volume threshold was surpassed. Billings in excess of the discounted pricing were recorded as customer credits (liability) on the consolidated balance sheet with a corresponding reduction to revenue. In the following year when the credits were applied to invoices rendered, customer credits were reduced with a corresponding credit to accounts receivable. The annual pre-determined volume threshold was surpassed in the fourth quarters of 2003 and 2004 resulting in the reduction of revenue and recognition of customer credits of $6.0 million and $11.9 million, respectively.

      In December 2003, these contracts were amended to extend their expiration date from May 2006 to May 2011, and the per-transaction fee charged to our customers over the term of the contracts was reduced. As part of the amendments, we agreed to retroactively apply the new transaction fee to all 2003 transactions processed and granted credits totaling $16.0 million. These credits were applied to customer invoices over a 23-month period beginning in January 2004. Additionally, we obtained letters of credit totaling $16.0 million in January 2004 to secure a portion of these customer credits. As of December 31, 2004, approximately $15.5 million of these customer credits were outstanding; as of December 31, 2005, none of these customer credits were outstanding.

Service Level Standards

      Pursuant to certain of our private commercial contracts, we are subject to service level standards and to corresponding penalties for failure to meet those standards. We record a provision for these performance-related penalties when we become aware that required service levels that would trigger such a penalty have not been met, which results in a corresponding reduction of our revenue.

      For more information regarding how we recognize revenue for each of our service categories, please see the discussion above under “— Revenue Recognition.”

Valuation of Goodwill and Intangible Assets

      Our acquisition of our business from the Lockheed Martin Corporation in November 1999 as well as the acquisitions of BizTelOne, NightFire, fiducianet, and Foretec in January 2003, August 2003, February 2005 and December 2005, respectively, resulted in the recording of goodwill, which represents the excess of the purchase price over the fair value of assets acquired, as well as other definite-lived intangible assets. Under present accounting rules (Statement of Financial Accounting Standards No. 142, Goodwill and Other Intangible Assets), goodwill is no longer subject to amortization; instead it is subject to impairment testing criteria. Other acquired definite-lived intangible assets are being amortized over their estimated useful lives, although those with indefinite lives are not to be amortized but are tested at least annually for impairment, using a lower of cost or fair value approach. We test for impairment on an annual basis or on an interim basis if circumstances change that would indicate the possibility of impairment. The impairment review may require an analysis of future projections and assumptions about our operating performance. If such a review indicates that the assets are impaired, an expense would be recorded for the amount of the impairment, and the corresponding impaired assets would be reduced in carrying value.

Impairment of Long-Lived Assets

      Our long-lived assets primarily consist of property and equipment and intangible assets. In accordance with Statement of Financial Accounting Standards No. 144, Accounting for the Impairment or Disposal of Long-Lived Assets, we evaluate the recoverability of our long-lived assets for impairment whenever events or

32

changes in circumstances indicate the carrying value of such assets may not be recoverable. If an indication of impairment is present, we compare the estimated undiscounted future cash flows to be generated by the asset to its carrying amount. If the undiscounted future cash flows are less than the carrying amount of the asset, we record an impairment loss equal to the excess of the asset’s carrying amount over its fair value. Substantially all of our long-lived assets are located in the United States.

Accounts Receivable, Revenue Recovery Collections, and Allowance for Doubtful Accounts

      Accounts receivable are recorded at the invoiced amount and do not bear interest. In accordance with our contracts with North American Portability Management LLC, we bill a RRC fee of a percentage of monthly billings to our customers. The aggregate RRC fees collected may be used to offset uncollectible receivables from an individual customer. The RRC fees are recorded as an accrued liability when collected. For the period from January 1, 2002 through June 30, 2004, this fee was 3% of monthly billings. On July 1, 2004, the RRC fee was reduced to 2%. On July 1, 2005, the RRC fee was reduced to 1%. Any accrued RRC fees in excess of uncollectible receivables are paid back to the customers annually on a pro rata basis. RRC fees of $4.3 million and $2.5 million are included in accrued expenses as of December 31, 2004 and December 31, 2005, respectively. All other receivables related to services not covered by the RRC fees are evaluated and, if deemed not collectible, are appropriately reserved.

Deferred Income Taxes

      We recognize deferred tax assets and liabilities based on temporary differences between the financial reporting bases and the tax bases of assets and liabilities. These deferred tax assets and liabilities are measured using the enacted tax rates and laws that will be in effect when such amounts are expected to reverse or be utilized. The realization of deferred tax assets is contingent upon the generation of future taxable income. When appropriate, we recognize a valuation allowance to reduce such deferred tax assets to amounts that are more likely than not to be ultimately realized. The calculation of deferred tax assets (including valuation allowances) and liabilities requires us to apply significant judgment related to such factors as the application of complex tax laws, changes in tax laws and our future operations. We review our deferred tax assets on a quarterly basis to determine if a valuation allowance is required based upon these factors. Changes in our assessment of the need for a valuation allowance could give rise to a change in such allowance, potentially resulting in additional expense or benefit in the period of change.

Stock-Based Compensation

      We account for employee stock-based compensation in accordance with the provisions of Accounting Principles Board Opinion No. 25, Accounting for Stock Issued to Employees (APB No. 25) and related interpretations, which require us to recognize compensation cost for the excess of the fair value of the stock at the grant date over the exercise price, if any. An alternative method of accounting would apply the principles of Statement of Financial Accounting Standards (SFAS) No. 123, Accounting for Stock-Based Compensation (SFAS No. 123), which require the fair value of the stock option to be recognized at the date of grant and amortized as compensation expense over the stock option’s vesting period. No stock-based employee compensation cost for stock options is reflected in net income, as all options granted under the plans had an exercise price equal to the market value of the underlying common stock on the date of grant. Stock-based compensation for non-employees is accounted for using the fair value-based method in accordance with SFAS No. 123 and Emerging Issues Task Force Issue No. 96-18, Accounting for Equity Instruments that are Issued to Other than Employees for Acquiring, or in Connection with Selling Goods or Services (EITF 96-18). See the discussion under “— Recent Accounting Pronouncements” below.

Acquisitions

      We have expanded the scope of our services and increased our customer base by selectively acquiring four small businesses. Our objective for each acquisition was to leverage our clearinghouse capabilities in order to maximize efficiency and provide added value to our customers. The stock consideration described below

33

reflects the 1.4-for-1 stock split effected as part of the Recapitalization, but does not reflect the other aspects of the Recapitalization.

BizTelOne, Inc.

      In January 2003, we acquired BizTelOne, Inc. for $2.5 million in cash, plus a $700,000 earn-out amount accrued in 2004, which was paid in March 2005. This acquisition provided us with additional order management service technology and market presence needed to facilitate growth in the revenue generated by our interoperability services.

NightFire Software, Inc.

      In August 2003, we acquired certain assets of NightFire Software, Inc. for $4.1 million in cash (net of $293,000 cash acquired) and the issuance of 855,069 shares of our Class B common stock for total purchase consideration of $7.8 million. NightFire’s products enable fully automated voice, data, and broadband access services fulfillment for competitive local exchange carriers, integrated communications carriers, incumbent local exchange carriers, inter-exchange carriers, Internet service providers, and other types of service providers. This acquisition further expanded our order management services technology and market presence and aided in the growth of our interoperability revenue.

fiducianet, Inc.

      In February 2005, we acquired fiducianet, Inc. for $2.2 million in cash and the issuance of 35,745 shares of our common stock for total purchase consideration of $2.6 million. The acquisition of fiducianet enables us to serve as a single point of contact in managing all day-to-day customer obligations involving subpoenas, court orders and law enforcement agency requests under electronic surveillance laws, including CALEA, the USA Patriot Act of 2001 and the Homeland Security Act of 2002.

Foretec Seminars Inc.

      In December 2005, we acquired Foretec Seminars Inc., a provider of secretariat services to the Internet Engineering Task Force (IETF), from the Corporation for National Research Initiatives (CNRI) for $875,000 in cash, of which $500,000 is payable upon the achievement of certain milestones, as well as the payment of approximately $213,000 in legal fees incurred by CNRI to establish a public trust to administer IETF-related intellectual property. In accordance with Financial Accounting Standards Board (FASB) Statement No. 141, Business Combinations, the $500,000 payable upon the achievement of certain milestones has been included in the purchase consideration since this amount was determinable as of the date of acquisition.

Current Trends Affecting Our Results of Operations

      We have experienced increased demand for our clearinghouse services, which has been driven by market trends such as network expansion to meet subscriber growth, the implementation of new technologies, competitive churn, network changes, carrier vendor churn and consolidations.

      Wireless carriers are expanding their networks to facilitate wireless subscriber growth, to deliver new wireless applications, and to foster wireless competition. As CSPs expand and upgrade their networks and technology to enable the delivery of high-speed wireless services, we anticipate that they will increasingly rely on our services, and wireless-related transactions will remain a major contributor to our transaction volume growth.

      Advancements in the communications industry, such as changes from time division multiplexing, or TDM, to global system for mobile, or GSM, have driven increased infrastructure transactions in our clearinghouse. As the industry migrates towards next-generation technologies and applications, we anticipate that demand for our infrastructure services will increase.

34

      As the communications industry has changed to meet consumer demands and new technological advancements, consolidation among industry participants has increased. Consolidation requires the integration of disparate systems and networks, which has driven increased demand for our addressing, interoperability and infrastructure services. We anticipate that future consolidations will continue to drive growth in our transaction volumes.

      Competition has placed significant pressure on CSPs to reduce costs. At the same time, the complexity of back office operations has increased as CSPs work to manage the proliferation of new technologies and new, complex end-user services provided across a large number of independent networks. Our clearinghouse services assist CSPs in equipping their back office systems to manage the added complexity of sharing essential data with other CSPs in this environment, thereby allowing CSPs to reduce their capital investments and operating expenses. As the CSPs make changes to their back office to remain competitive, we anticipate that demand for our infrastructure services will increase.

      During 2005, addressing transactions increased due to the emergence of IP service providers. In particular, VoIP service providers are expanding their operations. This expansion has led to an increased need for access to inventories of telephone numbers, which has driven demand for our addressing services. We expect continued growth in the number of addressing transactions in 2006 as IP service providers continue to develop an inventory of telephone number resources. In addition, we expect to see increased demand for our infrastructure services as carriers change their networks to facilitate Internet telephony services.

      To support our growth, we will continue to explore opportunities to improve our operating efficiencies. In 2005, we initiated several programs to improve operating efficiencies, such as the utilization of offshore technical resources for systems engineering, implementation of new hardware and software technology in our clearinghouse, and management of process improvement teams. Having become a public company in 2005, we have experienced, and will continue to experience, increases in certain general and administrative expenses to comply with the laws and regulations applicable to public companies. These laws and regulations include the provisions of the Sarbanes-Oxley Act of 2002 and the rules of the Securities and Exchange Commission and the New York Stock Exchange. To comply with the corporate governance and operating requirements of being a public company, we have incurred, and will continue to incur, increases in such items as personnel costs, professional services fees, fees for independent directors and the cost of directors and officers liability insurance. We believe that these costs will approximate $3.0 to $3.5 million annually.

      In 2003 and 2004, we were able to utilize net operating loss carryforwards and deferred tax benefits from previous years to offset taxable income and income tax expense related to U.S. federal income taxes. These carryforwards and deferrals were exhausted in 2004. In 2005, our profits were, and in future years we expect our profits to be, subject to U.S. federal income taxes at the statutory rates.

35

Consolidated Results of Operations

Year Ended December 31, 2004 Compared to the Year Ended December 31, 2005

      The following table presents an overview of our results of operations for the years ended December 31, 2004 and 2005. The 2004 share and per share data in the following table reflect the 1.4-for-1 stock split effected as part of the Recapitalization, but do not reflect the other aspects of the Recapitalization.

					2005			2004 vs. 2005
		2004			$			$ Change			% Change
		(In thousands, except per share data)
Revenue:
	Addressing	$	50,792		$	75,036		$	24,244			47.7	%
	Interoperability		34,228			52,488			18,260			53.3	%
	Infrastructure and other		79,981			114,945			34,964			43.7	%
Total revenue			165,001			242,469			77,468			47.0	%
Operating expense:
	Cost of revenue (excludes depreciation and amortization shown separately below)		49,261			64,891			15,630			31.7	%
	Sales and marketing		22,743			29,543			6,800			29.9	%
	Research and development		7,377			11,883			4,506			61.1	%
	General and administrative		21,144			28,048			6,904			32.7	%
	Depreciation and amortization		17,285			16,025			(1,260	)		(7.3	)%
	Restructuring recoveries		(220	)		(389	)		(169	)		76.8	%
			117,590			150,001			32,411			27.6	%
Income from operations			47,411			92,468			45,057			95.0	%
Other (expense) income:
	Interest expense		(2,498	)		(2,121	)		377			(15.1	)%
	Interest income		1,629			2,406			777			47.7	%
Income before minority interest and income taxes			46,542			92,753			46,211			99.3	%
Minority interest			—			(104	)		(104	)		—
Income before income taxes			46,542			92,649			46,107			99.1	%
Provision for income taxes			1,166			37,251			36,085			3094.8	%
Net income			45,376			55,398			10,022			22.1	%
Dividends on and accretion of preferred stock			(9,737	)		(4,313	)		5,424			(55.7	)%
Net income attributable to common stockholders		$	35,639		$	51,085		$	15,446			43.3	%
Net income attributable to common stockholders per common share:
	Basic	$	6.33		$	1.48
	Diluted	$	0.57		$	0.72
Weighted average common shares outstanding:
	Basic		5,632			34,437
	Diluted		80,237			77,046

36

Revenue

      Total revenue. Total revenue increased $77.5 million due to increases in addressing, interoperability and infrastructure transactions. Contributing to this increase was a contractual reduction in the total volume-based credits available to our customers under our contracts with North American Portability Management LLC, which resulted in an $11.9 million reduction in revenue in 2004, compared to a $7.5 million reduction in 2005.

      Addressing. Addressing revenue increased $24.2 million due to the continued implementation of, and expansion of carrier networks to facilitate, new communications services, such as Internet telephony, as well as growth in the use of U.S. Common Short Codes and other wireless data services. Of this amount, revenue from pooling transactions increased $17.3 million, primarily as service providers continued to build inventories of telephone numbers in multiple area codes and rate centers to be able to offer them to Internet and wireless telephony users. In addition, U.S. Common Short Codes revenue increased $5.5 million due to an increase in the number of subscribers for U.S. Common Short Codes, as well as an increase in the number of service providers that carried U.S. Common Short Codes across their networks. Revenue from our domain name services increased $1.7 million due in large part to the increased number of names under management, offset by a reduction of approximately $0.6 million in our administration fees under our contract to serve as the North American Numbering Plan Administrator.

      Interoperability. Interoperability revenue increased $18.3 million due to an increase in wireline and wireless competition and the associated movement of end users from one CSP to another, carrier consolidation, and broader usage of our expanding service offerings such as enhanced order management services for wireless data and Internet telephony providers. Specifically, revenue from number portability transactions increased $10.5 million, and revenue from our order management services increased $7.1 million.

      Infrastructure and other. Infrastructure and other revenue increased $35.0 million due to an increase in the demand for our network management services. Of this amount, $28.9 million was attributable to customers making changes to their networks that required actions such as disconnects and modifications to network elements. We believe these changes were driven largely by trends in the industry, including the implementation of new technologies by our customers, wireless technology upgrades, carrier vendor changes and network optimization. Connection fees and other revenue increased $5.2 million in 2005 due in part to revenue related to one-time functionality improvements that our customers requested.

Expense

      Cost of revenue. Cost of revenue increased $15.6 million due to growth in personnel, contractor costs to support higher transaction volumes and royalties related to our Common Short Code services. Of this amount, personnel and employee related expense increased $8.6 million due to increased personnel to support our customer deployment group, software engineering group and operations group. Contractor costs increased $4.1 million for software maintenance activities and managing industry changes to our clearinghouse. Additionally, cost of revenue increased by $4.1 million due to royalty expenses related to Common Short Code services and revenue share cost associated with our Internet domain names and registry gateway services. These increases were offset by a $1.2 million decrease in facilities expense, maintenance of hardware and software and other clearinghouse expenses. Cost of revenue as a percentage of revenue decreased from 29.9% for the year ended December 31, 2004 to 26.8% for the year ended December 31, 2005. This decrease in cost of revenue as a percentage of revenue is attributable to operating efficiencies in our clearinghouse operations, which allowed us to increase the number of transactions we processed without proportional increases in personnel costs.

      Sales and marketing. Sales and marketing expense increased $6.8 million due to additions to our sales and marketing team to focus on branding, product launches and new business development opportunities, including international expansion. Of this amount, personnel and employee related expense increased $6.2 million, and costs related to industry events increased $0.3 million. Sales and marketing expense as a percentage of revenue decreased from 13.8% for the year ended December 31, 2004 to 12.2% for the year ended December 31, 2005.

37

      Research and development. Research and development expense increased $4.5 million due to the development of Internet telephony solutions to enhance our service offerings. Of this increase, personnel and employee related costs increased $3.1 million due to increased headcount, and fees for consultants to augment our internal research and development resources increased $0.9 million. Research and development expense as a percentage of revenue increased from 4.5% for the year ended December 31, 2004 to 4.9% for the year ended December 31, 2005.

      General and administrative. General and administrative expense increased $6.9 million primarily due to costs incurred to support business growth and costs incurred in preparation for, and in conjunction with, becoming a public company. We recorded $5.8 million of offering costs related to our public offerings in 2005 and other related expense, which includes legal, accounting and consulting fees. In addition, personnel and employee related expense increased $2.0 million, which was offset in part by a reduction of $0.7 million in general and administrative facility costs. General and administrative expense as a percentage of revenue decreased from 12.8% in the year ended December 31, 2004 to 11.6% for the year ended December 31, 2005.

      Depreciation and amortization. Depreciation and amortization expense decreased $1.3 million due to the expiration of certain capital leases. Depreciation and amortization expense as a percentage of revenue decreased from 10.5% for the year ended December 31, 2004 to 6.6% for the year ended December 31, 2005.

      Restructuring recoveries. In 2005, we recorded a net restructuring recovery of $0.4 million, which included a restructuring recovery of $0.7 million after entering into a sub-lease for our leased property in Chicago with sub-lease rates more favorable than originally assumed when the restructuring liability for the closure of excess facilities was recorded in 2002. This was offset by a restructuring charge of $317,000 for the closure of our facility in Oakland, CA, which was completed on October 31, 2005.

      Interest expense. Interest expense decreased $0.4 million in 2005 as compared to 2004 due to decrease in the number of capital leases. Interest expense as a percentage of revenue decreased from 1.5% for the year ended December 31, 2004 to 0.9% for the year ended December 31, 2005.

      Interest income. Interest income increased $0.8 million due to higher average cash balances. Interest income as a percentage of revenue remained flat at 1% for the year ended December 31, 2005, as compared to the year ended December 31, 2004.

      Provision for income taxes. We recorded a provision for income taxes of $37.3 million in 2005 to reflect the expected 2005 effective tax rate, as compared to $1.2 million in 2004. As of June 30, 2004, we had generated operating profits for six consecutive quarters. As a result of this earnings trend, we determined that it was more likely than not that we would realize our deferred tax assets and reversed approximately $20.2 million of our deferred tax asset valuation allowance. The reversal resulted in the recognition of an income tax benefit of $16.9 million, and a reduction of goodwill of $3.3 million. The benefit was offset by current income tax expense of $7.6 million and deferred income taxes of $10.7 million, resulting in a net income tax expense of $1.2 million for 2004. Our annual effective income tax rate increased from 2.5% for the year ended December 31, 2004 to 40.2% for the year ended December 31, 2005.

38

Year Ended December 31, 2003 Compared to the Year Ended December 31, 2004

      The following table presents an overview of our results of operations for the years ended December 31, 2003 and 2004. The share and per share data in the following table reflect the 1.4-for-1 stock split effected as part of the Recapitalization, but do not reflect the other aspects of the Recapitalization.

		2003			2004			2003 vs. 2004
		$			$			$ Change			% Change
		(In thousands, except per share data)
Revenue:
	Addressing	$	42,905		$	50,792		$	7,887			18.4	%
	Interoperability		16,003			34,228			18,225			113.9	%
	Infrastructure and other		52,785			79,981			27,196			51.5	%
Total revenue			111,693			165,001			53,308			47.7	%
Operating expense:
	Cost of revenue (excludes depreciation and amortization shown separately below)		37,846			49,261			11,415			30.2	%
	Sales and marketing		14,381			22,743			8,362			58.1	%
	Research and development		6,678			7,377			699			10.5	%
	General and administrative		11,359			21,144			9,785			86.1	%
	Depreciation and amortization		16,051			17,285			1,234			7.7	%
	Restructuring recoveries		(1,296	)		(220	)		1,076			83.0	%
			85,019			117,590			32,571			38.3	%
Income from operations			26,674			47,411			20,737			77.7	%
Other (expense) income:
	Interest expense		(3,119	)		(2,498	)		621			(19.9	)%
	Interest income		1,299			1,629			330			25.4	%
Income before minority interest and income taxes			24,854			46,542			21,688			87.3	%
Minority interest			10			—			(10	)		—
Income before minority interest			24,864			46,542			21,678			87.3	%
Provision for income taxes			836			1,166			330			39.5	%
Net income			24,028			45,376			21,348			88.8	%
Dividends on and accretion of preferred stock			(9,583	)		(9,737	)		(154	)		1.6	%
Net income attributable to common stockholders		$	14,445		$	35,639		$	21,194			146.7	%
Net income attributable to common stockholders per common share:
	Basic	$	3.09		$	6.33
	Diluted	$	0.31		$	0.57
Weighted average common shares outstanding:
	Basic		4,680			5,632
	Diluted		76,520			80,237

Revenue

      Total revenue. Total revenue increased $53.3 million due to increases in addressing, interoperability and infrastructure transactions. Revenue from increased transactions was partially offset by annual volume credits

39

under our contracts with North American Portability Management LLC, based on our exceeding pre-determined annual transaction volume thresholds under those contracts. The impact of this volume credit was $11.9 million in 2004, which was recognized in the fourth quarter and reduced fourth quarter revenue.

      Addressing. Addressing revenue increased $7.9 million due primarily to the growth in the number of wireless customers, the increase in new communications services being offered by our customers and the continued expansion of carrier networks. Of this amount, revenue from pooling transactions increased $7.7 million, primarily as service providers built inventories of telephone numbers in multiple area codes and rate centers to be able to offer them to VoIP users. Carrier consolidation also required the use of our pooling service to reallocate pooled blocks of telephone numbers to consolidated networks. In addition, U.S. Common Short Codes revenue increased $2.4 million, reflecting a full year of this service, which commenced in October 2003. These increases were offset by a reduction of $2.5 million in our administration fees under our contract to serve as the North American Numbering Plan Administrator, reflecting the revised lower pricing under the new contract awarded to us in January 2004.

      Interoperability. Interoperability revenue increased $18.2 million due to an increase in wireless competition, carrier consolidation and our expanding service offerings, such as order management services for wireless data. Specifically, revenue from number portability increased $9.6 million, and revenue from our order management services, which we initiated in the third quarter of 2003, increased $8.4 million.

      Infrastructure and other. Infrastructure and other revenue increased $27.2 million due to an increase in the demand for our network management services. Revenue of $31.0 million was attributable to customers making changes to their networks that required actions such as disconnects and modifications to network elements. We believe these changes were driven largely by the implementation of new technologies by our customers, wireless technology upgrades and network optimization after carrier consolidation. This increase was offset by a $3.8 million decrease in connections fees and other revenue.

Expense

      Cost of revenue. Cost of revenue increased $11.4 million due to growth in personnel and employee-related expenses and contractor costs to support higher transaction volumes. Of this amount, personnel and employee-related expenses increased by $3.9 million to support our customer deployment and information technology and systems groups, along with increased contractor costs of $5.2 million for the conversion of acquired software platforms to the clearinghouse. Additionally, cost of revenue increased by $2.1 million due to royalty expenses primarily related to Common Short Code services and revenue share cost associated with our Internet domain name registry gateway services. Cost of revenue as a percentage of revenue decreased from 33.9% for the year ended December 31, 2003 to 29.9% for the year ended December 31, 2004. This decrease in cost of revenue as a percentage of revenue is attributable to operating efficiencies in our clearinghouse operations, which allowed us to increase the number of transactions we processed without proportional increases in personnel costs.

      Sales and marketing. Sales and marketing expense increased $8.4 million due to growth in personnel and employee-related expenses to focus on branding and product launches. Of this amount, personnel and employee-related expenses increased $6.7 million as we expanded our sales and marketing team. In addition, external costs related to branding and product launch accounted for $0.9 million of the increase. Sales and marketing expense as a percentage of revenue increased from 12.9% for the year ended December 31, 2003 to 13.8% for the year ended December 31, 2004.

      Research and development. Research and development expense increased $0.7 million due to an increase in personnel and employee-related expenses. Research and development expense as a percentage of revenue decreased from 6.0% for the year ended December 31, 2003 to 4.5% for the year ended December 31, 2004.

      General and administrative. General and administrative expense increased $9.8 million primarily due to costs incurred to support business growth and in preparation for becoming a public company. These costs include executive additions, systems and process controls and professional fees. General and administrative

40

personnel cost increased $4.6 million, attributable in part to stock-based compensation of $2.1 million. Professional fees and other legal expenses increased $3.4 million. General and administrative expense as a percentage of revenue increased from 10.2% for the year ended December 31, 2003 to 12.8% for the year ended December 31, 2004.

      Depreciation and amortization. Depreciation and amortization expense increased $1.2 million due to an increase in capital assets to support increased transaction volume. Depreciation and amortization expense as a percentage of revenue decreased from 14.4% for the year ended December 31, 2003 to 10.5% for the year ended December 31, 2004. This decrease in depreciation and amortization expense as a percentage of revenue reflects improvement in asset utilization.

      Restructuring recoveries. In 2002, we disposed of property and equipment from operations and recorded a restructuring liability that included penalties for the cancellation of facility leases, resulting in a charge of $7.3 million. In 2004, $0.2 million of these charges were recovered as a result of updates to the assumptions used in the establishment of the restructuring accrual in 2003.

      Interest expense. Interest expense decreased $0.6 million as a result of lower interest charges on outstanding notes as principal was reduced, as well as a decrease in the number of capital leases. Interest expense as a percentage of revenue decreased from 2.8% for the year ended December 31, 2003 to 1.5% for the year ended December 31, 2004.

      Interest income. Interest income increased $0.3 million due to higher average cash balances in 2004 compared to 2003. Interest income as a percentage of revenue decreased from 1.2% for the year ended December 31, 2003 to 1.0% for the year ended December 31, 2004.

      Provision for income taxes. We recorded a provision for income taxes of $1.2 million for the year ended December 31, 2004, as compared to a provision for income taxes of $0.8 million for the year ended December 31, 2003. As of June 30, 2004, we had generated operating profits for six consecutive quarters. As a result of this earnings trend, we determined that it was more likely than not that we would realize our deferred tax assets and reversed approximately $20.2 million of our deferred tax asset valuation allowance. The reversal resulted in the recognition of an income tax benefit of $16.9 million and a reduction of goodwill of $3.3 million. The benefit was offset by current income tax expense of $7.6 million and deferred income taxes of $10.7 million, resulting in a net income tax expense of $1.2 million.

Liquidity and Capital Resources

      Our principal source of liquidity has been cash provided by operations. Our principal uses of cash have been to fund facility expansions, capital expenditures, acquisitions, working capital, dividend payouts on preferred stock, and debt service requirements. We anticipate that our principal uses of cash in the future will be facility expansion, capital expenditures, acquisitions and working capital.

      Total cash and cash equivalents and short-term investments were $63.9 million at December 31, 2004, increasing to $103.5 million at December 31, 2005. As of December 31, 2005, we had $4.3 million available under the revolving loan commitment of our bank credit facility, subject to the terms and conditions of that facility.

      We believe that our existing cash and cash equivalents, short-term investments and cash from operations will be sufficient to fund our operations for the next twelve months.

      As part of the Recapitalization, we paid accrued and unpaid dividends on our preferred stock of approximately $6.3 million. On June 28, 2005, all of the preferred stock was converted into common stock, and no dividends are currently accruing. We have paid or expect to pay offering costs, excluding underwriting discounts and commissions, and other related expenses totaling $5.8 million in connection with our initial public offering and the additional offering of our common stock in December 2005.

41

Discussion of Cash Flows

Cash flows from operations

      Net cash provided by operating activities for the year ended December 31, 2005 was $61.2 million, as compared to $64.7 million for the year ended December 31, 2004. This $3.5 million decrease in net cash provided by operating activities was principally the result of a net decrease in changes in operating assets and liabilities of approximately $33.3 million. This decrease was offset by a net increase in adjustments to reconcile net income to net cash flow provided by operating activities of approximately $19.7 million, which was predominantly due to an adjustment of approximately $17.0 million related to the tax benefit from the exercise of stock options.

Cash flows from investing

      Net cash used in investing activities was $46.5 million for the year ended December 31, 2005, compared to $54.4 million for the year ended December 31, 2004. This $7.9 million decrease in net cash used in investing activities was principally due to a reduction in purchases of short-term investments of $10.1 million and a decrease in purchases of property and equipment of $0.4 million, offset by the purchase of two businesses for $2.5 million.

Cash flows from financing

      Net cash used in financing activities was $6.2 million for the year ended December 31, 2005, compared to $51.5 million for the year ended December 31, 2004. This $45.3 million decrease in net cash used in financing activities was principally the result of the following: a decrease of $24.1 million in the payment of preferred stock dividends, and a $5.6 million increase in proceeds received from the exercise of common stock options; a decrease of $10.4 million for required letters of credit relating to our December 2003 contract amendments with North American Portability Management LLC; and a decrease of $6.0 million in repayments of notes payable and capital leases, offset by a decrease of $2.2 million in proceeds from the issuance of notes payable.

Contractual Obligations

      Our principal commitments consist of obligations under leases for office space, computer equipment and furniture and fixtures. The following table summarizes our long-term contractual obligations as of December 31, 2005.

Payments Due by Period

			Less Than						More Than
	Total		1 Year		1-3 Years		4-5 Years		5 Years
	(In thousands)
Capital lease obligations	$	9,923	$	6,346	$	3,577	$	—	$	—
Operating lease obligations		21,373	$	4,765	$	12,729	$	3,879	$	—
Long-term debt		2,251	$	1,232	$	1,019	$	—	$	—
Total	$	33,547	$	12,343	$	17,325	$	3,879	$	—

Debt and Credit Facilities

      We have a revolving credit facility, which provides us with up to $15 million in available credit. Borrowings under the revolving credit facility may be either base rate loans or Eurodollar rate loans. There were no outstanding borrowings under this facility at December 31, 2004 and December 31, 2005; however, total available borrowings were reduced by outstanding letters of credit of $1.8 million and $10.7 million at December 31, 2004 and December 31, 2005, respectively, which reduce the amount we may borrow under the revolving credit facility. Base rate loans bear interest at a fluctuating rate per annum equal to the higher of the federal funds rate plus 0.5% or the lender’s prime rate. Eurodollar rate loans bear interest at the Eurodollar

42

rate plus the applicable margin. Our obligations under the revolving credit facility are secured by all of our assets (other than the assets of NeuLevel, Inc., our subsidiary, and the receivables securing our obligations under our receivables facility) and our interest in NeuLevel.

      Under the terms of the revolving credit facility, we must comply with certain financial covenants, such as maintaining minimum levels of consolidated net worth, quarterly consolidated EBITDA and liquid assets and not exceeding certain levels of capital expenditures and leverage ratios. Additionally, there are negative covenants that limit our ability to declare or pay dividends, acquire additional indebtedness, incur liens, dispose of significant assets, make acquisitions or significantly change the nature of our business without the permission of the lender. During 2003, 2004 and 2005, we were not in compliance with certain covenants and obtained waivers for such defaults.

      We also have a receivables facility under which we borrowed $10.1 million, secured by, and payable from the proceeds of, certain receivables. An independent third party administers the collections of these receivables. As the receivables are collected, the third party pays the bank directly for all secured amounts on a monthly basis, thereby reducing the amounts outstanding under the facility. Minimum payments of $1 million against principal have been due every six months since January 2004, and all amounts outstanding are due February 1, 2007. We have guaranteed a portion of the receivables facility (less than 10% of the outstanding principal balance) but are otherwise not liable for the collection of amounts owed under the secured receivables. The receivables facility bears interest at the reserve adjusted one month LIBOR rate plus 2%.

Effect of Inflation

      Inflation generally affects us by increasing our cost of labor and equipment. We do not believe that inflation had any material effect on our results of operations during the years ended December 31, 2003, 2004 and 2005.

Recent Accounting Pronouncements

      On December 16, 2004, and as amended on April 14, 2005, the FASB issued Statement No. 123 (revised 2004), Share-Based Payment (SFAS No. 123(R)), which is a revision of FASB Statement No. 123, Accounting for Stock-Based Compensation. SFAS No. 123(R) supersedes APB Opinion No. 25, Accounting for Stock Issued to Employees, and amends FASB Statement No. 95, Statement of Cash Flows. Generally, the approach in SFAS No. 123(R) is similar to the approach described in SFAS No. 123. However, SFAS No. 123(R) requires all share-based payments to employees, including grants of employee stock options, to be recognized in the statement of operations based on their fair values. Pro forma disclosure is no longer an alternative. As permitted by SFAS No. 123, in 2005 and in prior years, we accounted for share-based payments to employees using the intrinsic value method of APB Opinion No. 25 and, as such, generally did not recognize compensation cost for employee stock options.

      We will adopt the provisions of SFAS No. 123(R) for the fiscal quarter beginning on January 1, 2006 using the modified prospective transition method and therefore will not restate prior periods. Application of this pronouncement requires us to make significant judgments regarding the variables in an option pricing model in order to determine fair value, including stock price volatility and employee exercise behavior. Most of these variables are either highly dependent on the economic environment at the date of grant or over the expected term of the award. We are currently evaluating the requirements of SFAS No. 123(R) and expect that the adoption of SFAS No. 123(R) will have a material impact on our consolidated results of operations. Had we adopted SFAS No. 123(R) in prior periods, the impact of that standard would have approximated the impact of SFAS No. 123 as described in the disclosure of pro forma net income and earnings per share in Note 2 to our Consolidated Financial Statements. SFAS No. 123(R) also requires the benefits of tax deductions in excess of recognized compensation cost to be reported as a financing cash flow, rather than as an operating cash flow as required under current accounting guidance. This requirement will reduce net operating cash flows and increase net financing cash flows in periods after adoption. While we cannot estimate what those amounts will be in the future (because they depend on, among other things, when employees exercise

43

stock options), the amount of operating cash flows recognized in prior periods for such excess tax deductions was approximately $0, $0 and $17.0 million in 2003, 2004 and 2005, respectively.

Off-Balance Sheet Arrangements

      We had no off-balance sheet arrangements as of December 31, 2004 and 2005.

ITEM 7A. QUANTITATIVE AND QUALITATIVE DISCLOSURES ABOUT MARKET RISK.

      We are subject to market risk associated with changes in foreign currency exchange rates and interest rates. Our exchange rate risk related to foreign currency exchange is due to our number portability contract with Canadian LNP Consortium, Inc. Based on this agreement, we recognize revenue on a per transaction basis as the services are performed and bill for these services using the Canadian dollar at a fixed exchange rate that is updated annually. As a result, we are affected by currency fluctuations in the value of the U.S. dollar as compared to the Canadian dollar. The net impact of foreign exchange rate fluctuations on earnings was not material for the years ended December 31, 2003, 2004 or 2005, respectively.

      Interest rate exposure is primarily limited to the approximately $75.9 million of short-term investments owned by us at December 31, 2005. Such investments consist principally of commercial paper, high-grade auction rate securities and U.S. government or corporate debt securities. We do not actively manage the risk of interest rate fluctuations on our short-term investments; however, such risk is mitigated by the relatively short-term nature of these investments. For the year ended December 31, 2005, a one-percentage point adverse change in interest rates would have reduced our interest income for the year ended December 31, 2005 by approximately $650,000. In addition, we do not consider the present rate of inflation to have a material impact on our business.

44

ITEM 8. FINANCIAL STATEMENTS AND SUPPLEMENTARY DATA.

INDEX TO CONSOLIDATED FINANCIAL STATEMENTS

	Page
Report of Independent Registered Public Accounting Firm		46
Consolidated Balance Sheets as of December 31, 2004 and 2005		47
Consolidated Statements of Operations for the years ended December 31, 2003, 2004 and 2005		49
Consolidated Statements of Stockholders’ (Deficit) Equity for the years ended December 31, 2003, 2004 and 2005		50
Consolidated Statements of Cash Flows for the years ended December 31, 2003, 2004 and 2005		51
Notes to Consolidated Financial Statements		52

45

REPORT OF INDEPENDENT REGISTERED PUBLIC ACCOUNTING FIRM

Board of Directors and Stockholders

NeuStar, Inc.

      We have audited the accompanying consolidated balance sheets of NeuStar, Inc. as of December 31, 2004 and 2005, and the related consolidated statements of operations, stockholders’ (deficit) equity, and cash flows for each of the three years in the period ended December 31, 2005. Our audits also included the financial statement schedule listed in the Index at Item 15(a)(2). These financial statements and schedule are the responsibility of the Company’s management. Our responsibility is to express an opinion on these financial statements and schedule based on our audits.

      We conducted our audits in accordance with the standards of the Public Company Accounting Oversight Board (United States). Those standards require that we plan and perform the audit to obtain reasonable assurance about whether the financial statements are free of material misstatement. We were not engaged to perform an audit of the Company’s internal control over financial reporting. Our audits included consideration of internal control over financial reporting as a basis for designing audit procedures that are appropriate in the circumstances, but not for the purpose of expressing an opinion on the effectiveness of the Company’s internal control over financial reporting. Accordingly, we express no such opinion. An audit includes examining, on a test basis, evidence supporting the amounts and disclosures in the financial statements, assessing the accounting principles used and significant estimates made by management, and evaluating the overall financial statement presentation. We believe that our audits provide a reasonable basis for our opinion.

      In our opinion, the financial statements referred to above present fairly, in all material respects, the consolidated financial position of NeuStar, Inc. at December 31, 2004 and 2005, and the consolidated results of its operations and its cash flows for each of the three years in the period ended December 31, 2005, in conformity with U.S. generally accepted accounting principles. Also, in our opinion, the related financial statement schedule, when considered in relation to the basic financial statements taken as a whole, present fairly in all material respects the information set forth therein.

/s/ Ernst & Young LLP

McLean, Virginia

March 10, 2006

46

NEUSTAR, INC.

CONSOLIDATED BALANCE SHEETS

(In thousands, except share and per share data)

		December 31,
		2004		2005
ASSETS
Current assets:
	Cash and cash equivalents	$	19,019	$	27,529
	Restricted cash		4,835		374
	Short-term investments		44,910		75,946
	Accounts receivable, net of allowance for doubtful accounts of $468 and $494, respectively		29,171		30,982
	Unbilled receivables		980		6,394
	Securitized notes receivable		3,325		1,074
	Notes receivable		965		—
	Prepaid expenses and other current assets		3,747		8,054
	Deferred costs		2,359		4,819
	Income taxes receivable		—		14,595
	Deferred tax asset		10,923		12,216
Total current assets			120,234		181,983
Restricted cash, long-term			835		—
Property and equipment, net			36,504		39,627
Goodwill			49,453		51,495
Intangibles assets, net			1,250		2,655
Securitized notes receivable, long-term			1,074		—
Deferred costs, long-term			2,012		5,454
Other assets			961		557
Total assets		$	212,323	$	281,771

See accompanying notes.

47

NEUSTAR, INC.

CONSOLIDATED BALANCE SHEETS

(In thousands, except share and per share data)

		December 31,
		2004			2005
LIABILITIES AND STOCKHOLDERS’ (DEFICIT) EQUITY
Current liabilities:
	Accounts payable	$	2,828		$	4,119
	Accrued expenses		32,630			36,880
	Income taxes payable		419			—
	Customer credits		15,541			—
	Deferred revenue		14,761			20,006
	Notes payable		4,636			1,232
	Capital lease obligations		4,813			5,540
	Accrued restructuring reserve		1,330			536
Total current liabilities			76,958			68,313
Deferred revenue, long-term			13,892			18,463
Notes payable, long-term			1,358			1,019
Capital lease obligations, long-term			6,606			3,440
Accrued restructuring reserve, long-term			3,719			2,572
Other liabilities			—			500
Deferred tax liability			1,194			1,197
Total liabilities			103,727			95,504
Minority interest			—			104
Commitments and contingencies			—			—
Series B Voting Convertible Preferred Stock, $0.01 par value; 4,000,000 shares authorized; 100,000 shares issued and outstanding at December 31, 2004; liquidation preference of $66 at December 31, 2004			66			—
Series C Voting Convertible Preferred Stock, $0.01 par value; 28,600,000 shares authorized; 28,569,692 shares issued and outstanding at December 31, 2004; liquidation preference of $85,717 at December 31, 2004			85,717			—
Series D Voting Convertible Preferred Stock, $0.01 par value; 10,000,000 shares authorized; 9,098,525 shares issued and outstanding at December 31, 2004; liquidation preference of $54,817 at December 31, 2004			54,671			—
Stockholders’ (deficit) equity:
	Preferred stock, $0.001 par value; 100,000,000 shares authorized; No shares issued or outstanding as of December 31, 2004 and 2005		—			—
	Class A common stock, $0.001 par value; 200,000,000 shares authorized; No shares issued or outstanding as of December 31, 2004; 68,150,690 shares issued and outstanding as of December 31, 2005		—			68
	Class B common stock, $0.001 par value; 100,000,000 shares authorized; 6,159,985 and 199,152 shares issued and outstanding as of December 31, 2004 and 2005, respectively		6			—
	Additional paid-in capital		—			163,741
	Deferred stock compensation		(1,733	)		(1,446	)
	Treasury stock, 236,366 shares at cost at December 31, 2004		(1,125	)		—
	(Accumulated deficit) retained earnings		(29,006	)		23,800
Total stockholders’ (deficit) equity			(31,858	)		186,163
Total liabilities and stockholders’ (deficit) equity		$	212,323		$	281,771

See accompanying notes.

48

NEUSTAR, INC.

CONSOLIDATED STATEMENTS OF OPERATIONS

(In thousands, except per share data)

		Year Ended December 31,
		2003			2004			2005
Revenue:
	Addressing	$	42,905		$	50,792		$	75,036
	Interoperability		16,003			34,228			52,488
	Infrastructure and other		52,785			79,981			114,945
Total revenue			111,693			165,001			242,469
Operating expense:
	Cost of revenue (excluding depreciation and amortization shown separately below)		37,846			49,261			64,891
	Sales and marketing		14,381			22,743			29,543
	Research and development		6,678			7,377			11,883
	General and administrative		11,359			21,144			28,048
	Depreciation and amortization		16,051			17,285			16,025
	Restructuring recoveries		(1,296	)		(220	)		(389	)
			85,019			117,590			150,001
Income from operations			26,674			47,411			92,468
Other (expense) income:
	Interest expense		(3,119	)		(2,498	)		(2,121	)
	Interest income		1,299			1,629			2,406
Income before minority interest and income taxes			24,854			46,542			92,753
Minority interest			10			—			(104	)
Income before income taxes			24,864			46,542			92,649
Provision for income taxes			836			1,166			37,251
Net income			24,028			45,376			55,398
Dividends on and accretion of preferred stock			(9,583	)		(9,737	)		(4,313	)
Net income attributable to common stockholders		$	14,445		$	35,639		$	51,085
Net income attributable to common stockholders:
	Basic	$	3.09		$	6.33		$	1.48
	Diluted	$	0.31		$	0.57		$	0.72
Weighted average common shares outstanding:
	Basic		4,680			5,632			34,437
	Diluted		76,520			80,237			77,046

See accompanying notes.

49

NEUSTAR, INC.

CONSOLIDATED STATEMENT OF STOCKHOLDERS’ (DEFICIT) EQUITY

(In thousands)

		Class A				Class B																		(Accumulated			Total
		Common Stock				Common Stock						Additional			Common Stock			Deferred						Deficit)			Stockholders’
												Paid-In			Subscription			Stock			Treasury			Retained			(Deficit)
		Shares		Amount		Shares			Amount			Capital			Receivable			Compensation			Stock			Earnings			Equity
Balance at December 31, 2002			—	$	—		4,447		$	4		$	—		$	(155	)	$	(44	)	$	—		$	(87,105	)	$	(87,300	)
	Shares issued for acquisition of NightFire Software, Inc.		—		—		882			1			3,776			—			—			—			—			3,777
	Common stock options exercised		—		—		220			—			39			—			—			—			—			39
	Repayment of executive promissory notes		—		—		—			—			—			155			—			—			—			155
	Compensation expense associated with options issued to nonemployees		—		—		—			—			287			—			—			—			—			287
	Amortization of deferred stock compensation		—		—		—			—			—			—			16			—			—			16
	Accretion of preferred stock and related dividends		—		—		—			—			(4,102	)		—			—			—			(5,481	)		(9,583	)
	Net income		—		—		—			—			—			—			—			—			24,028			24,028
Balance at December 31, 2003			—		—		5,549			5			—			—			(28	)		—			(68,558	)		(68,581	)
	Common stock options exercised		—		—		611			1			90			—			—			—			—			91
	Deferred stock compensation expense associated with issuance of restricted stock units		—		—		—			—			2,187			—			(2,187	)		—			—			—
	Repurchase of common stock		—		—		—			—			—			—			—			(1,012	)		—			(1,012	)
	Return of common stock originally issued for acquisition of NightFire Software, Inc		—		—		—			—			—			—			—			(113	)		—			(113	)
	Compensation expense associated with options issued to nonemployees		—		—		—			—			654			—			—			—			—			654
	Compensation expense associated with repurchase of immature shares		—		—		—			—			982			—			—			—			—			982
	Accretion of preferred stock and related dividends		—		—		—			—			(3,913	)		—			—			—			(5,824	)		(9,737	)
	Amortization of deferred stock compensation		—		—		—			—			—			—			482			—			—			482
	Net income		—		—		—			—			—			—			—			—			45,376			45,376
Balance at December 31, 2004			—		—		6,160			6			—			—			(1,733	)		(1,125	)		(29,006	)		(31,858	)
	Common stock options exercised		—		—		466			1			246			—			—			—			—			247
	Compensation expense associated with options issued to nonemployees		—		—		—			—			2,214			—			—			—			—			2,214
	Shares issued for acquisition of fiducianet, Inc.		—		—		36			—			388			—			—			—			—			388
	Retirement of treasury stock		—		—		(236	)		—			(1,125	)		—			—			1,125			—			—
	Accretion of preferred stock and related dividends		—		—		—			—			(1,721	)		—			—			—			(2,592	)		(4,313	)
	Issuance of Class B common stock pursuant to conversion of convertible preferred stock		—		—		53,435			53			138,452			—			—			—			—			138,505
	Conversion of Class B common stock to Class A common stock		59,662		60		(59,662	)		(60	)		—			—			—			—			—			—
	Deferred stock compensation expense associated with issuance of restricted stock		5		—		—			—			160			—			(160	)		—			—			—
	Amortization of deferred stock compensation		—		—		—			—			—			—			447			—			—			447
	Common stock options exercised		2,122		2		—			—			7,709			—			—			—			—			7,711
	Warrants exercised		6,362		6		—			—			418			—			—			—			—			424
	Tax benefit from stock option exercises		—		—		—			—			17,000			—			—			—			—			17,000
	Net income		—		—		—			—			—			—			—			—			55,398			55,398
Balance at December 31, 2005			68,151	$	68		199		$	—		$	163,741		$	—		$	(1,446	)	$	—		$	23,800		$	186,163

See accompanying notes.

50

NEUSTAR, INC.

CONSOLIDATED STATEMENTS OF CASH FLOWS

(In thousands)

		Year Ended December 31,
		2003			2004			2005
Operating activities:
Net income		$	24,028		$	45,376		$	55,398
Adjustments to reconcile net income to net cash provided by operating activities:
	Depreciation and amortization		16,051			17,285			16,025
	Stock compensation		303			2,118			2,661
	Amortization of deferred financing costs		533			150			57
	Tax benefit from stock option exercises		—			—			17,000
	Deferred income taxes		—			(6,419	)		(2,289	)
	Noncash restructuring recoveries		(1,295	)		(220	)		(389	)
	Provision for doubtful accounts		184			960			551
	Minority interest		—			—			104
Changes in operating assets and liabilities, net of acquisitions:
	Accounts receivable		(10,396	)		(7,697	)		(3,810	)
	Unbilled receivables		4,726			139			(5,414	)
	Notes receivable		2,753			4,938			4,290
	Prepaid expenses and other current assets		(32	)		(1,524	)		(1,570	)
	Deferred costs		(2,633	)		(869	)		(5,902	)
	Income tax receivable		—			—			(14,595	)
	Other assets		(257	)		(102	)		658
	Accounts payable and accrued expenses		8,628			11,119			6,396
	Income taxes payable		375			44			(419	)
	Accrued restructuring reserve		(3,507	)		(386	)		(1,551	)
	Customer credits		21,000			(5,459	)		(15,541	)
	Deferred revenue		12,426			5,279			9,542
	Net cash provided by operating activities		72,887			64,732			61,202
Investing activities:
	Purchases of property and equipment		(8,186	)		(13,271	)		(12,890	)
	Sales (purchases) of investments, net		1,845			(41,155	)		(31,036	)
	Businesses acquired, net of cash acquired		(8,089	)		—			(2,540	)
	Net cash used in investing activities		(14,430	)		(54,426	)		(46,466	)
Financing activities:
	Disbursement (release) of restricted cash		493			(5,112	)		5,296
	Proceeds from issuance of notes payable		12,037			2,166			—
	Principal repayments on notes payable		(16,104	)		(9,823	)		(5,406	)
	Principal repayments on capital lease obligations		(10,342	)		(7,505	)		(5,939	)
	Proceeds from exercise of common stock options		39			91			5,661
	Proceeds from exercise of warrants		—			—			424
	Payment of preferred stock dividends		—			(30,324	)		(6,262	)
	Repayment of common stock subscriptions		155			—			—
	Repurchase of common stock		—			(1,012	)		—
	Payment of deferred financing fees		(250	)		—			—
	Net cash used in financing activities		(13,972	)		(51,519	)		(6,226	)
Net increase (decrease) in cash and cash equivalents			44,485			(41,213	)		8,510
Cash and cash equivalents at beginning of year			15,747			60,232			19,019
Cash and cash equivalents at end of year		$	60,232		$	19,019		$	27,529
Supplemental cash flow information:
	Cash paid for interest	$	1,673		$	1,693		$	1,377
	Cash paid for income taxes	$	836		$	7,291		$	37,583

See accompanying notes.

51

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS

1. DESCRIPTION OF BUSINESS AND ORGANIZATION

      NeuStar, Inc. (the Company) was incorporated as a Delaware corporation in 1998. The Company provides the North American communications industry with essential clearinghouse services. The Company operates the authoritative directories that manage virtually all telephone area codes and numbers, and enable the dynamic routing of calls among thousands of competing communication service providers, or CSPs, in the United States and Canada. The Company also provides clearinghouse services to emerging CSPs, including Internet service providers, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, the Company manages the authoritative directories for the .us and .biz Internet domains, as well as for U.S. Common Short Codes, part of the short messaging service, or SMS, relied on by the U.S. wireless industry.

      The Company provides its services from its clearinghouse, which includes unique databases and systems for workflow and transaction processing. These services are used by CSPs to solve a range of their technical and operating requirements, including:

•  Addressing. The Company enables CSPs to use critical, shared addressing resources, such as telephone numbers, several Internet domain names, and U.S. Common Short Codes.

•  Interoperability. The Company enables CSPs to exchange and share critical operating data so that communications originating on one provider’s network can be delivered and received on the network of another CSP. The Company also facilitates order management and work flow processing among CSPs.

•  Infrastructure and Other. The Company enables CSPs to more efficiently manage changes in their own networks by centrally managing certain critical data they use to route communications over their own networks.

      On June 28, 2005, the Company effected a recapitalization, which involved (i) the payment of $6.3 million for all accrued and unpaid dividends on all of the then-outstanding shares of preferred stock, followed by the conversion of such shares into shares of common stock, (ii) the amendment of the Company’s certificate of incorporation to provide for Class A common stock and Class B common stock, (iii) and the split of each share of common stock into 1.4 shares and the reclassification of the common stock into shares of Class B common stock (collectively, the “Recapitalization”). Each share of Class B common stock is convertible at the option of the holder into one share of Class A common stock.

      On June 28, 2005, the Company made an initial public offering of 31,625,000 shares of Class A common stock, which included the underwriters’ over-allotment option exercise of 4,125,000 shares of Class A common stock. All the shares of Class A common stock sold in the initial public offering were sold by selling stockholders and, as such, the Company did not receive any proceeds from that offering. Prior to the Company’s initial public offering, holders of 100,000 shares of Series B Voting Convertible Preferred Stock, 28,569,692 shares of Series C Voting Convertible Preferred Stock, and 9,098,525 shares of Series D Voting Convertible Preferred Stock converted their shares into 500,000, 28,569,692, and 9,098,525 shares of the Company’s common stock, respectively, after which the split by means of a reclassification, as described in clauses (ii) and (iii) of the previous paragraph, was effected.

      The accompanying consolidated financial statements give retroactive effect to the amendment of the Company’s certificate of incorporation to provide for Class A common stock and Class B common stock and the split of each share of common stock into 1.4 shares and the reclassification of the common stock into shares of Class B common stock, as though these events occurred at the beginning of the earliest period presented.

52

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

2. SUMMARY OF SIGNIFICANT ACCOUNTING POLICIES

Basis of Presentation and Consolidation

      The consolidated financial statements include the accounts of the Company and its majority-owned subsidiaries. All material intercompany transactions and accounts have been eliminated in consolidation. The Company consolidates investments where it has a controlling financial interest as defined by Accounting Research Bulletin (ARB) No. 51, Consolidated Financial Statements, as amended by Statement of Financial Accounting Standards (SFAS) No. 94, Consolidation of all Majority-Owned Subsidiaries. The usual condition for controlling financial interest is ownership of a majority of the voting interest and, therefore, as a general rule ownership, directly or indirectly, of more than 50% of the outstanding voting shares is a condition indicating consolidation. Minority interest is recorded in the statement of operations for the share of losses absorbed by minority shareholders to the extent that the minority shareholder’s investment in the subsidiary does not fall below zero. For investments in variable interest entities, as defined by Financial Accounting Standards Board (FASB) Interpretation No. 46, Consolidation of Variable Interest Entities, the Company would consolidate when it is determined to be the primary beneficiary of a variable interest entity. For those investments in entities where the Company has significant influence over operations, but where the Company neither has a controlling financial interest nor is the primary beneficiary of a variable interest entity, the Company follows the equity method of accounting pursuant to Accounting Principles Board (APB) Opinion No. 18, The Equity Method of Accounting for Investments in Common Stock. The Company does not have any variable interest entities or investments accounted for under the equity method of accounting.

Use of Estimates

      The preparation of financial statements in conformity with U.S. generally accepted accounting principles requires management to make estimates and assumptions that affect the reported amounts of assets and liabilities, the disclosure of contingent assets and liabilities at the date of the financial statements and the reported amounts of revenue and expense during the reporting periods. Actual results could differ from those estimates.

Reclassifications

      Certain amounts in the prior years’ financial statements have been reclassified to conform to the current year presentation.

Fair Value of Financial Instruments

      SFAS No. 107, Disclosures about Fair Value of Financial Instruments, requires disclosures of fair value information about financial instruments, whether or not recognized in the balance sheet, for which it is practicable to estimate that value. Due to their short-term nature, the carrying amounts reported in the consolidated financial statements approximate the fair value for cash and cash equivalents, accounts receivable, accounts payable and accrued expenses. As of December 31, 2004 and 2005, the Company believes the carrying value of its long-term notes receivable approximates fair value as the interest rates approximate a market rate. The fair value of the Company’s long-term debt is based upon quoted market prices for the same and similar issuances giving consideration to quality, interest rates, maturity and other characteristics. As of December 31, 2004 and 2005, the Company believes the carrying amount of its long-term debt approximates its fair value since the fixed and variable interest rates of the debt approximate a market rate.

53

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Cash and Cash Equivalents

      The Company considers all highly liquid investments, which are readily convertible into cash and have original maturities of three months or less at the time of purchase, to be cash equivalents. Supplemental non-cash information to the consolidated statements of cash flows is as follows:

	Year Ended December 31,
	2003		2004			2005
	(In thousands)
Fixed assets acquired through capital leases	$	7,433	$	8,054		$	3,470
Fixed assets acquired through notes payable		1,154		1,359			1,002
Accounts payable incurred to purchase fixed assets		1,539		125			79
Business acquired with common shares (see Note 3)		3,777		(113	)		388
Dividends to preferred stockholders		9,334		2,095			—

Restricted Cash

      At December 31, 2004 and 2005, approximately $5.7 million and $374,000, respectively, of cash was pledged as collateral on outstanding letters of credit related to 2003 customer credits and lease obligations and was classified as restricted cash on the consolidated balance sheets.

Derivatives and Hedging Activities

      The Company recognizes all derivative financial instruments in the consolidated financial statements at fair value regardless of the purpose or intent for holding the instrument, in accordance with SFAS No. 133, Accounting for Derivative Instruments and Hedging Activities, as amended. Changes in the fair value of derivative financial instruments are either recognized periodically in the results of operations or in stockholders’ (deficit) equity as a component of other comprehensive income, depending on whether the derivative financial instrument qualifies for hedge accounting and, if so, whether it qualifies as a fair value hedge or cash flow hedge. Generally, changes in the fair value of the derivatives accounted for as fair value hedges are recorded in the results of operations along with the portions of the changes in the fair values of the hedged items that relate to the hedged risks. Changes in fair value of derivatives accounted for as cash flow hedges, to the extent they are effective as hedges, are recorded in other comprehensive income. Changes in fair values of derivatives not qualifying as hedges are reported in the results of operations.

      In October 2003, the Company entered into an interest rate swap agreement to manage our interest rate exposure under our 2003 Receivables Facility (see Note 9). The interest rate swap does not meet the criteria under SFAS No. 133 to qualify for hedge accounting treatment. Accordingly, changes in the fair value of the instrument are recorded in earnings. The fair value of the interest rate swap was not significant at December 31, 2004 and 2005.

Concentrations of Credit Risk

      Financial instruments that are potentially subject to a concentration of credit risk consist principally of cash equivalents and accounts receivable. Cash investment policies are in place that restrict placement of these instruments to financial institutions evaluated as highly creditworthy.

      With respect to accounts receivable, the Company performs ongoing evaluations of its customers, generally granting uncollateralized credit terms to its customers, and maintains an allowance for doubtful accounts based on historical experience and management’s expectations of future losses. Customers under the Company’s contracts with North American Portability Management LLC are charged a Revenue Recovery

54

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Collection fee (See Accounts Receivable, Revenue Recovery Collection and Allowance for Doubtful Accounts).

Short-term Investments

      Investments in debt and equity securities that have readily determinable fair values are accounted for as available-for-sale securities. Available-for-sale securities are stated at fair value as determined by the most recently traded price of each security at the balance sheet date, with the unrealized gains and losses recorded as a component of other comprehensive income. The specific-identification method is used to compute the realized gains and losses on debt and equity securities. As of December 31, 2004 and 2005, the carrying value of the investments approximated their fair value and there were no unrealized gains or losses. As of December 31, 2004 and 2005, these investments consisted principally of commercial paper, high-grade auction rate securities and U.S. government or corporate debt securities.

Accounts Receivable, Revenue Recovery Collections and Allowance for Doubtful Accounts

      Accounts receivable are recorded at the invoiced amount and do not bear interest. In accordance with the Company’s contracts with North American Portability Management LLC, the Company bills a Revenue Recovery Collections (RRC) fee to offset uncollectible receivables from any individual customer. The RRC fee is based on a percentage of monthly billings. From January 1, 2003 through June 30, 2004, the RRC fee was 3%. On July 1, 2004, the RRC fee was reduced to 2%. On July 1, 2005, the RRC fee was reduced to 1%. The RRC fees are recorded as an accrued liability when collected. If the RRC fee is insufficient the amounts can be recovered from the customers. Any accrued RRC fees in excess of uncollectible receivables are paid back to the customers annually on a pro rata basis. RRC fees of $4.3 million and $2.5 million are included in accrued expenses as of December 31, 2004 and 2005, respectively. All other receivables related to services not covered by the RRC fees are evaluated and, if deemed not collectible, are reserved. The Company recorded an allowance for doubtful accounts of $468,000 and $494,000 as of December 31, 2004 and 2005, respectively. Bad debt expense amounted to $184,000, $960,000 and $551,000 for the years ended December 31, 2003, 2004 and 2005, respectively.

Deferred Financing Costs

      The Company amortizes deferred financing costs using the effective-interest method and records such amortization as interest expense. Amortization of debt discount and annual commitment fees for unused portions of available borrowings are also recorded as interest expense.

Property and Equipment

      Property and equipment, including leasehold improvements and assets acquired through capital leases, are recorded at cost, net of accumulated depreciation and amortization. Depreciation and amortization of property and equipment are determined using the straight-line method over the estimated useful lives of the assets, as follows:

Computer hardware	3-5 years
Equipment	5 years
Furniture and fixtures	5-7 years
Leasehold improvements	Lesser of related lease term or useful life

      Amortization expense of capital leased assets is included in depreciation and amortization expense in the consolidated statements of operations. Replacements and major improvements are capitalized; maintenance and repairs are charged to expense as incurred.

55

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

      The Company capitalizes software development and acquisition costs in accordance with Statement of Position (SOP) No. 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use. SOP No. 98-1 requires the capitalization of costs incurred in connection with developing or obtaining software for internal use. Costs incurred to develop the application are capitalized, while costs incurred for planning the project and for post-implementation training and maintenance are expensed as incurred. The capitalized costs of purchased technology and software development are amortized using the straight-line method over the estimated useful life of three to five years. During the years ended December 31, 2004 and 2005, the Company capitalized costs related to internal use software of $9.1 million and $8.2 million, respectively. Amortization expense related to internal use software for the years ended December 31, 2003, 2004 and 2005 was $5.3 million, $5.5 million and $3.7 million, respectively and is included in depreciation and amortization expense in the consolidated statements of operations.

Goodwill

      Goodwill represents the excess of costs over fair value of assets of businesses acquired. Goodwill and intangible assets that are determined to have an indefinite useful life are not amortized, but instead tested for impairment annually in accordance with the provisions of SFAS No. 142, Goodwill and Other Intangible Assets.

      The Company performs its annual impairment analysis on October 1 of each year or more often if indicators of impairment arise. The impairment review may require an analysis of future projections and assumptions about the Company’s operating performance. If such a review indicates that the assets are impaired, an expense would be recorded for the amount of the impairment, and the corresponding impaired assets would be reduced in carrying value. The Company performed its annual impairment test with regard to the carrying value of goodwill on October 1, 2004 and 2005 and determined that goodwill was not impaired at those dates.

Identifiable Intangible Assets

      Identifiable intangible assets are amortized over their respective estimated useful lives using a method of amortization that reflects the pattern in which the economic benefits of the intangible assets are consumed or otherwise used up and are reviewed for impairment in accordance with SFAS No. 144, Accounting for Impairment or Disposal of Long-Lived Assets.

      The Company’s identifiable intangible assets are amortized as follows:

	Years		Method
Acquired technologies		4		Straight-line
Customer lists		3 to 5		Various

      Amortization expense related to acquired technologies and customer lists are included in depreciation and amortization expense in the consolidated statements of operations.

Impairment of Long-Lived Assets

      In accordance with SFAS No. 144, Accounting for the Impairment or Disposal of Long-Lived Assets, a review of long-lived assets for impairment is performed when events or changes in circumstances indicate the carrying value of such assets may not be recoverable. If an indication of impairment is present, the Company compares the estimated undiscounted future cash flows to be generated by the asset to its carrying amount. If the undiscounted future cash flows are less than the carrying amount of the asset, the Company records an impairment loss equal to the excess of the asset’s carrying amount over its fair value. The fair value is determined based on valuation techniques such as a comparison to fair values of similar assets or using a

56

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

discounted cash flow analysis. There were no impairment charges recognized during the years ended December 31, 2003, 2004 or 2005.

Revenue Recognition

      The Company provides the North American communications industry with essential clearinghouse services that address the industry’s addressing, interoperability, and infrastructure needs. The Company’s revenue recognition policies are in accordance with the Securities and Exchange Commission Staff Accounting Bulletin No. 104, Revenue Recognition.

      The Company provides the following services pursuant to various private commercial and government contracts.

Addressing

      The Company’s addressing services include telephone number administration, implementing the allocation of pooled blocks of telephone numbers, and directory services for Internet domain names and U.S. Common Short Codes. The Company generates revenue from its telephone number administration services under two government contracts. Under its contract to serve as the North American Numbering Plan Administrator, the Company earns a fixed annual fee and recognizes this fee as revenue on a straight-line basis as services are provided. In the event the Company estimates losses on its fixed fee contract, the Company recognizes these losses in the period in which a loss becomes apparent. Under the Company’s contract to serve as the National Pooling Administrator, the Company is reimbursed for costs incurred plus a fixed fee associated with administration of the pooling system. The Company recognizes revenue for this contract based on costs incurred plus a pro rata amount of the fixed fee.

      In addition to the administrative functions associated with its role as the National Pooling Administrator, the Company also generates revenue from implementing the allocation of pooled blocks of telephone numbers under our long-term contracts with North American Portability Management LLC, and the Company recognizes revenue on a per transaction fee basis as the services are performed. For its Internet domain name services, the Company generates revenue for Internet domain registrations, which generally have contract terms between one and ten years. The Company recognizes revenue on a straight-line basis over the lives of the related customer contracts. The Company generates revenue from its Common Short Code services under short-term contracts ranging from three to twelve months, and the Company recognizes revenue on a straight-line basis over the term of the customer contracts.

Interoperability

      The Company’s interoperability services consist primarily of wireline and wireless number portability and order management services. The Company generates revenue from number portability under its long-term contracts with North American Portability Management LLC and Canadian LNP Consortium, Inc. The Company recognizes revenue on a per transaction fee basis as the services are performed. The Company provides order management services (OMS), consisting of customer set-up and implementation followed by transaction processing, under contracts with terms ranging from one to three years. Customer set-up and implementation is not considered a separate deliverable; accordingly, the fees are deferred and recognized as revenue on a straight-line basis over the term of the contract. Per-transaction fees are recognized as the transactions are processed.

Infrastructure and Other

      The Company’s infrastructure services consist primarily of network management and connection fees. The Company generates revenue from network management services under its long-term contracts with

57

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

North American Portability Management LLC. The Company recognizes revenue on a per transaction fee basis as the services are performed. In addition, the Company generates revenue from connection fees and system enhancements under its contracts with North American Portability Management LLC. The Company recognizes its connection fee revenue as the service is performed. System enhancements are provided under contracts in which the Company is reimbursed for costs incurred plus a fixed fee, and revenue is recognized based on costs incurred plus a pro rata amount of the fee.

Significant Contracts

      The Company provides wireline and wireless number portability, implements the allocation of pooled blocks of telephone numbers and provides network management services pursuant to seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States. The Company recognizes revenue under its contracts with North American Portability Management LLC primarily on a per-transaction basis. The aggregate fees for transactions processed under these contracts are determined by the total number of transactions, and these fees are billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share is based on each respective telecommunications service provider’s share of the aggregate end-user services revenues of all U.S. telecommunications service providers as determined by the Federal Communications Commission (FCC). Under the Company’s contracts, the Company also bills an RRC fee of a percentage of monthly billings to its customers, which is available to the Company if any telecommunications service provider fails to pay its allocable share of total transactions charges. In the period in which the RRC fees are billed, the RRC fees are recorded as an accrued expense (see Note 8) on the consolidated balance sheet, with a corresponding increase to accounts receivable. If the RRC fee is insufficient for that purpose, these contracts also provide for the recovery of such differences from the remaining telecommunications service providers. On an annual basis, (i) the Company evaluates the RRC fee reserve by comparing cash collections to billings and the RRC percentage is adjusted, and (ii) any excess RRC fee reserve is returned to the telecommunications service providers in accordance with the terms of these contracts.

      The per-transaction pricing under these contracts provides for annual volume credits that are earned on all transactions in excess of the pre-determined annual volume threshold. For 2005, the maximum aggregate volume credit was $7.5 million, which was applied via a reduction in per-transaction pricing once the pre-determined annual volume threshold was surpassed. When the aggregate credit was fully satisfied, the per-transaction pricing was restored to the prevailing contractual rate. In August 2005, the pre-determined annual transaction volume threshold under these contracts was exceeded, which resulted in the issuance of $7.5 million of volume credits for the year ended December 31, 2005.

      Conversely, billings in 2003 and 2004 continued at the original contractual rate after the annual volume threshold was surpassed. Billings in excess of the discounted pricing were recorded as customer credits (liability) on the consolidated balance sheet with a corresponding reduction to revenue. In the following year when the credits were applied to invoices rendered, customer credits were reduced with a corresponding credit to accounts receivable. The annual pre-determined volume threshold was surpassed in the fourth quarters of 2003 and 2004 resulting in the reduction of revenue and recognition of customer credits of $6.0 million and $11.9 million, respectively.

      In December 2003, these contracts were amended to extend their expiration date from May 2006 to May 2011, and the per-transaction fee charged to the Company’s customers over the term of the contracts was reduced. As part of the amendments, the Company agreed to retroactively apply the new transaction fee to all 2003 transactions processed and granted credits totaling $16.0 million. These credits were applied to customer invoices over a 23-month period beginning in January 2004. Additionally, the Company obtained letters of credit totaling $16.0 million in January 2004 to secure these customer credits. As of December 31, 2004,

58

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

approximately $15.5 million of these customer credits were outstanding. As of December 31, 2005, no customer credits were outstanding. The amount of the Company’s revenue derived under its contracts with North American Portability Management LLC was $84.5 million $130.0 million, and $188.8 million for the years ended December 31, 2003, 2004 and 2005, respectively.

Service Level Standards

      Pursuant to certain of the Company’s private commercial contracts, the Company is subject to service level standards and to corresponding penalties for failure to meet those standards. The Company records a provision for these performance-related penalties when it becomes aware that required service levels that would trigger such a penalty have not been met, which results in a corresponding reduction to revenue.

Cost of Revenue and Deferred Costs

      Cost of revenue includes all direct materials, direct labor, and those indirect costs related to revenue such as indirect labor, materials and supplies and facilities cost.

      Deferred costs represent direct labor related to professional services incurred for the setup and implementation on contracts. These costs are recognized in cost of revenue ratably over the contract term. Deferred costs are classified as such on the consolidated balance sheet for the periods presented.

Research and Development

      The Company expenses its research and development costs as incurred. Research and development expense consists primarily of personnel costs, including salaries, stock-based compensation and other personnel-related expense; consulting fees; and the costs of facilities, computer and support services used in service and technology development.

Advertising

      The Company expenses advertising as incurred. Advertising expense was approximately $1.2 million, $447,000 and $809,000 for the years ended December 31, 2003, 2004 and 2005, respectively.

Accounting for Stock-Based Compensation

      SFAS No. 123, Accounting for Stock-Based Compensation, as amended by SFAS No. 148, Accounting for Stock-Based Compensation — Transition and Disclosure, an amendment of SFAS No. 123 (SFAS No. 123), allows companies to account for stock-based compensation using either the provisions of SFAS No. 123 or the provisions of APB Opinion No. 25, Accounting for Stock Issued to Employees, but requires pro forma disclosure in the notes to the financial statements as if the measurement provisions of SFAS No. 123 had been adopted. The Company accounts for its stock-based employee compensation in accordance with APB No. 25. Stock compensation expense to nonemployees has been determined in accordance with SFAS No. 123 and Emerging Issues Task Force (EITF) Issue No. 96-18, Accounting for Equity Instruments that are Issued to Other than Employees for Acquiring, or in Connection with Selling Goods or Services (EITF 96-18) and represents the fair value of the consideration received or the fair value of the equity instrument issued, whichever may be more reliably measured. For options that have not reached a measurement date under EITF 96-18, the fair value of the options granted to nonemployees is remeasured at each reporting date.

59

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

      The following table illustrates the effect on net income attributable to common stockholders and net income attributable to common stockholders per common share if the Company had applied the fair value recognition provisions of SFAS No. 123 to stock-based compensation (in thousands, except per share data):

		Year Ended December 31,
		2003			2004			2005
Pro forma basic net income attributable to common stockholders:
	Basic net income attributable to common stockholders, as reported	$	14,445		$	35,639		$	51,085
	Add: stock-based compensation expense included in reported net income attributable to common stockholders		303			2,065			1,607
	Deduct: total stock-based compensation expense determined under fair value-based method for all awards		(2,794	)		(6,707	)		(6,282	)
Pro forma basic net income attributable to common stockholders		$	11,954		$	30,997		$	46,410
Pro forma diluted net income attributable to common stockholders:
	Basic net income attributable to common stockholders, as reported	$	14,445		$	35,639		$	51,085
	Dividends on and accretion of convertible preferred stock		9,583			9,737			4,313
	Diluted net income attributable to common stockholders		24,028			45,376			55,398
	Add: stock-based compensation expense included in reported net income attributable to common stockholders		303			2,065			1,607
	Deduct: total stock-based compensation expense determined under fair value-based method for all awards		(2,794	)		(6,707	)		(6,282	)
Pro forma diluted net income attributable to common stockholders		$	21,537		$	40,734		$	50,723
Net income attributable to common stockholders per common share:
Basic — as reported		$	3.09		$	6.33		$	1.48
Basic — pro forma		$	2.55		$	5.50		$	1.35
Diluted — as reported		$	0.31		$	0.57		$	0.72
Diluted — pro forma		$	0.28		$	0.51		$	0.66

      The effect of applying SFAS No. 123 on pro forma net income attributable to common stockholders as stated above is not necessarily representative of the effects on reported net income attributable to common stockholders for future years due to, among other things, the vesting period of the stock options and the fair value of additional options to be granted in the future years.

      For the purposes of the disclosure required by SFAS No. 123, the weighted-average fair value of each option granted during the years ended December 2003, 2004 and 2005 was $2.51, $3.92 and $11.19, respectively. The fair value of each option is estimated on the date of grant using the Black-Scholes option-

60

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

pricing model with the following assumptions used for grants issued during the years ended December 31, 2003, 2004, 2005:

	Year Ended December 31,
	2003			2004			2005
Dividend yield		0.00	%		0.00	%		0.00	%
Expected volatility		71.43	%		67.14	%		61.38	%
Average risk-free interest rate		3.08	%		3.43	%		3.95	%
Expected term		5 years			5 years			5 years

Basic and Diluted Net Income Attributable to Common Stockholders per Common Share

      Basic net income attributable to common stockholders per common share excludes dilution for potential common stock issuances and is computed by dividing net income attributable to common stockholders by the weighted-average number of common shares outstanding for the period. Diluted net income attributable to common stockholders per common share reflects the potential dilution that could occur if securities or other contracts to issue common stock were exercised or converted into common stock. The following table provides a reconciliation of the numerators and denominators used in computing basic and diluted net income attributable to common stockholders per common share (in thousands, except per share data):

			Year Ended December 31,
			2003			2004			2005
Basic net income attributable to common stockholders per common share:
	Net income		$	24,028		$	45,376		$	55,398
	Dividends on and accretion of convertible preferred stock			(9,583	)		(9,737	)		(4,313	)
Basic net income attributable to common stockholders			$	14,445		$	35,639		$	51,085
Basic net income attributable to common stockholders per common share			$	3.09		$	6.33		$	1.48
Diluted net income attributable to common stockholders per common share:
		Basic net income attributable to common stockholders	$	14,445		$	35,639		$	51,085
		Dividends on and accretion of convertible preferred stock		9,583			9,737			4,313
Diluted net income attributable to common stockholders			$	24,028		$	45,376		$	55,398
Diluted net income attributable to common stockholders per common share			$	0.31		$	0.57		$	0.72
Weighted average common shares outstanding — basic				4,680			5,632			34,437
Dilutive effect of:
	Stock options for the purchase of common stock			6,820			7,515			10,163
	Conversion of preferred stock and accrued dividends payable into common stock			58,755			60,801			26,453
	Warrants for the purchase of common stock			6,265			6,289			5,993
Weighted average common shares outstanding — diluted				76,520			80,237			77,046

61

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Income Taxes

      The Company accounts for income taxes in accordance with SFAS No. 109, Accounting for Income Taxes. Under SFAS No. 109, the liability method is used in accounting for income taxes. Under this method, deferred tax assets and liabilities are determined based on differences between financial reporting and tax bases of assets and liabilities and are measured using the enacted tax rate and laws that will be in effect when the differences are expected to reverse. Deferred tax assets are reduced by a valuation allowance if it is more likely than not that some portion or all of the deferred tax asset will not be realized.

Segment Information

      The Company currently operates in one business segment; namely providing critical technology services to the communications industry. The Company is not organized by market and is managed and operated as one business. A single management team reports to the chief operating decision maker who comprehensively manages the entire business. The Company does not operate any material separate lines of business or separate business entities with respect to its services. Accordingly, the Company does not accumulate discrete financial information with respect to separate service lines and does not have separately reportable segments as defined by SFAS No. 131, Disclosure About Segments of an Enterprise and Related Information.

      Substantially all of the Company’s material identifiable assets are located in the United States. Revenue derived from international sales was $5.6 million, $5.2 million and $7.0 million for the years ended December 31, 2003, 2004 and 2005.

Comprehensive Income

      There were no material differences between net income and comprehensive net income for the years ended December 31, 2003, 2004 and 2005.

Recent Accounting Pronouncements

      On December 16, 2004, and as amended on April 14, 2005, the FASB issued Statement No. 123 (revised 2004), Share-Based Payment (SFAS No. 123(R)), which is a revision of FASB Statement No. 123, Accounting for Stock-Based Compensation. SFAS No. 123(R) supersedes APB Opinion No. 25, Accounting for Stock Issued to Employees, and amends FASB Statement No. 95, Statement of Cash Flows. Generally, the approach in SFAS No. 123(R) is similar to the approach described in SFAS No. 123. However, SFAS No. 123(R) requires all share-based payments to employees, including grants of employee stock options, to be recognized in the statement of operations based on their fair values. Pro forma disclosure is no longer an alternative. As permitted by SFAS No. 123, in 2005 and in prior years, the Company accounted for share-based payments to employees using the intrinsic value method of APB Opinion No. 25 and, as such, generally did not recognize compensation cost for employee stock options.

      The Company will adopt the provisions of SFAS No. 123(R) for the fiscal quarter beginning on January 1, 2006 using the modified prospective transition method and therefore will not restate prior periods. Application of this pronouncement requires management to make significant judgments regarding the variables in an option pricing model in order to determine fair value, including stock price volatility and employee exercise behavior. Most of these variables are either highly dependent on the economic environment at the date of grant or over the expected term of the award. The Company is currently evaluating the requirements of SFAS No. 123(R) and expects that the adoption of SFAS No. 123(R) will have a material impact on its consolidated results of operations. Had the Company adopted SFAS No. 123(R) in prior periods, the impact of that standard would have approximated the impact of SFAS No. 123 as described in the disclosure of pro forma net income and earnings per share in Note 2 to the Company’s Consolidated Financial Statements. SFAS No. 123(R) also requires the benefits of tax deductions in excess of recognized

62

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

compensation cost to be reported as a financing cash flow, rather than as an operating cash flow as required under current accounting guidance. This requirement will reduce net operating cash flows and increase net financing cash flows in periods after adoption. While the Company cannot estimate what those amounts will be in the future (because they depend on, among other things, when employees exercise stock options), the amount of operating cash flows recognized in prior periods for such excess tax deductions was approximately $0, $0 and $17.0 million in 2003, 2004 and 2005, respectively.

3. ACQUISITIONS

BizTelOne, Inc.

      In January 2003, the Company acquired BizTelOne, Inc. (BTO) for $2.5 million in cash. The acquisition provided technology and market presence needed to facilitate growth of the Company’s order management services. The acquisition was accounted for as a purchase and the results of operations of BTO have been included in the accompanying consolidated statements of operations since the date of the acquisition.

      The Company allocated the purchase price principally to acquired technology ($937,000) and goodwill ($2.1 million), and recorded liabilities assumed of $489,000. Acquired technology is included in intangible assets (see Note 7) and is being amortized on a straight-line basis over four years.

      In connection with the purchase, the Company was obligated to pay additional consideration over a two-year period to BTO’s former shareholders if certain levels of revenue were achieved by BTO in 2004. The Company accrued $700,000 at December 31, 2004 with a corresponding increase to goodwill for settlement of the earnout, which was paid in March 2005.

NightFire Software, Inc.

      In August 2003, the Company acquired certain assets of NightFire Software Inc. (NightFire) for $4.1 million in cash (net of $293,000 cash acquired) and the issuance of 881,435 shares of common stock for total purchase consideration of $7.9 million. NightFire’s products enabled fully automated voice, data, and broadband access services fulfillment for competitive local exchange carriers, integrated communications carriers, incumbent local exchange carriers, inter-exchange carriers, Internet service providers, and other types of service providers. The acquisition of NightFire continued the expansion of the Company’s order management services to telecommunication service providers.

      The common stock of the Company was valued at $4.29 per share, which approximated fair market value, on the date of the acquisition. Of the total shares issued, approximately 294,000 shares of common stock were held in escrow for a period of nine months, ending May 2004, pursuant to an indemnification clause in the purchase agreement. The value of these shares has been included in the purchase consideration at the date of acquisition.

      The acquisition was accounted for as a purchase and accordingly, the results of operations of the acquired business have been included in the accompanying consolidated statements of operations since the date of the acquisition. The purchase price was allocated to acquired technology ($1.3 million), customer lists ($996,000), and goodwill ($5.7 million) based on their estimated fair values on the acquisition date. Acquired technology and customer lists are included in intangible assets. Acquired technology is being amortized on an accelerated basis over four years, and customer lists are being amortized on a straight-line basis over three years.

      In July 2004, 267,446 shares of common stock were released from escrow and the Company recorded a purchase price adjustment of approximately $113,000 for the value of 26,366 shares of common stock that were returned to the Company with an offsetting reduction to goodwill. The shares returned to the Company were held in Treasury as of December 31, 2004 and were retired in May 2005.

63

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

fiducianet, Inc.

      In February 2005, the Company acquired fiducianet, Inc. (Fiducianet) for $2.2 million in cash and the issuance of 35,745 shares of common stock for total purchase consideration of $2.6 million. The acquisition of Fiducianet enables the Company to serve as a single point of contact in managing all day-to-day customer obligations involving subpoenas, court orders and law enforcement agency requests under electronic surveillance laws including the Communications Assistance for Law Enforcement, Patriot and Homeland Security Acts. The acquisition was accounted for as a purchase, and the results of Fiducianet have been included in the accompanying consolidated statements of operations since the date of the acquisition.

      The Company allocated the purchase price principally to customer lists ($2.6 million) and goodwill ($1.1 million) based on their estimated fair values on the acquisition date. Customer lists are included in intangible assets and are being amortized on a straight-line basis over five years. In accordance with SFAS No. 109, Accounting for Income Taxes, the Company recorded a deferred tax liability of approximately $1.0 million with an offset to goodwill.

Foretec Seminars Inc.

      In December 2005, the Company acquired Foretec Seminars, Inc. (Foretec) a provider of secretariat services to the Internet Engineering Task Force (IETF), from the Corporation for National Research Initiatives (CNRI) for $875,000 in cash, of which $500,000 is payable upon the achievement of certain milestones, as well as the payment of approximately $213,000 in legal fees incurred by CNRI to establish a public trust to administer IETF-related intellectual property. In accordance with FASB Statement No. 141, Business Combinations (SFAS No. 141), the $500,000 payable upon the achievement of certain milestones has been included in the purchase consideration since this amount was determinable as of the date of acquisition.

      The acquisition was accounted for as a purchase and accordingly, the results of Foretec have been included in the accompanying consolidated statements of operations since the date of the acquisition. The purchase price was allocated to net liabilities assumed of approximately $53,000 and goodwill ($929,000) based on their estimated fair values on the acquisition date.

4. SECURITIZED NOTES RECEIVABLE

      The Company has receivables for functionality upgrades on behalf of its customers under its Statement of Work (SOW) contracts with North American Portability Management LLC. At the option of these customers, payment of these securitized notes receivable is made over 36 months from completion of the contract. The obligations, which are unsecured, accrue interest monthly on the unpaid balance. The interest charges range from 7.3% to 9.6% per annum. Payments are received from each customer for its pro-rata share of the obligation under the SOW contracts.

5. DEFERRED FINANCING COSTS

      During 2003, 2004 and 2005, the Company paid $250,000, $0 and $0, respectively, in loan origination fees that are being amortized using the effective-interest method over the term of the related debt. Total amortization expense was approximately $496,000, $150,000 and $57,000 for the years ended December 31, 2003, 2004 and 2005, respectively, and is reported as interest expense in the consolidated statements of operations. As of December 31, 2004 and 2005, the balance of unamortized deferred financing fees was $65,000 and $7,000, respectively, and is included within other noncurrent assets.

64

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

6. PROPERTY AND EQUIPMENT

      Property and equipment consists of the following (in thousands):

	December 31,
	2004			2005
Computer hardware	$	26,245		$	32,608
Equipment		312			969
Furniture and fixtures		2,176			2,537
Leasehold improvements		11,852			14,781
Construction in-progress		3,002			1,927
Capitalized software		25,099			33,091
		68,686			85,913
Accumulated depreciation and amortization		(32,182	)		(46,286	)
Property and equipment, net	$	36,504		$	39,627

      The Company entered into capital lease obligations of $8.1 million and $3.5 million for the years ended December 31, 2004 and 2005, respectively, primarily for equipment and furniture.

      In 2003, the Company revised the estimated useful life related to certain systems as the Company expected to replace the affected systems in 2004. As a result, the Company accelerated depreciation based on the revised useful life for an amount totaling $686,000 in 2003. Depreciation and amortization expense for the years ended December 31, 2003, 2004 and 2005 was $16.1 million, $17.3 million and $16.0 million, respectively.

7. GOODWILL AND INTANGIBLE ASSETS

      Goodwill consists of the following (in thousands):

	December 31,
	2004		2005
Goodwill	$	49,453	$	51,495

      Intangible assets consist of the following (in thousands):

		December 31,						Weighted-Average
								Amortization Period
		2004			2005			(In Years)
Intangible assets:
	Customer lists	$	996		$	3,566			4.4
	Accumulated amortization		(704	)		(1,441	)
	Customer lists, net		292			2,125
	Acquired technology		2,208			2,208			4.0
	Accumulated amortization		(1,250	)		(1,678	)
	Acquired technology, net		958			530
Intangible assets, net		$	1,250		$	2,655

      Amortization expense related to other intangible assets for the years ended December 31, 2003, 2004 and 2005 of approximately $629,000, $1.3 million and $1.2 million, respectively, is included in depreciation and

65

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

amortization expense. Amortization expense related to other intangibles for the years ended December 31, 2006, 2007, 2008, 2009 and 2010 is expected to be approximately $858,000, $726,000, $514,000, $514,000 and $43,000, respectively.

8. ACCRUED EXPENSES

      Accrued expenses consist of the following (in thousands):

	December 31,
	2004		2005
Accrued wages	$	15,656	$	23,254
RRC reserve		4,289		2,501
Other		12,685		11,125
	$	32,630	$	36,880

9. NOTES PAYABLE

      Notes payable consist of the following (in thousands):

	December 31,
	2004			2005
Promissory note payable to vendor; principal and interest payable quarterly at 1.73% per annum with a maturity date of April 1, 2006; secured by the equipment financed	$	767		$	155
Promissory note payable to vendor; principal and interest payable quarterly at 2.88% per annum with a maturity date of April 1, 2006; secured by the equipment financed		41			10
Promissory note payable to vendor; principal and interest payable quarterly at 3.87% per annum with a maturity date of April 1, 2006; secured by the equipment financed		146			30
Promissory note payable to vendor; principal and interest payable quarterly at 2.08% per annum with a maturity date of April 1, 2007; secured by the equipment financed		1,443			810
Promissory note payable to vendor; principal and interest payable quarterly at 0.0% per annum with a maturity date of March 1, 2008; secured by the equipment financed		—			1,246
2003 Receivables Facility (defined below), bearing interest at the one-month LIBOR rate plus 2.00% (6.39% at December 31, 2005), with monthly paydown corresponding with the cash collection of securitized notes receivable (see Note 4), with a maturity date of February 1, 2007		3,597			—
		5,994			2,251
Less: current portion		(4,636	)		(1,232	)
Notes payable, long-term	$	1,358		$	1,019

Revolving Credit Facility

      In August 2002, the Company entered into a Revolving Credit Facility (Revolving Credit Facility), which provides the Company with up to $15 million in available credit. Borrowings under the Revolving Credit Facility may be either Base Rate loans or Eurodollar rate loans. Base Rate loans bear interest at a fluctuating

66

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

rate per annum equal to the higher of the federal funds rate plus 0.5% or the lender’s prime rate. Eurodollar rate loans bear interest at the Eurodollar rate plus the applicable margin. There were no outstanding borrowings under the Revolving Credit Facility at December 31, 2004 and December 31, 2005; however, total available borrowings were reduced by outstanding letters of credit of $1.8 million and $10.7 million at December 31, 2004 and December 31, 2005, respectively (see Note 10), which reduce the amount the Company may borrow under the revolving credit facility. Accordingly, as of December 31, 2004 and 2005, the available capacity under the Revolving Credit Facility was $13.2 million and $4.3 million, respectively.

      The Company’s obligations under the Revolving Credit Facility are secured by all of the Company’s assets (other than the assets of NeuLevel, Inc. and those securing its obligations under the 2003 Receivable Facility, as discussed below). Under the terms of the Revolving Credit Facility, the Company must comply with certain financial covenants such as maintaining minimum levels of consolidated net worth, quarterly consolidated EBITDA, and liquid assets and not exceeding certain levels of capital expenditures and leverage ratios. Additionally, there are negative covenants that limit the Company’s ability to declare or pay dividends, acquire additional indebtedness, incur liens, dispose of significant assets, make acquisitions or significantly change the nature of the business without permission of the lender. During 2003, 2004 and 2005, the Company was not in compliance with certain covenants and obtained waivers for such defaults.

Receivables Facilities

      In November 2001, the Company established a Receivables Facility with a bank (2001 Receivables Facility), which provided the Company with up to a total of $37 million, as amended, in available credit. In connection with the 2001 Receivables Facility, the Company drew down net proceeds of approximately $28.0 million, net of financing costs, against $30.2 million in securitized notes receivable (see Note 4) in November 2001. This balance was repaid in full in 2003. In September 2002, the Company amended the 2001 Receivables Facility and drew down additional net proceeds of $6.7 million, net of financing costs, against $7.0 million in securitized notes receivable (see Note 4). In October 2003, the Company used a portion of the proceeds from the 2003 Receivables Facility, as discussed below, to pay off the remaining balance on the 2001 Receivables Facility.

      In October 2003, the Company established a Receivables Facility with a bank (2003 Receivables Facility), pursuant to which it borrowed $10.1 million, secured by, and payable from the proceeds of, its securitized notes receivable (see Note 4). An independent third party administers the collection of the securitized notes receivable. As the securitized notes receivable are collected, the third party pays the bank directly for all secured amounts on a monthly basis, thereby reducing the amounts outstanding under the facility. Minimum payments of $1 million have been due every six months since January 2004, and all amounts outstanding are due February 1, 2007. The Company has guaranteed a portion of the 2003 Receivables Facility (less than 10% of the outstanding principal balance) but is otherwise not liable for the collection of amounts owed under the secured securitized notes receivable. The 2003 Receivables Facility bears interest at the reserve adjusted one month LIBOR rate plus 2%. As of December 31, 2005, the rate was 6.39%.

67

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

      As of December 31, 2005, remaining principal payments under promissory notes payable and the 2003 Receivables Facility are as follows (in thousands):

2006	$	1,232
2007		880
2008		139
Total		2,251
Less: current portion		(1,232	)
Notes payable, long-term	$	1,019

10. COMMITMENTS AND CONTINGENCIES

Capital Leases

      The following is a schedule of future minimum lease payments due under capital lease obligations (in thousands):

2006	$	6,346
2007		3,207
2008		370
Total minimum lease payments		9,923
Less: amounts representing interest		(943	)
Present value of minimum lease payments		8,980
Less: current portion		(5,540	)
Capital lease obligation, long-term	$	3,440

      The following assets were capitalized under capital leases at the end of each period presented (in thousands):

	December 31,
	2004			2005
Equipment and hardware	$	14,922		$	18,392
Furniture and fixtures		1,918			1,918
		16,840			20,310
Less: accumulated amortization		(4,982	)		(10,838	)
	$	11,858		$	9,472

      The Company is obligated under certain capital lease obligations to maintain letters of credit for the value of the underlying assets. The Company has letters of credit with balances totaling $1.8 million and $10.7 million at December 31, 2004 and 2005, respectively.

68

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Operating Leases

      The Company leases office space under noncancelable operating lease agreements. The leases terminate at various dates through 2010 and generally provide for scheduled rent increases. Future minimum lease payments under noncancelable operating leases as of December 31, 2005, are as follows (in thousands):

2006	$	4,765
2007		4,283
2008		4,181
2009		4,265
2010		3,054
Thereafter		825
	$	21,373

      Rent expense was $2.6 million, $3.0 million and $3.6 million for the years ended December 31, 2003, 2004 and 2005, respectively.

Contingencies

      Currently, and from time to time, the Company is involved in litigation arising in the normal course of its business. The Company is not a party to any lawsuit or proceeding that, in the opinion of management, is reasonably possible to have a material adverse effect on its financial position, results of operations or cash flows.

11. RESTRUCTURING CHARGES

Workforce Reduction

      The restructuring program during 2005 resulted in workforce reductions of approximately 20 employees which were located in the Company’s Oakland, California office. The Company recorded workforce reduction charges of $317,000 during the year ended December 31, 2005, primarily for severance and fringe benefits.

Closure of Excess Facilities

      During 2003, the Company recorded a change in estimate of approximately $1.3 million to reduce a previously established restructuring liability in connection with the cancellation of a lease without penalties, which the Company had previously believed would apply when the applicable property was abandoned in 2002. During 2004, the Company recorded a change in estimate of approximately $220,000 to reduce the restructuring liability as a result of changes in the Company’s assumptions regarding the time period over which this property would remain vacant. During 2005, the Company recorded a change in estimate of approximately $706,000 to reduce the restructuring liability due to a change in the Company’s assumptions regarding the sub-lease rate for this property.

      At December 31, 2004 and 2005, the accrued liability associated with the restructuring and other related charges was $5.0 million and $3.1 million, respectively. Amounts related to the lease termination due to the closure of excess facilities will be paid over the respective lease terms, the longest of which extends through 2011. The Company paid approximately $3.3 million, $900,000 and $1.9 million, in the years ended December 31, 2003, 2004 and 2005, respectively, related to restructuring charges.

69

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

12. INCOME TAXES

      The provision for income taxes consists of the following components (in thousands):

		Year Ended December 31,
		2003		2004			2005
Current:
	Federal	$	401	$	5,609		$	32,381
	State		435		1,976			5,905
Total current			836		7,585			38,286
Deferred:
	Federal		—		(5,429	)		(876	)
	State		—		(990	)		(159	)
Total deferred			—		(6,419	)		(1,035	)
Total provision for income taxes		$	836	$	1,166		$	37,251

      As of June 30, 2004, the Company had generated operating profits for six consecutive quarters and had fully utilized its federal net operating loss carryforwards. As a result of this earnings trend and projected operating results over future years, the Company reversed approximately $20.2 million of its deferred tax asset valuation allowance, having determined that it was more likely than not that these deferred tax assets will be realized. This reversal resulted in the recognition of an income tax benefit of $16.9 million and a reduction of goodwill of $3.3 million. Of the total income tax benefit recognized, approximately $14.5 million relates to a federal deferred tax benefit with the remainder representing the state deferred tax benefit.

70

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

      Deferred income taxes reflect the net tax effects of temporary differences between the carrying amount of assets and liabilities for financial reporting purposes and the amounts used for income tax purposes. Significant components of the Company’s net deferred income taxes are as follows (in thousands):

		December 31,
		2004			2005
Deferred tax assets:
	NOL carryforwards	$	—		$	111
	Restructuring accrual		1,964			1,209
	Deferred revenue		4,939			6,328
	Accrued compensation		5,792			7,535
	Start-up costs		1,742			689
	Stock-based compensation expense		602			1,119
	Other reserves		1,173			1,281
	Other		495			777
Total deferred tax assets			16,707			19,049
Deferred tax liabilities:
	Unbilled receivables		(482	)		(3,162	)
	Depreciation and amortization		(4,883	)		(2,575	)
	Identifiable intangibles		(236	)		(816	)
	Deferred expenses		(1,362	)		(1,462	)
	Other		(15	)		(15	)
Total deferred tax liabilities			(6,978	)		(8,030	)
Net deferred tax asset		$	9,729		$	11,019

      A reconciliation of the statutory United States income tax rate to the effective income tax rate follows:

	Year Ended December 31,
	2003			2004			2005
Tax at statutory rate		35.0	%		35.0	%		35.0	%
State taxes		5.7			5.1			4.1
AMT Credit/ Tax		1.6			(1.0	)		1.6
Other		0.1			0.1			(0.5	)
Change in valuation allowance		(39.0	)		(36.7	)		0.0
Effective tax rate		3.4	%		2.5	%		40.2	%

13. CONVERTIBLE PREFERRED STOCK

      Prior to the Company’s initial public offering on June 28, 2005 (See Note 1), holders of 100,000 shares of Series B Voting Convertible Preferred Stock, 28,569,692 shares of Series C Voting Convertible Preferred Stock, and 9,098,525 shares of Series D Voting Convertible Preferred Stock converted their shares into 500,000, 28,569,692, and 9,098,525 shares of the Company’s common stock, respectively, after which each share of common stock was split by means of a reclassification into 1.4 shares of Class B common stock and subsequently converted, at the election of the holder, into Class A common stock.

71

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Series B Preferred Stock

      The holders of the Series B were entitled to receive preferential cumulative dividends in cash at the rate per share of 6% of stated value ($0.651) or $0.04 per annum, compounded quarterly. Dividends were declared and paid on the Series B. Each share of Series B was convertible into seven shares of common stock, subject to anti-dilution adjustments, and was entitled to that number of votes. Conversion into common stock was automatic in the event of an underwritten public offering (or a combination of offerings) of common stock with gross proceeds to the Company of not less than $50 million (Qualified IPO). In the event of liquidation, dissolution, or winding up of the Company, the holders of the Series B would have received, on par with the holders of the Series C, a liquidation preference of $0.651 per share plus any accrued and unpaid dividends per share. Dividends on the Series B were approximately $4,800, $4,800 and $2,000 for each of the years ended December 31, 2003, 2004 and 2005. Accrued and unpaid dividends on Series B were $18,000, $1,000 and $0 at December 31, 2003, 2004 and 2005, respectively.

      The Series B had a deemed liquidation provision included among the rights given to its holders whereby, upon the sale of the Company or substantially all the Company’s assets, the holders of the Series B were entitled to elect to receive a cash payment equal to the liquidation preference or the amount of consideration that would have been payable had the Series B converted to common stock.

Series C Preferred Stock

      The holders of the Series C were entitled to receive cumulative dividends in cash at the rate per share of 6% of stated value ($2.956) or $0.18 per annum, compounded quarterly. Dividends were declared and paid on the Series C in preference in respect to other series of stock determined as subordinate. The Series C were convertible to common shares on a 1.4-for-1 basis, subject to anti-dilution adjustments. Upon a Qualified IPO, the Series C would have automatically converted to common stock at the applicable conversion price. Each share of Series C was entitled to the same number of votes as the shares of common stock into which it was convertible. The Company also had the right to redeem, in whole or in part, the Series C outstanding at the Series C redemption price of $2.956 per share, plus an amount equal to any and all dividends accrued and unpaid, with consent of the holders of a majority of the Series C. In the event of liquidation, dissolution, or winding up of the Company, the holders of the Series C would have received, on par with the holders of the Series B, a liquidation preference of $2.956 per share plus any accrued and unpaid dividends per share. Dividends on the Series C were approximately $5.7 million and $5.8 million and $2.5 million for the years ended December 31, 2003, 2004 and 2005, respectively. Accrued and unpaid dividends on the Series C were approximately $14.0 million, $1.3 million and $0 at December 31, 2003, 2004 and 2005, respectively.

      The Series C had a deemed liquidation provision included among the rights given to its holders whereby, upon the sale of the Company or substantially all the Company’s assets, the holders of the Series C were entitled to elect to receive a cash payment equal to the liquidation preference or the amount of consideration that would have been payable had the Series C converted to common stock.

Series D Preferred Stock

      Holders of the Series D were entitled to receive cumulative dividends in cash at the rate per share of 6% of stated value ($5.935) or $0.36 per annum, compounded quarterly. Dividends were declared and paid on the Series D, subject in all cases to the rights and preferences of the holders of Series B and C but were in preference with respect to other series of shares determined as subordinate. The Series D were convertible to common shares on a 1.4-for-1 basis, subject to anti-dilution adjustments. Upon a Qualified IPO, the Series D would have automatically converted to common stock at the conversion price applicable at that time. Each share of Series D was entitled to that number of votes as the shares of common stock into which it was convertible.

72

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

      During the period commencing on August 5, 2006 and ending September 5, 2006, the holders of a majority of the then-outstanding shares of Series D and Series E could have required the Company to engage an independent investment banker to seek a third-party purchaser for then-outstanding Series D and E at not less than the applicable liquidation amount or some or all of the Company’s assets or to sell additional securities to fund the redemption of the Series D and Series E, such that the holders of such shares will receive the applicable liquidation amount. If the shares of Series D and Series E were not purchased or redeemed by the Company prior to June 5, 2007, the Company would have been required to redeem such shares on that date. If a majority of the holders of Series D and E did not elect to have their shares redeemed, a certain holder of Series D had a one-month period ending in October 2006 to have required the Company to redeem their shares on June 5, 2009. If the board of directors had determined that funds will not be reasonably available to satisfy the redemption obligation, the Company would not have been required to do so, provided that it increased the dividend rate on shares held by a certain holder of Series D by 0.5% per annum, up to a maximum dividend rate of 15% per annum. Series D was redeemable in amounts equal to the original investment plus accrued and unpaid dividends. The redemption amount of the Series D, $54.0 million plus accrued and unpaid dividends, was accreted to its redemption rate.

      In the event of a liquidation, dissolution, or winding up of the Company, the holders of the Series D and E were entitled to a liquidation preference over holders of all other series of preferred and common stock. The holders of the Series B and C were pari passu and had preference over the common stockholders. Dividends on and accretion of the Series D were approximately $3.6 million, $3.7 million and $1.6 million for the years ended December 31, 2003, 2004 and 2005, respectively.

      Accrued and unpaid dividends on the Series D were $8.9 million, $817,000 and $0 at December 31, 2003, 2004 and 2005, respectively.

14. STOCKHOLDERS’ (DEFICIT) EQUITY

Preferred Stock

      The Company is authorized to issue up to 100,000,000 shares of preferred stock, $0.001 par value per share, in one or more series, to establish from time to time the number of shares to be included in each series, and to fix the rights, preferences, privileges, qualifications, limitations and restrictions of the shares of each wholly unissued series.

Common Stock

      The Company is authorized to issue up to 200,000,000 shares of Class A common stock, $0.001 par value per share and 100,000,000 shares of Class B common stock, $0.001 par value per share. Each holder of Class A and Class B common stock is entitled to one vote for each share of common stock held on all matters submitted to a vote of stockholders. Subject to preferences that may apply to shares of preferred stock outstanding at the time, the holders of Class A and Class B common stock are entitled to receive dividends out of assets legally available at the times and in the amounts as our board of directors may from time to time determine.

      On June 28, 2005, the Company made an initial public offering of 31,625,000 shares of Class A common stock, which included the underwriters’ over-allotment option exercise of 4,125,000 shares of Class A common stock. All the shares of Class A common stock sold in the IPO were sold by selling stockholders and, as such, the Company did not receive any proceeds from the offering. In connection with this transaction, the Company incurred offering costs and other IPO-related expenses of approximately $4.9 million.

      On December 6, 2005, the Company completed an additional offering (December 2005 offering), of 20,000,000 shares of Class A common stock. All the shares of Class A common stock sold in the December 2005 offering were sold by selling stockholders and, as such, the Company did not receive any proceeds from

73

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

that offering. In connection with this transaction, the Company incurred offering costs of approximately $900,000.

      In connection with the formation of NeuLevel, Inc. (NeuLevel), the Company’s 90%-owned subsidiary, the Company granted the minority interest holder of NeuLevel an option to purchase, within 30 days of the completion of the Company’s initial public offering, up to $20.0 million worth of Class B common stock at a purchase price per share equal to the public offering price. This option expired unexercised.

      In October 2005, the Company granted 5,000 shares of restricted common stock to an employee under the NeuStar, Inc. 2005 Stock Incentive Plan. The shares vest in annual equal installments over three years from the date of grant.

Warrants

      In prior years, the Company issued warrants to purchase 6,361,383 shares of common stock at $0.0667 per share in connection with certain debt financings. On December 12, 2005, the Company issued 6,361,383 shares of Class A common stock upon the exercise these warrants in exchange for cash proceeds of approximately $424,000.

15. STOCK INCENTIVE PLANS

      The Company has two stock incentive plans, the NeuStar, Inc. 1999 Equity Incentive Plan (the 1999 Plan) and the NeuStar, Inc. 2005 Stock Incentive Plan (the 2005 Plan). Under the 1999 Plan, the Company had the ability to grant to its directors, employees and consultants stock or stock-based awards in the form of incentive stock options, nonqualified stock options, stock appreciation rights, performance share units, shares of restricted common stock, phantom stock units and other stock-based awards. In May 2005, the Company’s board of directors adopted the 2005 Plan, which was approved by the Company’s stockholders in June 2005. In connection with the adoption of the 2005 Plan, the Company’s board of directors amended the 1999 Plan to provide that no further awards would be granted under the 1999 Plan as of the date stockholder approval of the 2005 Plan was obtained. All shares available for grant as of that date, plus any other shares under the 1999 Plan that again become available due to forfeiture, expiration, settlement in cash or other termination of awards without issuance, will be available for grant under the 2005 Plan.

      Under the 2005 plan, the Company may grant to its directors, employees and consultants awards in the form of incentive stock options, nonqualified stock options, stock appreciation rights, shares of restricted stock, restricted stock units, performance awards and other stock-based awards. The aggregate number of shares of Class A common stock with respect to which all awards may be granted under the 2005 plan is 6,044,715, plus any shares available for issuance under the 1999 Plan. As of December 31, 2005, 6,021,173 shares are available for grant or award under the 2005 Plan.

      The terms of all stock options granted may not exceed ten years. The exercise price of options granted, as determined by the Compensation Committee, approximates fair market value of Common Stock at the time of the grant. The exercise price per share for options granted under the Plan is generally not less than 100% of the fair market value of the common stock on the option grant date. The board of directors or Compensation Committee of the board of directors determines the vesting of the options, with a maximum vesting period of ten years. Options issued through 2005 generally vest with respect to 25% of the shares on the first anniversary of the grant date and 2.083% of the shares on the last day of each succeeding calendar month thereafter. The options expire ten years from date of issuance and are forfeitable upon termination of an option holder’s service.

74

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

      The following table summarizes the Company’s stock option activity:

					Weighted-Average
		Shares			Exercise Price
Outstanding at December 31, 2002			9,345,910		$	1.07
	Options granted		4,016,446			5.26
	Options exercised		(220,060	)		0.18
	Options forfeited		(425,703	)		2.11
Outstanding at December 31, 2003			12,716,593			2.37
	Options granted		2,983,173			6.69
	Options exercised		(611,118	)		0.15
	Options forfeited		(713,006	)		3.91
Outstanding at December 31, 2004			14,375,642			3.29
	Options granted		1,149,844			20.33
	Options exercised		(2,588,631	)		3.07
	Options forfeited		(315,302	)		6.10
Outstanding at December 31, 2005			12,621,553			4.81
Exercisable at December 31, 2005			8,692,844			2.41
Exercisable at December 31, 2004			8,561,121			1.46
Exercisable at December 31, 2003			7,466,332			0.92

      The following table summarizes information regarding options outstanding at December 31, 2005:

	Options Outstanding						Options Exercisable
					Weighted-
			Weighted-		Average				Weighted-
	Number of		Average		Remaining		Number of		Average
	Options		Exercise		Contractual Life		Options		Exercise
Range of Exercise Price	Outstanding		Price		(In Years)		Exercisable		Price
$ 0.00 - $ 3.20		5,252,398	$	0.38		4.51		5,252,398	$	0.38
$ 3.21 - $ 6.21		2,492,998		4.42		6.90		1,963,415		4.39
$ 6.22 - $ 8.21		3,296,263		6.33		7.93		1,223,778		6.33
$ 8.22 - $11.21		776,644		9.42		8.18		253,253		10.27
$11.22 - $31.95		803,250		24.35		9.51		—		—
		12,621,553		4.81		6.42		8,692,844		2.41

      In June 2004, the Company entered into an agreement with an employee which gave the employee the right to put 210,000 shares of common stock to be received upon the exercise of vested stock options back to the Company at $4.82 per share. In July 2004, the employee exercised vested stock options for 210,000 shares of common stock and put the shares back to the Company in August 2004. The Company recognized stock-based compensation expense of $982,000 on the date the put right was granted in accordance with FASB Interpretation No. 44, Accounting for Certain Transactions Involving Stock Compensation, an Interpretation of ABP 25. The shares repurchased were held in treasury as of December 31, 2004 and were retired in May 2005.

      In July 2004, the Company granted an employee of the Company the right to receive a total of 350,000 shares of common stock. This right vests on December 18, 2008. The Company recorded $2.2 million

75

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

in deferred compensation expense during the year ended December 31, 2004 in connection with this stock grant. The deferred compensation is calculated as the fair value of the shares on the grant date and is being amortized over the vesting period of the restricted stock.

      In February 2005, the Company granted fully vested options to nonemployees for the purchase of 22,400 shares of common stock at a weighted average exercise price of $10.86 per share. The Company recognized compensation expense of approximately $180,000. The fair value of these awards was calculated on the date of grant using the Black-Scholes option-pricing model with the following weighted average assumptions: expected life of the award equal to the remaining contractual life; volatility 63.11%; risk-free interest rate, 3.38%; and dividend yield of 0.00% during the option term.

      In March 2005, an employee of the Company changed status to a consultant and, in accordance with the terms of that employee’s original option agreement, continued to vest in 26,250 options as of March 29, 2005. As a result, the Company re-measured the fair value of the vested options and recognized compensation expense of approximately $331,000. The fair value of this award was calculated on the modification date using the Black-Scholes option-pricing model with the following weighted average assumptions: expected life of the award equal to the remaining contractual life; volatility 63.11%; risk-free interest rate, 3.43%; and dividend yield of 0.00% during the option term.

      In March 2005, the Company accelerated the vesting of certain options issued to nonemployees. This acceleration enabled the optionholders to immediately vest in approximately 102,000 options, which otherwise would have vested over the options’ original vesting period, generally 48 months. In connection with this acceleration, the Company recorded approximately $1.6 million as compensation expense based on the fair value of the options on the date of acceleration. The fair value of these awards was remeasured on the acceleration date using the Black-Scholes option-pricing model with the following weighted average assumptions: expected life of the award equal to the remaining contractual life; volatility 63.11%; risk-free interest rate, 3.72%; and dividend yield of 0.00% during the option term. As of March 31, 2005, all options granted to nonemployees had vested. Prior to this acceleration, the Company recognized compensation expense of approximately $249,000 and $644,000 for the years ended December 31, 2003 and 2004.

      In October 2005, the Company granted 5,000 shares of restricted common stock to an employee under the 2005 Plan. The shares vest in annual equal installments over three years from the date of grant. The Company recorded approximately $160,000 of deferred stock compensation expense relating to the issuance of the restricted common stock. The deferred stock compensation expense is amortized on a straight-line basis over the three year vesting period.

16. EMPLOYEE BENEFIT PLANS

      The Company has a 401(k) Profit-Sharing Plan for the benefit of all employees who meet certain eligibility requirements. This plan covers substantially all of the Company’s full-time employees. The plan documents provide for the Company to make matching and other discretionary contributions, as determined by the board of directors. The Company recognized contribution expense related to both plans totaling $1.3 million, $1.5 million and $2.0 million for the years ended December 31, 2003, 2004 and 2005, respectively.

17. RELATED PARTY TRANSACTIONS

      During the years ended December 31, 2003, 2004 and 2005, the Company received professional services from a company owned by a family member of the Chairman and CEO of the Company. The services were related to tenant improvements in the Company’s leased office spaces. The amounts paid to the related party during the years ended December 31, 2003, 2004 and 2005 were approximately $38,000, $117,000 and

76

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

$99,000, respectively. As of December 31, 2004 and 2005, the Company had no outstanding payable to this party.

      The Company has an agreement with Melbourne IT Limited (MIT), a holder of a 10% interest in NeuLevel, whereby MIT serves as a registrar for domain names within the .biz top-level domain. During the years ended December 31, 2003, 2004 and 2005, the Company recorded approximately $377,000, $512,000 and $684,000, respectively, in revenue from MIT related to domain name registration services and other nonrecurring revenue from IP claim notification services and pre-registration services.

18. QUARTERLY FINANCIAL INFORMATION (UNAUDITED)

		Quarter Ended
		Mar. 31,		Jun. 30,		Sep. 30,		Dec. 31,
		2004		2004		2004		2004
		(In thousands, except per share data)
Summary consolidated statement of operations:
	Total revenue	$	38,714	$	39,610	$	45,229	$	41,448	(1)
	Income from operations		14,054		11,586		14,794		6,977
	Net income		13,533		18,668		8,964		4,211
	Net income attributable to common stockholders		11,056		16,155		6,386		2,042
	Net income attributable to common stockholders per common share — basic	$	2.06	$	2.94	$	1.10	$	0.35
	Net income attributable to common stockholders per common share — diluted	$	0.17	$	0.23	$	0.11	$	0.05

		Quarter Ended
		Mar. 31,		Jun. 30,		Sep. 30,			Dec. 31,
		2005		2005		2005			2005
		(In thousands, except per share data)
Summary consolidated statement of operations:
	Total revenue	$	57,792	$	62,296	$	58,960	(1)	$	63,421
	Income from operations		24,475		23,016		21,692			23,285
	Net income		14,631		13,883		13,057			13,827
	Net income attributable to common stockholders		12,488		11,713		13,057			13,827
	Net income attributable to common stockholders per common share — basic	$	2.08	$	1.45	$	0.22		$	0.22
	Net income attributable to common stockholders per common share — diluted	$	0.19	$	0.18	$	0.17		$	0.18

(1)  Revenue for the quarters ended December 31, 2004 and September 30, 2005 reflects contractual pricing discounts based on pre-established annual aggregate transaction volume targets under our contracts with North American Portability Management LLC, which had an impact of $11.9 million and $7.5 million, respectively.

19. SUBSEQUENT EVENT

      In March 2006, the Company acquired all of the remaining shares of NeuLevel, Inc. from its joint venture partner, Melbourne IT Limited (MIT) for $4.3 million in cash. In accordance SFAS No. 141, the acquisition will be accounted for using purchase accounting. The Company is currently in the process of completing its purchase price allocation.

77

ITEM 9. CHANGES IN AND DISAGREEMENTS WITH ACCOUNTANTS ON ACCOUNTING AND FINANCIAL DISCLOSURE.

      None.

ITEM 9A. CONTROLS AND PROCEDURES.

      We maintain disclosure controls and procedures that are designed to ensure that information required to be disclosed in our reports filed or submitted under the Securities Exchange Act of 1934 is recorded, processed, summarized and reported within the time periods specified in the Securities and Exchange Commission’s rules and forms, and that such information is accumulated and communicated to our management, including our Chief Executive Officer and Chief Financial Officer, as appropriate, to allow for timely decisions regarding required disclosure. In designing and evaluating the disclosure controls and procedures, management recognized that any controls and procedures, no matter how well designed and operated, can provide only reasonable assurance of achieving the desired control objectives, and management is required to apply its judgment in evaluating the cost-benefit relationship of possible controls and procedures.

      As of December 31, 2005, we carried out an evaluation, under the supervision and with the participation of our management, including our Chief Executive Officer and our Chief Financial Officer, of the effectiveness of the design and operation of our disclosure controls and procedures. Based on the foregoing, our Chief Executive Officer and Chief Financial Officer concluded that our disclosure controls and procedures were effective and were operating at the reasonable assurance level.

      In addition, there were no changes in our internal control over financial reporting that occurred in the fourth quarter of 2005 that materially affected, or are reasonably likely to materially affect, our internal control over financial reporting.

ITEM 9B.     OTHER INFORMATION.

      None.

PART III

ITEM 10. DIRECTORS AND EXECUTIVE OFFICERS OF THE REGISTRANT.

      Information about our directors and executive officers is incorporated by reference to our definitive proxy statement for our 2006 Annual Meeting of Stockholders, or our 2006 Proxy Statement, which is anticipated to be filed with the Securities and Exchange Commission within 120 days of December 31, 2005, under the headings “Board of Directors” and “Executive Officers and Management.” Information about compliance with Section 16(a) of the Exchange Act is incorporated by reference to our 2006 Proxy Statement under the heading “Section 16(a) Beneficial Ownership Reporting Compliance.” Information about our Audit Committee, including the members of the Audit Committee, and Audit Committee financial experts, is incorporated by reference to our 2006 Proxy Statement under the heading “Governance of the Company — Board and Committee Membership.” Information about the NeuStar policies on business conduct governing our employees, including our Chief Executive Officer, Chief Financial Officer and our controller, is incorporated by reference to our 2006 Proxy Statement under the heading “Governance of the Company — Governance Information.”

ITEM 11. EXECUTIVE COMPENSATION.

      Information about director and executive officer compensation is incorporated by reference to our 2006 Proxy Statement, under the headings “Governance of the Company — Compensation of Non-Employee Directors,” “Executive Compensation,” “Compensation Committee Interlocks and Insider Participation,” and “Termination of Employment and Change in Control Arrangements and Indemnification.”

78

ITEM 12. SECURITY OWNERSHIP OF CERTAIN BENEFICIAL OWNERS AND MANAGEMENT AND RELATED STOCKHOLDER MATTERS.

      Information required by Item 12 of this report is incorporated by reference to our 2006 Proxy Statement, under the headings “Beneficial Ownership of Shares of Common Stock” and “Equity Compensation Plan Information.”

ITEM 13. CERTAIN RELATIONSHIPS AND RELATED TRANSACTIONS.

      The information required by Item 13 of this report is incorporated by reference to our 2006 Proxy Statement, under the heading “Certain Relationships and Related Party Transactions.”

ITEM 14. PRINCIPAL ACCOUNTING FEES AND SERVICES.

      Information about the fees for professional services rendered by our independent auditors in 2004 and 2005 is incorporated by reference to the discussion under the heading “Audit and Non-Audit Fees” in our 2006 Proxy Statement. Our audit committee’s policy on pre-approval of audit and permissible non-audit services of our independent auditors is incorporated by reference from the discussion under the heading “Policy on Audit Committee Pre-Approval of Audit and Permissible Non-Audit Services of Independent Registered Public Accounting Firm” in our 2006 Proxy Statement.

PART IV

ITEM 15. EXHIBITS, FINANCIAL STATEMENT SCHEDULES.

      (a) Documents filed as part of this report:

      (1) Financial Statements

		Page
Report of Independent Registered Public Accounting Firm			46
Financial Statements covered by the Report of Independent Registered Public Accounting Firm:
	Consolidated Balance Sheets as of December 31, 2004 and 2005		47
	Consolidated Statements of Operations for the years ended December 31, 2003, 2004 and 2005		49
	Consolidated Statements of Stockholders’ (Deficit) Equity for the years ended December 31, 2003, 2004 and 2005		50
	Consolidated Statements of Cash Flows for the years ended December 31, 2003, 2004 and 2005		51
	Notes to the Consolidated Financial Statements		52

      (2) Financial Statement Schedules

Schedule for the three years ended December 31, 2003, 2004 and 2005:
	II — Valuation and Qualifying Accounts	80

      (3) Exhibits

      A list of exhibits filed or furnished with this report is provided in the Exhibit Index beginning on page 80 of this report.

79

NEUSTAR, INC.

SCHEDULE II — VALUATION AND QUALIFYING ACCOUNTS

		As of December 31,
		2003			2004			2005
		(In thousands)
Allowance for Doubtful Accounts
	Beginning Balance	$	66		$	84		$	468
	Additions		184			960			551
	Reductions(1)		(166	)		(576	)		(525	)
	Ending Balance	$	84		$	468		$	494
Deferred Tax Asset Valuation Allowance
	Beginning Balance	$	30,270		$	20,209		$	—
	Additions		—			—			—
	Reductions		(10,061	)		(20,209	)		—
	Ending Balance	$	20,209		$	—		$	—

(1)  Includes accounts written-off, net of collections on accounts previously written off.

80

EXHIBIT INDEX

      Exhibits identified in parentheses below are on file with the SEC and are incorporated herein by reference. All other exhibits are provided as part of this electronic submission.

Exhibit
Number			Description of Exhibit
	(3	.1)	Restated Certificate of Incorporation, incorporated herein by reference to Exhibit 3.1 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635).
	(3	.2)	Amended and Restated Bylaws, incorporated herein by reference to Exhibit 3.2 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635).
	(4	.1)	Specimen Class A Common Stock Certificate, incorporated herein by reference to Exhibit 4.1 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635).
	(4	.2)	Specimen Class B Common Stock Certificate, incorporated herein by reference to Exhibit 4.2 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635).
	(9	.1)	Amended and Restated Trust Agreement dated September 24, 2004, by and among NeuStar, Inc., the stockholders named therein and the trustees named therein, incorporated herein by reference to Exhibit 9.1 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635).
	(10	.1)	Contractor services agreement entered into the 7th day of November 1997 by and between NeuStar, Inc. and North American Portability Management LLC, as amended, incorporated herein by reference to Exhibit 10.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005.**
	10	.1.1	Amendment, effective May 31, 2003, to the contractor services agreement by and between NeuStar, Inc. and North American Portability Management LLC, as amended.
	(10	.2)	Contractor services agreement, restated as of June 1, 2003, by and between Canadian LNP Consortium Inc. and NeuStar, Inc., as amended, incorporated herein by reference to (a) Exhibit 10.2 to Amendment No. 6 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635); and (b) Exhibit 10.2.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005.**
	10	.2.1	Amendment, entered into as of December 19, 2005, to the contractor services agreement between Canadian LNP Consortium Inc. and NeuStar, Inc.**
	10	.2.2	Amendment, entered into as of January 20, 2006, to the contractor services agreement between Canadian LNP Consortium Inc. and NeuStar, Inc.**
	(10	.3)	National Thousands-Block Pooling Administration agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective June 14, 2001, incorporated herein by reference to (a) Exhibit 10.3 to Amendment No. 6 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635); (b) Exhibit 10.3.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005; (c) Exhibit 10.3.2 to our Current Report on Form 8-K, filed September 15, 2005; and (d) Exhibit 10.3.3 to our Quarterly Report on Form 10-Q, filed November 14, 2005.
	(10	.4)	North American Numbering Plan Administrator agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective July 9, 2003, incorporated herein by reference to (a) Exhibit 10.4 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635); and (b) Exhibit 10.4.1 to our Current Report on Form 8-K, filed September 15, 2005.
	10	.4.1	Amendment, effective November 12, 2003, to the North American Numbering Plan Administrator agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective July 9, 2003.

81

Exhibit
Number			Description of Exhibit
	(10	.5)	.us Top-Level Domain Registry Management and Coordination agreement awarded to NeuStar, Inc. by the National Institute of Standards and Technology on behalf of the Department of Commerce on October 26, 2001, incorporated herein by reference to (a) Exhibit 10.5 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635); (b) Exhibit 10.5.1 to our Quarterly Report on Form 10-Q, filed November 14, 2005; and (c) Exhibit 10.5.2 to our Quarterly Report on Form 10-Q, filed November 14, 2005.
	(10	.6)	Registry Agreement by and between the Internet Corporation for Assigned Names and Numbers and NeuLevel, Inc., dated as of May 11, 2001, incorporated herein by reference to Exhibit 10.6 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).
	(10	.7)	Common Short Code License Agreement made and entered into October 17, 2003, by and between the Cellular Telecommunications and Internet Association and NeuStar, Inc., incorporated herein by reference to Exhibit 10.7 to Amendment No. 7 to our Registration Statement on Form S-1, filed June 28, 2005 (File No. 333-123635).**
	10	.7.1	Amendment, entered into on January 31, 2006, to Common Short Code License Agreement between the Cellular Telecommunications and Internet Association and NeuStar, Inc.
	(10	.8)	NeuStar, Inc. 1999 Equity Incentive Plan (the “1999 Plan”), incorporated herein by reference to Exhibit 10.8 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.9)	NeuStar, Inc. 2005 Stock Incentive Plan (the “2005 Plan”), incorporated herein by reference to Exhibit 10.9 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.10)	Incentive Stock Option Agreement under the 1999 Plan, made as of April 10, 2000, by and between NeuStar, Inc. and Jeffrey Ganek, incorporated herein by reference to Exhibit 10.10 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.11)	Incentive Stock Option Agreement under the 1999 Plan, made as of April 10, 2000, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.11 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.12)	Incentive Stock Option Agreement under the 1999 Plan, made as of March 26, 2002, by and between NeuStar, Inc. and Michael Lach, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.12 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.13)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of March 26, 2002, by and between NeuStar, Inc. and Michael Lach, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.13 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.14)	Incentive Stock Option Agreement under the 1999 Plan, made as of June 6, 2002, by and between NeuStar, Inc. and Jeffrey Ganek, incorporated herein by reference to Exhibit 10.14 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.15)	Incentive Stock Option Agreement under the 1999 Plan, made as of June 6, 2002, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.15 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.16)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of June 6, 2002, by and between NeuStar, Inc. and Jeffrey Ganek, incorporated herein by reference to Exhibit 10.16 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†

82

Exhibit
Number			Description of Exhibit
	(10	.17)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of June 6, 2002, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.17 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.18)	Incentive Stock Option Agreement under the 1999 Plan, made as of January 16, 2003, by and between NeuStar, Inc. and John Malone, as amended as of December 18, 2003 and as of June 22, 2004, incorporated herein by reference to Exhibit 10.18 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.19)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of January 16, 2003, by and between NeuStar, Inc. and John Malone, as amended as of December 18, 2003 and as of June 22, 2004, incorporated herein by reference to Exhibit 10.19 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.20)	Incentive Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and Jeffrey Ganek, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.20 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.21)	Incentive Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and Michael Lach, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.21 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.22)	Incentive Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and Mark Foster, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.22 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.23)	Incentive Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and John Malone, as amended as of June 22, 2004 and May 20, 2005, incorporated herein by reference to Exhibit 10.23 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.24)	Nonqualified Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and Jeffrey Ganek, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.24 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.25)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and Michael Lach, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.25 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.26)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and Mark Foster, as amended as of June 22, 2004, incorporated herein by reference to Exhibit 10.26 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.27)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of December 18, 2003, by and between NeuStar, Inc. and John Malone, as amended as of June 22, 2004 and May 20, 2005, incorporated herein by reference to Exhibit 10.27 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.28)	Incentive Stock Option Agreement under the 1999 Plan, made as of June 22, 2004, by and between NeuStar, Inc. and Jeffrey Babka, as amended as of May 20, 2005, incorporated herein by reference to Exhibit 10.28 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.29)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of June 22, 2004, by and between NeuStar, Inc. and Jeffrey Babka, as amended as of May 20, 2005, incorporated herein by reference to Exhibit 10.29 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†

83

Exhibit
Number			Description of Exhibit
	(10	.30)	Phantom Stock Unit Agreement under the 1999 Plan, made as of July 19, 2004, by and between NeuStar, Inc. and Michael R. Lach, incorporated herein by reference to Exhibit 10.30 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.31)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of April 10, 2000, by and between NeuStar, Inc. and Henry Geller, incorporated herein by reference to Exhibit 10.31 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.32)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of April 10, 2000, by and between NeuStar, Inc. and Henry Kressel, incorporated herein by reference to Exhibit 10.32 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.33)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of April 10, 2000, by and between NeuStar, Inc. and Joe Landy, incorporated herein by reference to Exhibit 10.33 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.34)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of April 10, 2000, by and between NeuStar, Inc. and Ken Pickar, incorporated herein by reference to Exhibit 10.34 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.35)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of February 14, 2005, by and between NeuStar, Inc. and Jim Cullen, incorporated herein by reference to Exhibit 10.35 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.36)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of February 14, 2005, by and between NeuStar, Inc. and Frank Schiff, incorporated herein by reference to Exhibit 10.36 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).†
	(10	.37)	Loudoun Tech Center Office Lease by and between Merritt-LT1, LLC, Landlord, and NeuStar, Inc., Tenant, incorporated herein by reference to Exhibit 10.37 to Amendment No. 2 to our Registration Statement on Form S-1, filed May 11, 2005 (File No. 333-123635).
	(10	.38)	Credit Agreement, dated as of August 14, 2002, among NeuStar, Inc., Bank of America, N.A., and other lenders, incorporated herein by reference to(a) Exhibit 10.38 to Amendment No. 2 to our Registration Statement on Form S-1, filed May 11, 2005 (File No. 333-123635); and(b) Exhibit 10.38.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005.
	10	.38.1	Amendment, dated February 15, 2005, to the Credit Agreement, dated as of August 14, 2002, among NeuStar, Inc., Bank of America, N.A., and other lenders.
	10	.38.2	Amendment, dated February 10, 2006, to the Credit Agreement, dated August 14, 2002, among NeuStar, Inc., Bank of America, N.A., and other lenders.
	(10	.39)	NeuStar, Inc. Annual Performance Incentive Plan, incorporated herein by reference to Exhibit 10.40 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.40)	NeuStar, Inc. 2005 Key Employee Severance Pay Plan, incorporated herein by reference to Exhibit 10.41 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.41)	Executive Relocation Policy, incorporated herein by reference to Exhibit 10.42 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.42)	Employment Continuation Agreement, made as of April 8, 2004, by and between NeuStar, Inc. and Jeffrey Ganek, incorporated herein by reference to Exhibit 10.43 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†

84

Exhibit
Number			Description of Exhibit
	(10	.43)	Employment Continuation Agreement, made as of April 8, 2004, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.44 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.44)	Form of Restricted Stock Agreement under the 2005 Plan, incorporated herein by reference to Exhibit 10.45 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.45)	Form of Nonqualified Stock Option Agreement under the 2005 Plan, incorporated herein by reference to Exhibit 10.46 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.46)	Form of Incentive Stock Option Agreement under the 2005 Plan, incorporated herein by reference to Exhibit 10.47 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.47)	Summary of relocation arrangement with Jeffrey A. Babka, incorporated herein by reference to Exhibit 10.48 to Amendment No. 3 to our Registration Statement on Form S-1, filed May 27, 2005 (File No. 333-123635).†
	(10	.48)	Form of Indemnification Agreement, incorporated herein by reference to Exhibit 10.49 to Amendment No. 5 to our Registration Statement on Form S-1, filed June 10, 2005 (File No. 333-123635).†
	(10	.49)	Stockholders Agreement, dated June 28, 2005, by and among NeuStar, Inc. and the stockholders named therein, incorporated herein by reference to Exhibit 4.3 to our Quarterly Report on Form 10-Q, filed August 15, 2005.
	(10	.50)	Registration Rights Agreement, dated as of June 5, 2001, by and among NeuStar, Inc. and the stockholders named therein, incorporated herein by reference to Exhibit 4.4 to Amendment No. 1 to our Registration Statement on Form S-1, filed April 8, 2005 (File No. 333-123635).
	21	.1	Subsidiaries of NeuStar, Inc.
	23	.1	Consent of Ernst & Young LLP.
	24	.1	Power of Attorney (included on the signature page herewith).
	31	.1	Chief Executive Officer Certification pursuant to Section 302 of the Sarbanes-Oxley Act of 2002.
	31	.2	Chief Financial Officer Certification pursuant to Section 302 of the Sarbanes-Oxley Act of 2002.
	32	.1	Certification pursuant to 18 U.S.C. Section 1350, as adopted pursuant to Section 906 of the Sarbanes-Oxley Act of 2002.
	99	.1	Update to the Functional Requirements Specification, which is attached as Exhibit B to the contractor services agreement by and between NeuStar, Inc. and North American Portability Management, LLC, filed with the Securities and Exchange Commission as Exhibit 10.1 and Exhibit 10.1.1 to this annual report on Form 10-K.
	99	.2	Update to the Interoperable Interface Specification, which is attached as Exhibit C to the contractor services agreement by and between NeuStar, Inc. and North American Portability Management, LLC, filed with the Securities and Exchange Commission Exhibit 10.1 and Exhibit 10.1.1 to this annual report on Form 10-K.

†  Compensation arrangement.

**  Confidential treatment has been requested or granted for portions of this document. The omitted portions of this document have been filed with the Securities and Exchange Commission.

85

SIGNATURES

      Pursuant to the requirements of Section 13 or 15(d) of the Securities Exchange Act of 1934, the registrant has duly caused this report to be signed on its behalf by the undersigned, thereunto duly authorized on March 29, 2006.

NEUSTAR, INC.

By:  /s/ Jeffrey E. Ganek

Jeffrey E. Ganek

Chairman of the Board of Directors

and Chief Executive Officer

      We, the undersigned directors and officers of NeuStar, Inc., hereby severally constitute Jeffrey E. Ganek and Martin K. Lowen, and each of them singly, our true and lawful attorneys with full power to them and each of them to sign for us, in our names in the capacities indicated below, any and all amendments to this Annual Report on Form 10-K filed with the Securities and Exchange Commission.

      Pursuant to the requirements of the Securities Act of 1934, this report has been signed below by the following persons on behalf of the registrant and in the capacities indicated on March 29, 2006.

Signature	Title
/s/ Jeffrey E. Ganek Jeffrey E. Ganek	Chairman of the Board of Directors and Chief Executive Officer (Principal Executive Officer)
/s/ Jeffrey A. Babka Jeffrey A. Babka	Senior Vice President and Chief Financial Officer (Principal Financial Officer and Principal Accounting Officer)
/s/ James G. Cullen James G. Cullen	Director
/s/ Henry Geller Henry Geller	Director
/s/ Joseph P. Landy Joseph P. Landy	Director
/s/ Dr. Kenneth A. Pickar Dr. Kenneth A. Pickar	Director
/s/ Frank L. Schiff Frank L. Schiff	Director

86 EX-10.1.1 2 w17665exv10w1w1.htm EX-10.1.1

Exhibit 10.1.1

Amendment No. 38
5/28/03
SOW: oYes þNo

[Graphic Omitted: NeuStar Logo]

AMENDMENT OF SLR-27

UNDER

AGREEMENT FOR NUMBERING ADMINISTRATION CENTER /
SERVICE MANAGEMENT SYSTEM

Page 1

Amendment No. 38
5/28/03
SOW: oYes þNo

AMENDMENT OF SLR-27

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

2. EFFECTIVNESS.

This Amendment shall be effective as of [the 31^st day of May, 2003] (the “Amendment Effective Date”) only upon execution of separate amendments by Contractor and Customer. 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. SCOPE.

The parties desire to amend SLR-27 to reflect the incorporation of electronic media into Contractor’s delivery processes. Therefore, SLR-27 is hereby amended by replacing the word “Mail” with “Provide” under the Service Commitment Level column.

Upon execution of this Amendment, Contractor will provide the amended definition of SLR-27 to its Gateway Evaluation Process (“GEP”) auditor.

4. COMPLETION AND ACCEPTANCE CRITERIA.

Page 2

Amendment No. 38
5/28/03
SOW: oYes þNo

The following internal documents are applicable under this Amendment:

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
Ö	User Documentation
N/A	Software Configuration Management Plan
Ö	Standards and Metrics

5. IMPACTS ON MASTER AGREEMENT

The following Master Agreement documents are impacted by this Amendment:

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

6. PRICING.

There are no pricing impacts under this Amendment.

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

Page 3

Amendment No. 38
5/28/03
SOW: oYes þNo

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.

8. MISCELLANEOUS.

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

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

[THIS SPACE INTENTIONALLY LEFT BLANK]

Page 4

Amendment No. 38
5/28/03
SOW: oYes þNo

IN WITNESS WHEREOF, the undersigned have executed this Amendment:

CONTRACTOR: NeuStar, Inc.
By:	/s/ C Walker
Its:	VP Customer Ops
Date:	6-9-03
CUSTOMER: North American Portability Management, LLC
By:	/s/ Richard Theiss
Its:	Co-Chair
Date:	11 June, 2003
CUSTOMER: North American Portability Management, LLC
By:	/s/ Pamela H. Connell
Its:	Co-Chair
Date:	June 16, 2003

Page 5

EX-10.1.1

exv10w1w1

EX-10.2.1

Exhibit 10.2.1

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

CANADIAN NPAC/SMS CONTRACTOR SERVICES AGREEMENT
AMENDING AGREEMENT

THIS AMENDING AGREEMENT is made and entered into with effect as of the day of October, 2005.

BETWEEN:

CANADIAN LNP CONSORTIUM, INC., a corporation incorporated under the laws of Canada (“Customer”),

- and -

NEUSTAR, INC., a corporation incorporated under the laws of Delaware (“Contractor”)

WHEREAS pursuant to a Contractor Services Agreement made and entered into as of May 19, 1998 by and between Customer and Lockheed Martin IMS Corporation (as amended and assigned on November 30, 1999 by Lockheed Martin IMS Corporation to Contractor) (the “Contractor Services Agreement”), Contractor has provided the NPAC/SMS Services to Users pursuant to User Agreements (as those terms are defined in the Contractor Services Agreement);

AND WHEREAS by amending agreement dated March 31, 2003, the Contractor Services Agreement was amended, inter alia, to extend the term thereof to May 31, 2007;

AND WHEREAS pursuant to a letter agreement dated September 12, 2005 between Customer and Contractor (the “Letter Agreement”), Customer and Contractor renewed the Contractor Services Agreement to December 31, 2011 (the “Renewal Term”), all upon and subject to the terms and conditions contained in the Letter Agreement;

AND WHEREAS the Letter Agreement contemplates the execution and delivery of this Canadian NPAC/SMS Contractor Services Agreement Amending Agreement (the “Amending Agreement”), on the terms and conditions described in the Letter Agreement, in order to fully implement the Letter Agreement;

NOW, THEREFORE, THIS AGREEMENT WITNESSETH that in consideration of the covenants and agreements hereinafter contained, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged by each of the parties hereto, the parties hereto covenant and agree as follows:

Page 1

1. Effective Date

The Effective Date of the Contractor Services Agreement is amended by deleting “June 1, 2003” and substituting “September 12, 2005” therefor.

2. Business Day

Section 1.7 of the Contractor Services Agreement is amended by deleting “Easter” and substituting “Good Friday” therefor.

3. Term

Article 3 of the Contractor Services Agreement is amended by deleting “May 31, 2007” and substituting “December 31, 2011” therefor.

4. Pricing and Adjustment

Article 6 of the Contractor Services Agreement is hereby amended by renumbering “Section 6.1 General” as “Section 6.1(a)”, and adding the following:

(b) One Time Credit. Contractor shall on or before December 31, 2005 pay, by way of credit, the amount of $[* * *] (the “One Time Credit”) for the benefit of, and for distribution among, the Users who are shareholders of the Customer (the “Canadian Users”). The One Time Credit shall be payable by Contractor in the manner stipulated in writing by the Customer in a direction delivered to Contractor, which direction shall be delivered to Contractor no later than November 30, 2005. For greater certainty, the Parties expressly acknowledge and agree that the One Time Credit may, in the sole discretion of the Customer expressed in the direction described in the immediately preceding sentence, be payable by Contactor: (i) by way of credit against future Canadian User payment obligations to Contractor (as directed by the Customer); or (ii) by way of payment to the Customer of the One Time Credit (or a combination of (i) and (ii)), within thirty (30) days of receipt by Contractor of the direction described in this Section 6.1(b). For greater certainty, if the amount of any such credit allocated to any Canadian User, as described in (i) in the immediately preceding sentence, exceeds any such Canadian User’s payment obligations to Contractor in the month in which such credit is allocated by Contractor (as described in the immediately preceding sentence), the net amount of such credit in respect of any such Canadian User shall be applied in the next following month, and so on, until such credit is exhausted, unless otherwise directed by the Customer.

(c) Fixed Annual Credit. Subject to the requirements set forth below in this Section 6.1(c), Contractor shall, in each calendar year during the Initial Term beginning in 2006, pay an annual credit in the amount of $[* * * ] for the benefit of, and for distribution among, the Canadian Users (each a “Fixed Annual Credit”). The Fixed Annual Credit shall be payable by Contractor in the manner stipulated in writing by the Customer in a

Page 2

direction delivered to Contractor, which direction shall be delivered to Contractor for each applicable calendar year no later than November 30 of that calendar year during the Initial Term beginning in 2006 . For greater certainty, the Parties expressly acknowledge and agree that the Fixed Annual Credit may, in the sole discretion of the Customer expressed in the direction described in the immediately preceding sentence, be payable by Contractor: (i) by way of credit against future Canadian User payment obligations to Contactor (as directed by the Customer); or (ii) by way of payment to the Customer of the Fixed Annual Credit (or a combination of (i) and (ii)), within thirty (30) days after both (A) Contractor receives the direction described in this Section 6.1(c), and (B) the annual, aggregate volume of executed Ported TN Events exceeds the applicable thresholds set forth below. For greater certainty, if the amount of any such credit allocated to any Canadian User, as described in (i) in the immediately preceding sentence, exceeds any such Canadian User’s payment obligations to the Contractor in the month in which such credit is applied by Contractor (as described in the immediately preceding sentence), the net amount of such credit in respect of any such Canadian User shall be applied in the next following month, and so on, until such credit is exhausted, unless otherwise directed by Customer. The Fixed Annual Credit shall only be payable by Contractor for each calendar year if Canadian Users, in the aggregate for each applicable calendar year, execute: (i) in the calendar year 2006, more than
[* * * ] TN Porting Events; (ii) in the calendar year 2007, more than [* * * ]TN Porting Events; (iii) in the calendar year 2008, more than [* * *] TN Porting Events; (iv) in the calendar year 2009, more than [* * *] TN Porting Events; (v) in the calendar year 2010, more than [* * * ]TN Porting Events; and (vi) in the calendar year 2011, more than [* * * ] TN Porting Events. Notwithstanding anything in this Section 6.1(c) to the contrary, if the number of TN Porting Events in any calendar year does not exceed the volume thresholds set forth in the immediately preceding sentence, then that calendar year’s Fixed Annual Credit forever expires, and in no event shall such Fixed Annual Credit be available or otherwise be used in a subsequent calendar year, provided that neither Party will be prejudiced by any error or mistake in calculating the aggregate number of TN Porting Events described in the immediately preceding sentence. Upon the discovery of any such error the Parties will promptly, and in good faith correct such error, including any adjustment as may be required under this Section.

(d) No Withholding or Deduction. All applicable credits and amounts payable described in Section 6.1(b) and Section 6.1(c) shall be applied and paid, as described herein, without withholding or any deduction whatsoever.

5. Amendment to License

Section 9.2 of the Contractor Services Agreement is amended by adding, as the penultimate sentence:

“The license described in the immediately preceding sentence shall also contain the right of the Contractor, following any Extension Period (as defined in Section 24.3), to review and examine records of the Customer and Users, under reasonable terms and conditions, for the sole purpose of assessing compliance

Page 3

with the obligations of the Customer and the Users in the last paragraph of Section 24.3(a)(ii) and Section 24.3(b)(ii).”

6. Transition at Expiration or Termination of the Agreement

Section 24.3 and Section 24.4 of the Contractor Services Agreement are deleted in their entirety, and the following substituted therefor:

24.3 Termination Plan.

The Contractor and Customer will, within ninety (90) Business Days of the execution and delivery by the Contractor and Customer of a renewal of this Agreement for a period ending December 31, 2011, agree upon a termination plan (the “Termination Plan”), which shall incorporate the following agreements and understandings between the Parties (and including, for greater certainty, the agreements and understandings contained in Article 24.2 and Article 24.4):

(a) Contractor’s Obligation to Assist with Transition — Contractor Termination Event or Contractor Non-Renewal. Upon either: (i) termination of this Agreement by Customer under Section 23.1 (a “Contractor Termination Event”); or (ii) expiration of this Agreement as a result of an election by Contractor not to renew this Agreement under Article 3 in respect of the Term (“Contractor Non-Renewal”), Contractor shall assist Customer in the orderly transition of the Canadian NPAC/SMS and Canadian NPAC/SMS Services from Contractor to a Successor Contractor, in accordance with the following requirements.

Contractor shall, upon thirty (30) Business Days prior written notice from Customer, at the direction and in the sole and exclusive discretion of Customer:

(i) extend the provision of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services as directed by the Customer for that period (the “Extension Period”) ending on the earlier of:

1.	that date upon which Customer and Users complete transition to a Successor Contractor for the provision and administration of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services; and
2.	eight (8) months following: (A) the delivery of the notice of termination in respect of a Contractor Termination Event, in the case of a Contractor Termination Event; and (B) the effective date of the Contractor Non-Renewal, in the case of a Contractor Non-Renewal; and

(ii) license to Customer the Canadian NPAC/SMS Software as directed by the Customer in accordance with Article 9 of this Agreement and subject to Exhibit L.

Page 4

For greater certainty, the license to the Canadian NPAC/SMS Software shall include any Maintenance Modifications created by Contractor during the Extension Period, Enhancements that are subject to a continuing payment obligation under a Statement of Work, Enhancements that are not subject to continuing obligations under a Statement of Work that contain modifications or revisions to the NPAC/SMS Software to correct defects or are necessary for the day to day functionality of the NPAC/SMS (when such modifications or revisions were not otherwise made available to the Customer in a Maintenance Modification or other Enhancement), and Enhancements for which the payments have been completed. To the extent that the Canadian NPAC/SMS Software that is subject to the license contains functionality not purchased by Customer, subject to the foregoing provisions contained in this paragraph, neither Customer, Successor Contractor, nor any User shall be entitled to use or receive such functionality as part of the license.

During any Extension Period contemplated in Section 24.3(a)(i), the Canadian NPAC/SMS Services shall meet or exceed the Service Levels and otherwise be provided in accordance with the applicable provisions of this Agreement, including, but not limited to, the Service Levels in effect on the date of such termination or expiration of the Agreement, as applicable. Without restricting the generality of the foregoing, Contractor shall also provide the Transition Services contemplated in Section 24.4 requested by Customer; provided that Contractor shall have no obligation to perform any such Transition Services after the end of the Extension Period. Notwithstanding the foregoing obligations of Contractor, Contractor’s obligation to perform the Canadian NPAC/SMS Services during any Extension Period described in this Section 24.3(a) shall be subject to Customer using reasonable and diligent efforts to transition to a Successor Contractor beginning no later than: (i) in the case of a Contractor Termination Event, the date of delivery of the notice of termination related to the Contractor Termination Event, or (ii) in the case of Contractor Non-Renewal, the date Contractor delivers the notice of the Contractor Non-Renewal.

(b) Contractor’s Obligation to Assist With Transition — Customer Non-Renewal. Upon expiration of this Agreement as a result of any election by the Customer not to renew this Agreement under Article 3 in respect of the Term, (“Customer Non-Renewal”), Contractor shall assist the Customer in the orderly transition of the Canadian NPAC/SMS and Canadian NPAC/SMS Services from Contractor to a Successor Contractor in accordance with the following requirements.

Contractor shall, upon thirty (30) Business Days prior written notice from the Customer, at the direction and in the sole and exclusive discretion of the Customer:

(i) extend the provision of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services as directed by the Customer for that period of time (also, the “Extension Period”) ending on the earlier of:

Page 5

1.	that date upon which Customer and Users complete transition to a Successor Contractor for the provision and administration of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services; and
2.	eight (8) months following the effective date of the Customer Non-Renewal; and

(ii) license to Customer the Canadian NPAC/SMS Software, as directed by the Customer, in accordance with Article 9 of this Agreement and subject to Exhibit L.

For greater certainty, the license to the Canadian NPAC/SMS Software shall include any Maintenance Modifications created by Contractor during the Extension Period, Enhancements that are subject to a continuing payment obligation under a Statement of Work, Enhancements that are not subject to continuing obligations under a Statement of Work that contain modifications or revisions to the NPAC/SMS Software to correct defects or are necessary for the day to day functionality of the NPAC/SMS (when such modifications or revisions were not otherwise made available to the Customer in a Maintenance Modification or other Enhancement), and Enhancements for which the payments have been completed. To the extent that the Canadian NPAC/SMS Software that is subject to the license contains functionality not purchased by Customer, subject to the foregoing provisions contained in this paragraph, neither Customer, Successor Contractor, nor any User shall be entitled to use or receive such functionality as part of the license.

During any Extension Period contemplated in Section 24.3(b)(i) the Canadian NPAC/SMS Services shall meet or exceed the Service Levels and otherwise be provided in accordance with the applicable provisions of this Agreement, including, but not limited to, the Service Levels in effect on the date of such termination or expiration of the Agreement, as applicable. Without restricting the generality of the foregoing, Contractor shall also provide the Transition Services contemplated in Section 24.4 requested by the Customer; provided that Contractor shall have no obligation to perform any such Transition Services after the end of the Extension Period. Notwithstanding the foregoing obligations of Contractor, Contractor’s obligation to perform the Canadian NPAC/SMS Services during any Extension Period described in this Section 24.3(b) is subject to the Customer using reasonable and diligent efforts to transition to a Successor Contractor beginning no later than the date of delivery, by the Customer, of the notice of Customer Non-Renewal.

(c) Incorporation into Agreement. The Termination Plan when completed shall be incorporated into this Agreement as Exhibit P.

24.4 Transition Services.

Page 6

Without limiting the obligations of Contractor in Section 24.2, Section 24.3(a) and Section 24.3(b), Contractor shall assist and cooperate with Customer in effecting the orderly transition of the Canadian NPAC/SMS and Canadian NPAC/SMS Services to a Successor Contractor by performing the obligations set forth below (collectively, the “Transition Services”) where requested by Customer. The Transition Services shall be provided through any Extension Period under Section 24.2, Section 24.34(a) or Section 24.3(b), as the case may be, or, if the Agreement is not being extended pursuant to such Sections, a period not to exceed eight (8) months after the expiration or termination of the Agreement. Customer shall submit its request for Transition Services in writing to Contractor on or forthwith following the delivery of the applicable notice of non-renewal or termination, as the case may be, described in Section 24.2 or Section 24.3. Contractor and Customer shall, within ten (10) days after Customer’s request for Transition Services, each appoint a representative (the “Transition Team”) who shall, jointly, deliver a preliminary transition plan within twenty (20) days following the appointment of the Transition Team, and shall produce a final plan within twenty (20) days following the joint submission of the preliminary plan, which plans shall set forth the methods and procedures for Customer and Contractor to manage the Transition Services (collectively, the “Transition Plan”). In the event of a failure of agreement, in good faith, on the Transition Plan, the Transition Plan shall be the plan as reasonably directed by Customer. The Transition Team shall meet no less frequently than monthly, acting reasonably, and shall take all steps reasonably necessary to facilitate implementation of the Transition Plan, including meeting by electronic means (including by telephone or other convenient means of communication) no less than daily for the purpose of reporting on matters related to the transition described in this Article, including all issues related thereto. Subject to the foregoing, Contractor agrees to promptly provide the following Transition Services in accordance with this Section 24.4:

(a) provide Customer with a description, in level of detail determined by Customer in its discretion acting reasonably, 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 Canadian NPAC/SMS and Canadian NPAC/SMS Services, in no event in any less detail than that required of the Contractor under Section 1.1 of Exhibit M (Software Escrow Agreement);

(b) provide Customer and/or its designees (including the Successor Contractor) all information, in a level of detail determined by Customer in its discretion acting reasonably, necessary to enable Customer and/or its designees (including the Successor Contractor) to provide the Canadian NPAC/SMS Services;

(c) with respect to any Third Party Software used to provide the Canadian NPAC/SMS Services, Contractor shall provide commercially reasonable assistance to Customer in obtaining, at Customer’s cost, all licenses (and applicable consents, if any) from all applicable vendors necessary for Customer or Successor Contractor to provide the NPAC/SMS Services, as may be reasonably directed by Customer;

Page 7

(d) with respect to any other third party agreements related to or used by Contractor in the delivery of the Services, Contractor shall transfer or assign such agreements (and applicable consents, if any) to Customer or the Successor Contractor, as reasonably directed by Customer, to the extent allowed under those third party agreements;

(e) Contractor shall return to Customer (without retaining copies): (1) all software, documentation, procedures, and other information and materials (including without limitation all tapes, disks, and printed matter) provided by Customer and Users, and (2) the contents of the Canadian NPAC/SMS database, including without limitation all User Data;

(f) Customer’s representatives shall have access at all reasonable times, and in a manner so as not to interfere with the normal business operations of the Contractor, to all Contractor employees, contractors, and other representatives necessary to facilitate the transition of the Canadian NPAC/SMS to a Successor Contractor for the provision of the Services. The Contractor shall permit the co-location of Customer’s representatives with Contractor’s representatives who possess the requisite knowledge in relation to the Services; provided that such Customer’s representatives shall not include a former Contractor employee. The Contractor shall provide Customer’s representatives with access and entry to premises with privileges and on terms and conditions customarily available to consultants of the Contractor, including access to the locations, hardware, information systems, and data located at the premises of the Contractor relevant to the Canadian NPAC/SMS and necessary to manage the Transition Services under the Transition Plan; provided, however, that such representatives execute a commercially reasonable confidentiality agreement with Contractor, and comply with any reasonable Contractor provided workplace rules. Customer shall 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;

(g) Contractor shall make available copies of any policies, procedures and methods of the Contractor that have been implemented by the Contractor in relation to the provision of Canadian NPAC/SMS Services; provided that Contractor shall not be required to divulge any of its financial or other proprietary or Confidential Information, including when such information is contained in its books and records, or any other information relating to the Contractor’s management of its business. To the extent any such policies, procedures and methods are not in writing, the Contractor shall use its reasonable best efforts to impart such policies, procedures and methods verbally during the Extension Period;

(h) In addition to the discharge of the obligations contained herein, the Contractor shall cooperate in good faith with the Successor Contractor in relation to the Transition Services. Contractor hereby acknowledges and agrees that the performance of the Transition Services will transition the Canadian NPAC/SMS, and the provision of Canadian NPAC/SMS Services, to a Successor Contractor. Notwithstanding the foregoing, Contractor shall not be obligated to disclose any information, whether Confidential Information or otherwise, or provide access to Contractor’s facilities,

Page 8

locations, information systems, data, or personnel to a Successor Contractor beyond that specified herein as part of the Transition Services; and

(i) Contractor shall be compensated for the performance of the Transition Services on a time and materials basis as described herein. Contractor will invoice Customer: (i) its time, in accordance with its published standard labor rates, which shall, for the purposes hereof, be offered to the Customer at commercially reasonable rates premised on a base rate of $[* * *] US Dollars [* * *]; and (ii) materials, at Contractor’s cost, without administrative or other markups, provided that: (iii) in the case of a Contractor Termination Event, Contractor’s labor rates will be subject to a discount of [* * *] percent ([* * *]%); and (iv) in the case of a Contractor Non-Renewal, Contractor’s labor rates will be subject to a discount of [* * *] percent ([* * *]%). Contractor shall provide Customer with reasonable estimates of time and materials charges prior to providing Transition Services to Customer.”

7. TN PORTING EVENT CHARGES

Schedule 1, Section 2 of Exhibit E of the Contractor Services Agreement is amended by deleting the entries in the third, fourth and fifth columns of the “TN Porting Event” row, and substituting the information set forth in the table below, entitled “TN Porting Event Charges”, therefor.

TN PORTING EVENT CHARGES

				Price in USD
				(for each TN
				Porting Event
				within
Tiers	Tier Start*	Tier End*	TN Porting Events	applicable Tier)
Tier 1	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 2	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 3	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 4	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 5	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 6	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 7	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 8	[* * *]	[* * *]	[* * *]	$[* * *]
Tier 9	[* * *]	[* * *]	[* * *]	$[* * *]

*   The above tier volumes represent cumulative TN Porting Events measured from [* * *]. The price described above for each TN Porting Event is the price for each TN Porting Event within each Tier set forth above.

Exhibit E of the Contractor Services Agreement is further amended by adding the following paragraph immediately following the table appearing as Schedule 1 (as amended hereby), preceding Note 1:

Page 9

The TN Porting Event charges described in the TN Porting Event row in the foregoing table (the “Amended Rates”) shall be effective as of, and based on, volumes of TN Porting Events executed beginning on [* * *]. Notwithstanding the Amended Rates, if, in any calendar year, including 2005, Users who are shareholders of the Customer (“Canadian Users”), in the aggregate, execute more than [* * *] TN Porting Events, the TN Porting Event charge shall, for the balance of such calendar year in which such number of aggregate TN Porting Events shall have been executed, equal US$[* * * ]. For greater certainty, subject to the immediately preceding sentence, all TN Porting Events executed by Canadian Users in excess of [* * *] TN Porting Events in any calendar year shall be included in the TN Porting Events used to derive applicable TN Porting Event charges in the years following the year in which Canadian Users executed more than [* * * ] TN Porting Events.

8. Royalty Calculation

The following is added as Article 32 to the Contractor Services Agreement:

“ARTICLE 32 – REVISION TO ROYALTY CALCULATION

On or before December 15, 2005 the Contractor Services Agreement shall be amended to reflect the following agreements between the Contractor and Customer, recognizing that the same are broadly drafted and that the expression of these terms, conditions and covenants in the Contractor Services Agreement will require further specific and detailed provisions:

(a) the license contained in Exhibit L to the Master Agreement and royalty calculation set forth in Paragraphs (m) through (o) in Exhibit L (Additional Terms and Conditions of Software License) of the Master Agreement shall be amended to reflect the following:

(i)

subject to paragraph (ii) immediately below, the license rights to the Canadian NPAC/SMS Software shall not include the use of functionality not purchased under a Statement of Work with Contractor. After the conclusion of any Extension Period, (as defined in Article 24 of the Contractor Services Agreement) Contractor shall have the right to audit Users for compliance with the foregoing;

(ii)

the license to the Canadian NPAC/SMS Software under Article 9 of the Contractor Services Agreement shall, for greater certainty, include: (A) any Maintenance Modifications created by Contractor during an Extension Period; (B) any Enhancements that are subject to continuing obligations under a Statement of Work; (C) any Enhancements not subject to a continuing obligation under a Statement of Work that contain modifications or revisions to the NPAC/SMS Software to correct defects or are necessary for the day to day functionality of the NPAC/SMS, when such modifications or revisions were not otherwise made available to the Customer in a Maintenance Modification or other Enhancement; and (D) Enhancements for which the payments have been completed;

Page 10

(iii) the royalty calculation set forth in Paragraphs (m) through (o) in Exhibit L shall be rewritten to simplify its terms and conditions; and

(iv) the terms “Centralized NPAC LLCs” and “Centralized NPAC Agreements” shall be deleted and/or modified together with such other modification as may be necessary in order to clarify and ensure that the royalty calculation set forth in Paragraphs (m) through (o) in Exhibit L relates only functionality acquired by Users, to the exclusion of the United States users and any others. The parties agree, and Contractor represents and warrants, that if the Licence were to be in effect as of the execution date of this letter, the royalty payment under the existing provisions of Exhibit L would be $[* * *] dollars.”

9. Conversion Factor

Unless otherwise specified, pricing in this Amending Agreement is set forth in US Dollars (USD). Any such pricing is subject to the requirements of SOW46, as revised, for converting US Dollars to Canadian Dollars.

10. Consideration

Except as amended by this Amending Agreement, the Contractor Services Agreement (including, without restriction, the obligations of the Contractor related to the Canadian NPAC/SMS) is ratified by the parties hereto. The modifications and amendments made in this Amending Agreement were negotiated together, are interrelated with, and each is made in consideration of all of the other terms and conditions herein, (including, without restriction, the obligations of the Contractor related to the Canadian NPAC/SMS in this Amending Agreement).

11. Amended and Restated Agreement

Promptly after the execution of this Amending Agreement, the parties shall, for administrative and information proposes only, prepare a restate the Contractor Services Agreement, including Exhibits thereof, reflecting the amendments contained herein. For greater certainty, the rights of the Parties shall be defined in the Contractor Services Agreement dated May 19, 1998, as amended by the Canadian NPAC/SMS Contractor Services Amending Agreement dated March 31, 2003 and this Amending Agreement.

12. Miscellaneous

12.1	Order of Precedence. In the event of any conflict or inconsistency among or between the terms of this Amending Agreement or the Contractor Services Agreement, this Amending Agreement shall prevail.
12.2	Amendments. This Amending Agreement may be amended or supplemented only in writing and signed on behalf of the Parties by authorized signatories.

Page 11

12.3	Waiver. No failure or delay of any party in exercising any right or remedy under this Amending Agreement (and no course of dealing between or among the parties) shall operate as a waiver of any such right or remedy.
12.4	Relationship of Parties. There is no relationship of agency, partnership, joint venture, employment between the parties. Neither Party has the authority to bind the other or to incur any obligation or liability on the other’s behalf.
12.5	Third Party Beneficiaries. Except as otherwise expressly set forth herein, the provisions of this Amending Agreement are solely for the benefit of the Parties. No other person, including invitees, members of the general public and other third parties are intended to have nor shall have any rights whatsoever under this Amending Agreement, whether for injury, loss or damage to persons or property, or for economic loss, damage or injury.
12.6	Equitable Relief. Either Party may seek injunctive or other equitable relief to remedy any actual or threatened dispute.
12.7	Entire Agreement. This Amending Agreement, including any supplements hereto, represents the entire agreement between the Parties relating to the subject matter of this Amending Agreement and supersedes any prior representations, discussions, negotiations and agreements, whether written or oral.
12.8	Independent Counsel. This Amending Agreement has been negotiated at arms length and jointly prepared by the parties and their respective counsel of choice.
12.9	Assignment. Neither Party shall assign any of its rights or obligations hereunder without the prior written consent of the other.
12.10	Compliance with Law. The Parties will, at their own expense, operate in full compliance with all laws, rules and regulations applicable to, and maintain in force all licenses and permits required for, their performance under this Amending Agreement.
12.11	Confidentiality. The confidentiality provisions contained in Article 15 of the Contractor Services Agreement shall apply, mutatis mutandis, to this Amending Agreement.
12.12	Definitions. Capitalized terms, and terms having initial capital letters shall, unless otherwise defined herein, have the meanings ascribed thereto in the Contractor Services Agreement.

[THE NEXT PAGE IS THE SIGNING PAGE]

Page 12

     IN WITNESS WHEREOF, each of the parties hereto has executed and delivered this Amending Agreement by its duly authorized representative, effective on the date and year first written above.

CANADIAN LNP CONSORTIUM
INC./CONSORTIUM CANADIEN POUR LA
TNL INC.
Per:	/s/ J. Sarrazin
Name:	Jacques Sarrazin
Title:	President
NEUSTAR, INC.
Per:	/s/ Joseph F. Franlin
Name:	Joseph Franlin
Title:	SC VP Customer relations
Date:	December 19, 2005

Page 13

EX-10.2.2

Exhibit 10.2.2

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

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

[Graphic Omitted: NeuStar Logo]

REVISION 1 TO STATEMENT OF WORK

FOR

CANADIAN VIRTUAL POINT OF PRESENCE

UNDER

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

Page 1

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

REVISION 1 TO STATEMENT OF WORK NO. 37(CA)

UNDER

AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

Canadian Virtual Point of Presence

1. PARTIES

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

2. EFFECTIVENESS

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

3. ADDITIONAL SERVICES

3.1 SOW37 Additional Services

SOW37 provided for the establishment of a virtual point of presence (“VPOP”) in a central location in Mississauga, Canada through which Canadian Users are be able to connect from time to time to Contractor’s Disaster Recovery Data Center, currently located in [* * *] (the “Disaster Recovery Center”).

3.2 Scope of Revision

Customer has requested that Contractor replace the vendor for the VPOP service from Lockheed Martin to [* * *]. On February 20, 2005, Contractor replaced the VPOP vendor in accordance with the foregoing, and began providing VPOP services on such basis on that date. The replacement of the vendor for VPOP services is considered a termination of SOW37 for purposes of Section 8.6 (Termination Charges) under SOW37. The provision of the VPOP by Contractor pursuant to this SOW shall comprise Additional Services. The Additional Services set forth in this SOW are not an Enhancement to the NPAC/SMS Software as defined under the Master Agreement.

Page 2

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

3.3 Revision Additional Services

Contractor shall procure, obtain, and deploy all necessary facilities, hardware, and software, as well as all required licenses, permits, consents, and other rights (the “Underlying Rights”) to establish the VPOP in Mississauga, Ontario, Canada to enable all Users requiring circuit connectivity to the Disaster Recovery Center to connect to such center through the VPOP. Contractor shall be solely and fully responsible for all aspects of the provision of the VPOP including, without limitation, space, equipment, management, Underlying Rights, and the responsibility for the delivery of User traffic between the VPOP and the Disaster Recovery Center.

In order to access the VPOP, Users will be required to bring their fractional T1 or higher circuit(s) to the VPOP, as further described below. The VPOP shall have a capacity equal to eight T1’s. All Users connecting to the VPOP must meet the requirements set forth in the Minimum Connectivity Requirements document issued by Contractor and approved by Customer. The point of demarcation between Users’ and Contractor’s networks shall be the Users’ connection to the VPOP third party service provider’s patch panel (the “Patch Panel”). Users are responsible for their circuit up to such connection. Contractor shall be responsible for connecting its circuit to the VPOP. For the avoidance of doubt, SLR-7 (SOA/LSMS Interface Availability (User)) as set forth in Exhibit G to the Master Agreement, applies from the User’s connection point to the Patch Panel up to and including the Disaster Recovery Data Center.

3.4 Limitations

The provision of the Additional Services set forth in this SOW does not convey any form or type of title or ownership in any real or personal property, including, but not limited to, any networks or any transmission or other facilities and equipment related to the VPOP.

3.5 Non-Interference

Subject to and conditional upon Contractor’s provision of the Additional Services in accordance with this SOW and otherwise in accordance with the Master Agreement, Customer and Users agree that Users’ use of and connection to the VPOP shall at all times be in accordance with the terms and conditions of this SOW and the Master Agreement, and that Users’ use of the VPOP otherwise than in accordance with this SOW and the Master Agreement shall not cause any material negative interference with, or material negative impairment of, delivery of the Services by the Contractor to other Users.

4. OUT OF SCOPE SERVICES

This SOW contains the agreed upon terms and conditions that shall govern Contractor’s performance of the Additional Services described herein. The Additional Services provided for in this SOW, and for which Contractor shall be compensated in accordance with Article 8 and Section 7.2, shall not be interpreted, implied, or assumed to include

Page 3

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

any other service(s) (hereinafter “Out of Scope Services”), which Out of Scope Services shall be provided in accordance with the Master Agreement and, specifically, Article 13, Additional Services.

5. PROJECT SCHEDULE

Contractor shall establish the VPOP by February 20, 2005, and provide the services contemplated under this SOW until the earlier of December 31, 2011 and termination of the Master Agreement.

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	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
Ö	User Documentation
N/A	Software Configuration Management Plan
N/A	Standards and Metrics

7. IMPACTS ON MASTER AGREEMENT

7.1 Applicable

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

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 I Key Personnel
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit M Software Escrow Agreement
None	Exhibit N System Performance Plan for NPAC/SMS Services

Page 4

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

None Exhibit O Statement of Work Cost Principles

7.2 Pricing Schedule

Effective on the Amendment Effective Date, Schedule 1 (Service Element Fees/Unit Pricing) of Exhibit E (Pricing Schedules) of the Master Agreement shall be amended by inserting the following item under Category 2 (Per User/Per Request Charges) as follows:

VPOP access to Disaster Recovery Data Center Per month in accordance with SOW No. 37, Revision 1 CDN$[* * *]

8. PRICING

8.1 Obligation

Upon execution of this SOW, Contractor shall be entitled to be compensated for the Additional Services described herein in the amount and on the terms and conditions described below. Such compensation shall be the obligation of each applicable User, as directed by the Customer. For the purposes of and in accordance with Section 23.3 of the Master Agreement (“Users’ Liability for Payments”), Additional Services, to the extent actually performed, shall be considered to be services performed prior to any such effective date of termination. Accordingly and notwithstanding any other provisions to the contrary in the Master Agreement or any exhibit attached thereto, but subject to Section 23.3 of the Master Agreement, 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 applicable User(s) as provided for herein.

8.2 Compensation

The Parties acknowledge and agree that the pricing for the Additional Services has been derived and calculated in material compliance with Exhibit O of the Master Agreement, which acknowledgment shall not be interpreted as an admission, by either Party, that Exhibit O is or is not a requirement for this SOW. The Contractor further expressly acknowledges and agrees, with respect to the pricing under this SOW, that such pricing shall not in any way be construed, directly or indirectly, as an agreement of, or waiver by, Customer of its rights to enforce the obligations of Contractor under Exhibit O in respect of any Statement of Work entered into by the Parties following the date of this SOW.

The pricing for the Additional Services performed by Contractor shall be equal to a non-recurring fee (“Non-Recurring Fee”) of [* * *] Canadian Dollars [* * *] Cents (CDN$[* * *]), billed in the month following the month in which this Revision is executed and delivered, and a monthly recurring charge (“Monthly Recurring Charge”) of [* * *] Canadian Dollars [* * *] Cents (CDN$[* * *]) to be paid each month during

Page 5

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

which the VPOP is available, beginning the first full month (on a pro-rated basis) after the VPOP is first made available to Users (i.e., the Effective Date).¹

Contractor and Customer acknowledge that because Contractor has billed Users since the Effective Date of this Revision in accordance with the billing requirements of SOW 37 up to and including the month in which this Revision is executed and delivered, Contractor will, where appropriate, apply an adjustment as directed by the Customer to User’s invoices in the month following the month in which this SOW is executed and delivered for the preceding period commencing with Effective Date of this Revision, which adjustment may include a credit against future invoice for the VPOP services provided as Additional Services under this Revision, until exhausted.

Neither the Non-Recurring Fee nor the Monthly Recurring Charge include costs and charges related to bringing User’s circuit to the point of demarcation described in Section 3.2 of this SOW, which costs and charges are the sole responsibility of the User. Both the Non-Recurring Fee and the Monthly Recurring Charge shall be allocated and invoiced among Users in accordance with the Allocation Model delivered by the Customer to the Contractor. Notwithstanding the foregoing, Customer shall have the right to direct Contractor to deviate from the Allocation Model upon thirty (30) days prior written notice.

8.3 Payment

Contractor shall prepare invoices in accordance with the Master Agreement invoicing, which may include invoicing for charges under other Statements of Work agreed to pursuant to Article 13 of the Master Agreement, on the last day of a calendar month and shall send such invoice 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. 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.

8.4 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

¹ The Non-Recurring Fee and the Monthly Recurring Charge are not subject to the annual conversion rate adjustment required under the Amending Agreement, effective March 31, 2003 of the Master Agreement, as implemented in SOW46 (Annual Update to Conversion Factor) because the amounts set forth for each are billed by the provider in Canadian Dollars.

Page 6

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

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

8.5 Taxes

Each User is to remit to or reimburse Contractor for any taxes that it is obligated to pay by law, rule or regulation or under this SOW, the Master Agreement or its respective NPAC/SMS User Agreement.

8.6 Termination Costs under Revision 1

Customer shall be entitled to terminate this SOW37 Revision 1 at any time during the term of provision of the Additional Services under this Revision by Contractor, provided that, in the event of any such termination, Users shall be entitled to re-terminate their circuits in the same fashion, and under the same terms and conditions, as was the case prior to implementation of the VPOP, and the Customer shall pay to Contractor termination charges as a Non-Recurring Fee. With respect to the VPOP vendor under this Revision to SOW37, i.e., [* * *], the following sets forth the method for calculating such termination charges:

(i)	If the termination occurs prior to the first anniversary of the installation of the VPOP services, then the termination charge shall equal the product of (a) the Monthly Recurring Charge and (b) the number of months remaining in the first year of VPOP services between Contractor and the underlying provider.
(ii)	If the termination occurs after the first anniversary of the installation of the VPOP services, then the termination charge shall equal the product of (a) one half (1/2) of the Monthly Recurring Charge and (b) the number of months remaining in the applicable VPOP service term between Contractor and the underlying provider.

Contractor’s agreement with [* * *], as the underlying provider of VPOP services, provides for an initial term of thirty six (36) months commencing on the Effective Date. Contractor shall notify the Customer in writing, at least 10 Business Days prior to the effective date, of any extension, renewal or other modification of the foregoing terms with [* * *], and any other service terms with any other underlying provider with whom Contractor may enter into an agreement in substitution for the agreement with [* * *], regarding the VPOP services under this SOW.

Notwithstanding the foregoing, Contractor represents and warrants that the termination charges are the exact charges (without mark up or margin) payable by Contractor to its VPOP supplier in the event of termination by Contractor pursuant to its agreements with

Page 7

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

its supplier. Contractor agrees that if Contractor becomes entitled to any discount, rebate or other reduction from such termination charges, any such other discount, rebate or reduction shall be applied in favor of the Customer as a dollar for dollar reduction from the termination charges which may otherwise be, or have been, payable by Customer hereunder.

8.7 Termination Costs under SOW37

The Parties acknowledge that the original vendor (Lockheed Martin) for VPOP services under SOW 37 has yet to invoice NeuStar the termination charges referenced in Section 8.6 of SOW 37, and as a result, Contractor cannot ascertain if the underlying vendor is providing any discounts, rebates or other reductions from such termination charges. Contractor and Customer agree that Contractor shall use commercially reasonable efforts to ascertain the termination charges under Section 8.6 of SOW37. The Parties hereby agree that for purposes of calculating the termination charges under Section 8.6 of SOW37, the VPOP services was terminated after 19 months of services (i.e., from July 16, 2003 to February 20, 2005). Upon Contractor ascertaining the termination charges referred to in the immediately preceding sentence, Contractor shall prepare and deliver to the Customer an invoice in respect thereof, which Customer shall pay within forty-five (45) days of receipt.

9. CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT

Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms. From and after the date hereof, any reference in either the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit as modified and amended by this SOW. From and after the Amendment Effective Date, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.

10. MISCELLANEOUS

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

Page 8

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

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

[THIS SPACE INTENTIONALLY LEFT BLANK]

Page 9

Amendment No. 37(CA) Revision 1		Date: February 20, 2005
SOW:	oNo
	þYes

IN WITNESS WHEREOF, the undersigned have executed and delivered this SOW:

CONTRACTOR: NeuStar, Inc.
By:	/s/Joseph F. Franlin
Its:	Joseph F. Franlin
Date:	1/17/06
CUSTOMER: Canadian LNP Consortium, Inc.
By:	/s/ J. Sarrazin
Its:	Jacques Sarrazin
Date:	1/20/06

Page 10

EX-10.4.1

Exhibit 10.4.1

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT 1. CONTRACT ID CODE Page 1 of 2

2. AMENDMENT/MODIFICATION NO. 0001 3. EFFECTIVE DATE 11/12/2003 4. REQUISITION/PURCHASE REQ. NO. 5. PROJECT NO. (If applicable)

6.	ISSUED BY	CODE	00001	7.	ADMINISTERED BY (If other than Item 6)	CODE
FCC/Contracts and Purchasing Center
445 12th St., SW,
Washington, DC 20554

8.	NAME AND ADDRESS OF CONTRACTOR (No., street, county, State and Zip Code)			9A. AMENDMENT OF SOLICITATION NO.
Neustar, Inc.				9B. DATED (SEE ITEM 11)
46000 Center Oak Plaza Sterling, VA 20166			(X)	10A. MODIFICATION OF CONTRACT/ORDER NO. CON03000016
			(X)	10B. DATED (SEE ITEM 13)
CODE*		FACILITY CODE

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

o	The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offers o is extended, o is not extended.
	Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods:
	(a) By completing Items 8 and 15, and returning ___copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12.	ACCOUNTING AND APPROPRIATION DATA (If required)
	No Funding Information

13. THIS ITEM ONLY APPLIES TO MODIFICATION OF CONTRACTS/ORDERS.

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

CHECK ONE
o	A.	THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE CONTRACT ORDER NO. IN ITEM 10A.
o	B.	THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.1 03(b).
o	C.	THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:
o	D.	OTHER (Specify type of modification and authority)
		FAR 1.6, Authority of Contracting Officers”
E. IMPORTANT: Contractor o is not, þ is required to sign this document and return 2 copies to the issuing office.
14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)
The above numbered contract is hereby modified to incorporate the attached security language..
Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A.	NAME AND TITLE OF SIGNER (Type or print)			16A.	NAME AND TITLE OF CONTRACTING OFFICER (Type or print)
					Mark Oakey
15B.	CONTRACTOR/OFFEROR	15C. DATE SIGNED		16B.	United States of America	16C. DATE SIGNED
	/s/ J. F. Franlin
			11/13/03	BY
	(Signature of person authorized to sign)				(Signature of Contracting Officer)

NSN 7540-01-152-8070
PREVIOUS EDITION
UNUSABLE STANDARD FORM 30 (REV. 10-83)
Prescribed by GSA FAR (48 CFR)
53.243

Line Item	Document Number	Title	Page
Summary	CON03000016/0001	NANP Administrator	2 of 2

No Funding Information

Line Item		Delivery Date		Unit of
Number	Description	(Start date to End date)	Quantity	Issue	Unit Price	Total Cost

     No Changed Line Item Fields

Previous Total:
Modification Total:
Grand Total:

     SECURITY AND SUITABILITY ASSESSMENT

1. General

(a) All contract personnel are subjected to background investigations for the purpose of suitability determinations. Based on their proposed duties, some contract personnel may also be required to have security clearance determinations. No contract personnel may be assigned to work on the contract without a favorable initial review of the OF 306, Declaration for Federal Employment (http://www.opm.gov/forms/pdf fill/of0306.pdf) or a written waiver from the FCC Security Operations Center (SOC). (For more detail, see Appendix No. 2)

(b) Suitability, waiver, and security clearance determination investigations are currently conducted through the FCC Security Operations Center (202- 418-7884). The individual contract employee will be provided with a review process before a final adverse determination is made. The FCC requires that any contract personnel found not suitable, or who has a waiver cancelled, or is denied a security clearance, be removed by the contractor during the same business day that the determination is made.

(c) If the contract personnel is re-assigned and the new position is determined to require a higher level of risk suitability than the contract personnel currently holds, the individual may be assigned to such position while the determination is reached by the SOC. A new A-200 may be necessary for the new position.

(d) Contract personnel working as temporary hires (for ninety (90) days or less) must complete and receive a favorable initial review of the OF 306 and complete the contract personnel section of the FCC Form A-600, “FCC Contractor Record Form.” If during the term of their employment they will have access to any FCC network application, they must also complete and sign the FCC Form A-200, “FCC Computer System Application Access Form.”

2. At Time of Contract Award

(a) The FCC Security Operations Center must receive the completed, signed OF 306 for all proposed contractor employees at the time of contract award. Resumes for all personnel proposed for assignment on the contract should be provided to the Security Office prior to the time of in-take processing (see below, 2.3.2). The FCC Security Operations Center requires up to five (5) working days (from the date they are received) to process the OF 306 before any employee is allowed to begin work on the contract. A written waiver from the SOC may be obtained in special circumstances.

All contract personnel, regardless of task description, must complete this form. Without an approved, completed OF 306 on file at the SOC, no contractor employee may begin work. An approved OF 306 is one that has passed initial review by the SOC. During the course of the SOC review of the OF 306, the contract personnel may be interviewed by SOC staff regarding information on their OF 306.

(b) In addition, the Contractor is responsible for submission of completed, signed computer security forms for each employee prior to that person beginning work on the contract (See Appendix No. 3, FCC Instruction 1479.1, FCC Computer Security Program Directive and sample forms.) These forms should be submitted to the FCC Computer Security Office.

(c) The COTR shall begin processing their section of the FCC Contract Personnel Record (FCC Form A-600) at this time. This form, with the COTR and CO portions completed, will be distributed at the time of contract award and must be submitted to the SOC within ten (10) working days.

(d) The Office of Personnel Management (OPM) will issue a Certificate of Investigation (CIN) for each favorably reviewed OF 306. The SOC will issue a memorandum to the CO and COTR listing those contract personnel who have been granted a CIN. This memorandum should be retained for the duration of the contract.

3. Registration and Checkout Requirements

3.1. Locator and Information Services Tracking (LIST) Registration

The Security Operations Center maintains a Locator and Information Services Tracking (LIST) database, containing contact information for all Commission and contract employee personnel, regardless of work location.

The contract employee’s FCC Form A-600, “FCC Contractor Record Form” captures the information for data entry into the LIST system.

3.2 Intake Processing

(a) Following the processing of the OF 306 and an initial favorable suitability determination, (unless otherwise waived) the contract personnel may report to the FCC for work.

(b) On the first day of work, all contract personnel must report to the Security Operations Center to complete the Fingerprint Card Form, FD 258, the Fair Credit Report Act form, and to be photographed and issued a security badge.

(c) At this time the contract employee will be given one of the following forms, based on the security risk designation for the proposed support classification/position, to complete and return to the SOC within seven (7) business days:

(i)	Low Risk Positions - SF 85, Questionnaire for Non-Sensitive Positions
(ii)	Moderate Risk Positions - SF 85-P, Questionnaire for Public Trust Positions
(iii)	High Risk Positions/Secret or Top Secret Security Clearances —Standard Form (SF) 86, Questionnaire for Sensitive Positions

(d) For any contract employee whose name is provided to the Commission for security investigation at (ii) or (iii) level, who subsequently leaves the subject contract, due to Contractor or contract employee decision, within the first year, the Contractor shall reimburse the Commission for the cost of the investigation. If the contract or task order is scheduled for completion in under one year and the contract employee for whom a security investigation has been done leaves prior to the work being done, the Contractor and SOC shall agree on a pro-rated amount for reimbursement. The cost may vary from approximately $400.00 (moderate risk) to $3,000.00 (high risk). The Contractor will be provided a copy of the investigation invoice with the reimbursement request.

3.3 Monthly Personnel Reports

Monthly report: The Contractor’s Program Manager shall submit to the SOC a monthly contract personnel list. This report is currently provided in MS Excel format. The Contractor shall annotate this report and correct and update the information monthly. This report shall highlight or list in some way those individuals who are no longer employed by the Contractor or no longer working on the subject contract. Any additional contract personnel that have been successfully processed for work on the contract since the previous report shall also be noted. The annotated monthly contract personnel list report shall be submitted to the following, via email, by the 10th calendar day of each month:

FCC Security Operations Center
Contracting Officer
Contracting Officer’s Technical Representative (COTR)

3.4 Checkout Processing:

(a) All contract employees no longer employed on the subject contract, or at the termination of the contract, are required to report to the SOC and complete the sign-out portion of the FCC A-600, Contract Personnel Record.

(b) This process verifies the ID badge and keys (if any) have been returned to the SOC by the contract personnel.

(c) If the checkout processing is not completed by the contract employee, the Contractor shall take action to ensure its accomplishment no later than 30 days after the employee’s departure from the FCC.

(d) The Contractor shall be liable to the FCC for an administrative processing charge of $150.00 (One Hundred Fifty Dollars), for each of their contractor employees who leaves their duty assignment at the Commission and fails to complete the checkout processing within 30 (thirty) calendar days of departure. Mellon Bank, N.A., handles collection and processing of all Commission administrative charges and should payment become necessary, the Contractor will be provided the appropriate directions for an EFT.

(e) The Contractor shall be liable for any actual damages arising from a failure to ensure that the checkout processing occurs within the 30 (thirty) calendar days of the contract employee’s departure from the FCC.

4. Computer Security

4.1. FCC Computer Security Program Directive Specifications

Contractors shall ensure that:

     a. any contractor employee assigned to this contract who is required, by their duties to be issued a FCC computer network id., obtain, read, understand and comply with the policy and procedures of Directive, 1479.1, Computer Security Program (Appendix No. 3) which outlines safeguards to be followed for the protection of agency sensitive and mission critical data;

     b. appropriate forms are completed and submitted to FCC OMD-ITC for processing required to gain, modify and server computer systems access. Forms include FCC Computer System Office Application and/or System Access Form, Form A-200 (used to identify the user requesting access to FCC computer resources), FCC Computer System Access Acknowledgement, Form A-201, (used to verify user’s obligations to secure the Commission’s computer system and data), FCC Computer System Personally-Owned Software Installation Certification, Form A-202 (used to identify properly licensed personal software to install on a particular PC), and FCC Computer System Separation Clearance, Form A-203 (used to announce the user’s intention to relinquish computer system access rights);

     c. access to FCC computer systems is requested and limited only on an “as needed basis” to perform official FCC business; and

     d. contractor promotes the security of FCC information systems and data when being accessed by the contractor. I n addition, contractor shall ensure that computer systems, related hardware and authorizations are not modified by the contractor without express written consent from the Government.

EX-10.7.1

Exhibit 10.7.1

SECOND AMENDMENT TO
COMMON SHORT CODE LICENSE AGREEMENT
Implementation of 6-Digit CSCs

     This Second Amendment to the Common Short Code License Agreement, Statement: Statement of Work dated as of the ___ day of January, 2006 between NeuStar, Inc., a Delaware corporation, with offices located at 46000 Center Oak Plaza, Building X, Sterling, VA 20166 (“NeuStar”) and the Cellular Telecommunications and Internet Association (“CTIA”), a District of Columbia non-profit corporation, located at 1400 16^th Street, NW, Suite 600, Washington, DC 20036.

     WHEREAS, NeuStar entered into a Common Short Code License Agreement with the CTIA (“License Agreement”) dated October 17, 2003 to develop and maintain a database of common short codes, to process common short code applications and assign common short codes to applicants and to engage in other Registry Services on behalf of members of the wireless industry;

     WHEREAS, NeuStar and CTIA now desire to amend certain terms of the License Agreement pursuant to Article 9 of the License Agreement to (i) allow for the registration of six (6) digit CSCs (each a “6-digit CSC”), (ii) upgrade the Registry Database and associated Registry Services, and (iii) to revise the Assignment Guidelines to reflect modified specifications from the Common Short Code Working Group.

     NOW, THEREFORE, in consideration of the mutual covenants contained herein and other good and valuable consideration, receipt of which is hereby acknowledged, the parties agree as follows:

I. Terms used in this Second Amendment and not otherwise defined shall have the same meaning set forth in the License Agreement.

II. Six-Digit Common Short Codes.

A.	Lease of 6 Digit CSCs. Commencing no later than ninety (90) days after the execution of this Second Amendment, Registry shall be entitled to lease six (6) digit CSCs in accordance with Article 6 of the License Agreement and with the Assignment Guidelines as modified in this Second Amendment.
B.	Grandfathered CSCs. No later than fifteen days prior to the launch of such 6-digit CSCs (“6-digit Launch Date”), Carriers may request 6-digit CSCs to be reserved from the CSC pool, rendering them unavailable for general registration on the 6-digit Launch Date as a CSC (“6-Digit Grandfathered CSC”). Carriers may return 6-digit Grandfathered CSCs to the available pool of CSCs at any time.
C.	Types of 6-Digit CSCs. There shall be Random, Selected and Carrier Reserved 6-Digit CSCs leased in accordance with sections 6.3.3, 6.3.4 and 6.3.5 of the License Agreement.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 1 of 35

D. 6-digit CSCs are CSCs. Except as set forth in Section II.A above, 6-Digit CSCs shall be treated the same as CSCs for all other purposes set forth in the License Agreement.

III. CSC Version 2.0.

A.	NeuStar shall, either itself, or in conjunction with other third parties, implement CSC version 2.0, which shall include the additional functionality set forth in Attachment 1, attached hereto (“CSC 2.0”)
B.	For purposes of the License Agreement, the functionalities listed under New Registry Database Functionality in Attachment Number 1 shall be considered an “Enhancement” as defined in Section 1.21 of the License Agreement. Therefore, the New Registry Database Functionality shall be considered “Registry IP” and owned exclusively by the Registry pursuant to Section 7.3 of the License Agreement.
C.	For purposes of the License Agreement , the enhancements listed under New CSC Website Enhancements as well as any CSC Data associated or related to CSC 2.0 shall be considered “CSC Enhancements” as defined in Section 1.16 of the License Agreement. Therefore, the New CSC Website Functionality and any related CSC Data generated by such Functionality shall be considered CSC Registry Rights and owned exclusively by CTIA, on behalf of all Participating Carriers, pursuant to Section 7.1 of the License Agreement.
D.	The Parties hereby agree that all transition requirements applicable to 5-Digit CSCs shall also be applicable to 6-Digit CSCs under the terms and conditions set forth in Article 17 of the License Agreement.

IV. 6-Digit Fees. CTIA agrees to pay Registry the fees set forth in Exhibit C-2 of the License Agreement for each 6-digit CSC.

V. Assignment Guidelines v. 1.1. The Parties hereby agree to delete Exhibit E to the License Agreement and replace such Exhibit with the new Exhibit E, attached hereto as Attachment 2.

VI. Except as specifically modified by this Second Amendment, the terms and conditions of the License Agreement shall remain in full force and effect.

     IN WITNESS WHEREOF, the parties have caused this Amendment to be duly executed as of the date first written above.

NEUSTAR, INC		CTIA
By: /s/ Steven Boyce		By: /s/ R. Mesirow
	Name: Steven Boyce		Name: R. Mesirow
	Title: VP + Controller		Title: VP Operations
	Date: 01/20/06		Date: 1/31/06

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 2 of 35

ATTACHMENT NUMBER 1 TO THE
SECOND AMENDMENT TO
COMMON SHORT CODE LICENSE AGREEMENT

CSC 2.0 FUNCTIONALITY

The following represents the material additional functionality that will be added to the CSC Registry Database and Website, which shall comprise CSC 2.0.

I. New Registry Database Functionality

1. Registry shall allow for the registration of Random and Selected 6-Digit CSCs by members of the public.

2. Registry shall update the Registry Database to allow CSC Registrants to pay for their CSC leases via Visa, MasterCard and American Express credit cards.

3. Registry shall ensure that all renewal terms for CSCs shall correspond to the expiration of the previous term, rather than the date of payment for such renewal.

4. Registry shall provide CSC applicants with the ability to add a basic content rating (i.e., Over/Under 18 years of age).

5. Registrants shall have the ability to copy information about a particular CSC from one application or registration into an application for an additional CSC.

6. In the CSC Application, Registrants will have the ability to select a particular Content Aggregator from a drop-down list.

7. Registry shall ensure that Carriers are provided with notices of deactivation in the event that CSCs are not renewed and paid within 30 days after expiration of the CSC.

8. Registry shall update the CSC application fields to allow for the use of Internationalized characters.

9. Registry shall allow CSC Registrants to add additional billing contacts for each CSC.

10. Registry shall provide e-mail reminder notices to Applicants for CSCs which have been registered or renewed, but are unpaid.

11. Carriers shall have the ability to opt-in or Opt-out of all types of Registry notices.

12. Registry shall incorporate a tool for end users to provide comments / suggestions to the Registry and CTIA on the US CSC program and the CSC Website.

II. New CSC Website Enhancements

1. The CSC Website shall be redesigned to minimize the number of steps to register a CSC.

2. Registry shall include actual examples of existing CSC programs (i.e., ESPN, ClearChannel, etc.) on the CSC Website. In addition, the CSC Website shall contain “case studies” and “model” CSC programs. Such content shall be supplied by CTIA to Registry to include on the Website. CTIA shall procure the intellectual property rights and associated licenses from third parties (if any are required) to display such content on the Website. Content may also be supplied directly by third party content providers that license such content directly to the CTIA and Registry to use on the CSC Website.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 3 of 35

3.	Registry shall revise the “Step by step process” for leasing CSCs currently located at: http://www.usshortcodes.com/content/csc_obtain.html
4.	Registry shall compile Website user statistics which shall be provided to CTIA in periodic reports, which shall be no more than once per month.
5.	Registry shall replace certain graphics on the Website.
6.	Registry shall include on the Website home page a section entitled “What’s New” to contain dynamic content supplied by CTIA and Registry. Registry’s website support team shall provide the support for updating this section.
7.	Registry shall also include on the home page of the Website a section entitled “Calendar/Events” which shall supply the end user with information related to events, trade shows and conferences that are related to the United Stated CSC program. Registry’s website support team shall provide the support for updating this section.
8.	The CSC Website shall contain a page dedicated to CSC advertising and promotions as agreed to by the Parties.
9.	The Registry shall, with the assistance of the CTIA, develop a Webpage on the CSC Website that describes how an end user sends an SMS message using a CSC.
10.	The Parties shall work together to develop a CSC User Guide to place on the CSC Website that shall provide end users with the rules related to the deployment of CSC programs.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 4 of 35

ATTACHMENT NUMBER 2 TO THE
SECOND AMENDMENT TO
COMMON SHORT CODE LICENSE AGREEMENT

AMENDED AND RESTATED EXHIBIT E TO THE
COMMON SHORT CODE ADMINISTRATION AGREEMENT
Assignment Guidelines

COMMON SHORT CODE
ADMINISTRATION
GUIDELINES

Version 1.1
January 20, 2006

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 5 of 35

Table of Contents

1.	Common Short Code Service Overview
2.	Common Short Code Namespace
3.	Common Short Code Users
4.	Common Short Code Application Process
5.	Common Short Code Address Database
6.	Common Shot Code Customer Service

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 6 of 35

1. Common Short Code Service Overview

Short codes are a string of numeric digits used to address wireless messages. Wireless carriers administer their own list of short codes. Common short codes (CSC) are short codes that are administered by a single CSC Administrator for a group of wireless carriers.

1.1 Wireless Messaging and Short Codes

Wireless messaging allows mobile subscribers to send and receive messages with other subscribers or with applications. A telephone number will be used when sending a message to another subscriber. Messages sent to other subscribers are like email, and include text such as “I’ll be there in 10 minutes”.

Some examples of applications used in wireless messaging are; TV voting/polling, information requests, direct response marketing promotions and wireless advertising. Rather than use telephone numbers to address applications carriers use short codes. For example, if a wireless user wants to request football scores by using a short code they could create a message with the text “Football scores” and address it to a short code such as 29876. The application provider would then send football scores to the subscriber’s mobile.

1.2 Functional Roles Involved in Short Codes

There are a number of roles involved in enabling and using short code related applications:

• End users — persons or entities that will utilize short codes for communication with applications

• Carriers — provide the network infrastructure for delivery of messages between the end user and connection aggregators or application providers. A Carrier may also act as a connection aggregator, application provider, or applicant for CSCs. In such an event that Carrier will be bound by the same rules and obligations as any other connection aggregator, application provider or applicant.

• Connection aggregator — may provide connectivity between carrier networks and application providers

• Application providers — provide the technology platform for a short code service application

• Content provider — the entity that owns or has the right to content and licenses such content to the application provider for delivery to the end user

It’s possible for the application provider to also be the content provider. For example an application provider could provide ring tones as content. It’s also possible for the same company to be both a connection aggregator and an application provider. Therefore it’s possible for the connection aggregator, the application provider and the content provider to be the same company.

Attachment 4 provides a diagram of the roles involved in short code service delivery.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 7 of 35

1.3 Common Short Codes

Short codes are currently offered on a carrier-by-carrier basis with no coordination of codes for identical applications. This limits applications to specific carriers and requires end users to recognize the specific short codes used by their carrier. This type of approach fragments the marketing message and limits content provider participation.

CSCs are a specific type of short code that will enable the same short code across multiple carriers thus increasing traffic and reducing user confusion. This document addresses CSCs that will be administered by a single CSC Administrator for a group of US wireless carriers.

A CSC Registry provides the operational aspects of the Administrator’s functions. The Registry will maintain a single database of available, reserved, and registered CSCs. Some of the Registry’s responsibilities include; providing the day to day operations, administering the resource, implementing and maintaining the CSC administration platform, developing and implementing guidelines, and facilitating the manual and automated implementation of CSCs across multiple carriers.

In addition to the roles identified in Section 1.2, CSCs require two additional roles:

          CSC Administrator — is the entity providing the administration of the CSCs. CTIA is the US Common Short Code Administrator.

          CSC Registry — provides the operational aspects of the Administrator’s functions. NeuStar is the US Common Short Code Registry.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 8 of 35

2. Common Short Codes Namespace

The industry will introduce the CSC service in 4Q03 using CSCs in the format of five (5) and six (6) digit short codes. The digits 0 and 1 will not be used as the first digit of a CSC to avoid potential conflicts with existing dialing plans. The potential CSCs at introduction will be within the ranges:

                    Five Digit CSCs:  20000-99999 = 80,000 potential CSCs
                    Six Digit CSCs:   222222-999999 = 777,778 potential CSCs

Some short codes within the range of potential CSCs will be reserved and therefore will not be available for assignment as a CSC. The remaining short codes within the defined range are eligible for use as CSCs. Each carrier retains the right to support traffic, or not support traffic for a leased CSC. However a carrier cannot use a leased CSC for a purpose other than that which it has been leased during its term.

CSCs are only to be used between mobile devices and applications. A CSC registrant cannot lease, sublicense or otherwise transfer a CSC nor the rights to an application within that CSC to a third party, in accordance with the Registrant Sublicense Agreement.

2.1 Reserved Short Codes

Reserved Short Codes are short codes within the range of potential CSCs that are reserved for other purposes and therefore are not available to be used as CSCs. There are no code-specific charges associated with reserved codes. There are two categories of reserved codes;

• Grandfathered — those currently used by carriers to provide short code related services

• Carrier-specific — those reserved after introduction of the CSC service by an individual carrier

2.1.1 Grandfathered Codes

Individual carriers and groups of carriers have introduced short code related services using short codes that fall within the range of the 5 or 6 digit CSCs. It is necessary for the Registry to identify these short codes and reserve them so that they are not included in the pool of available CSCs.

Prior to the introduction of the CSC service each carrier will provide the Registry a list of short codes it is currently using within the defined 5 or 6 digit range. The Registry will register these codes as unavailable; they will be grandfathered for the carrier. They will not be able to be registered as a random CSC, selected CSC, or carrier-specific code.

The Registry will register; 1) the code and 2) the carrier. The effective date for all grandfathered codes will be 15 days prior to introduction of the CSC service. (The date of CSC service introduction will be determined by a written agreement between the CSC Administrator and the CSC Registry.) The Registry will only disclose that the code is not available for registration as a CSC. It will not disclose the carrier that registered the code.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 9 of 35

If a Carrier decides that it is no longer necessary to reserve the grandfathered code they may contribute the code to the pool of CSCs. This process is depicted in Attachment 2. The carrier’s primary point of contact with the Registry will send an email to the Registry identifying the code(s) contributed and the date of contribution. The Registry will store a copy of the correspondence in its records.

It is possible that more than one carrier will have claimed the code as a grandfathered code. If no other carrier still has the code reserved as a grandfathered code it will be placed in the pool of CSCs and will start a 90-day aging period where it cannot be assigned as a CSC. Carriers will be notified, via email, each time a grandfathered code enters the 90-day aging period. They will not be told which carrier contributed it. Any carrier can reserve the code as a carrier-specific code during the 90-day aging period.

2.1.2 Carrier-specific Codes

After implementation of the CSC service carriers will still have the ability to reserve short codes within the range of CSCs for its own purposes as long as the code is not already registered. If the code is already registered as a CSC the carrier’s reservation request will be denied. The lessee has the right to renew that same code when its term is expiring, assuming it has abided by the terms of the registrant sub-license agreement. Once a carrier reserves a carrier-specific code it is removed from the pool of available CSCs.

The Registry will register; 1) the code, 2) the carrier, and 3) the date it was reserved. The Registry will only disclose that the code is not available for registration as a CSC. It will not disclose the carrier that registered the code.

If a Carrier decides that it is no longer necessary to reserve the carrier-specific code they can contribute it to the pool of CSCs following the process defined in Section 2.1.1.

2.2 Common Short Codes

Common Short Codes (CSCs) are those short codes within the defined range available for registration as a CSC. CSCs are subject to registrations fees from the Registry. There are two types of CSCs;

• Random CSCs — the applicant registers a CSC randomly selected by the Registry

• Selected CSCs — the applicant selects the CSC that it wants to register

2.2.1 Random CSCs

Applicants can choose to have a CSC randomly assigned to their application by the Registry. In the event that the applicant chooses a random CSC the CSC will not be assigned to the application until the Registry approves the application. A CSC will be assigned using an algorithm that searches the list of available CSCs.

2.2.2 Selected CSCs

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 10 of 35

Applicants can select a specific CSC for their application. Selected CSCs will be assigned on a first-come first-served basis. Prior to submitting the application the applicant can perform a CSC query to determine the availability of the desired CSC. If the applicant requests a CSC that is reserved or already registered the application will automatically be rejected. The applicant will have the opportunity to select a different CSC. If the CSC is available the Registry will review the application. Once the Registry receives the application it will be timestamped with the date and time in the event that there is a conflict between two applicants requesting the same CSC. The requested code will be placed in reserved status until the application is rejected or accepted.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 11 of 35

3. Common Short Code Users

The Registry website will be available to the public for the purposes of finding general information regarding CSCs. There are three entities that will have secure access to the Registry system and be able to view specific information about specific CSCs. Those are:

• Applicants — those that have submitted an application CSC, but have not yet had it approved by the Registry

• Registrants — those that have applied for and been assigned a CSC

• Carriers — telecommunications service providers that will be notified of the CSC assignment and may decide to implement the CSC in their network

3.1 Applicant Account Set-up

An entity that decides to submit an application for a CSC will first be required to set up an account with the Registry. If the applicant has already set up an account the applicant can go directly to the Existing User Login page and login with their user name and password.

If the applicant does not have an account it must first set one up by filling out the appropriate information (see Applicant Information section of application form in Attachment 1 of this document) at the Account Set-up page. Once the potential applicant has an account they can then log on to the Registry system and fill out a CSC application (see Attachment 1). The application is sent to the Registry for review. Once they submit an application they can review the status of that application through their secure access to the Registry system.

Applicants have the following permissions:

• Modify account information

• Receive alerts related to applications

• View status with regard to pending applications (e.g., approved or rejected with comments)

3.2 Registrants

Once the Registry approves the application the selected or random CSC is assigned to the application. At this point the applicant’s status changes to that of a registrant because they are no longer awaiting assignment of the CSC.

Registrants have the following permissions:

• Modify account information

• Receive alerts related to registered CSCs

• View all of their existing registration records

• View assigned CSC status information such as carrier expiration date

• Submit modification request of certain CSC information (excluding the name of the Content Provider) and view status

• Submit renewal request for CSC and view status

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 12 of 35

3.3 Carriers

The Registry will work directly with representatives from the Carriers to identify a primary point of contact (POC). The Registry will set up an account for the POC, with a User Name and Password provided by the POC. The POC can modify the Password once they log-on to the Registry system.

The POC will have the following permissions:

• Modify account information

• Receive all carrier alerts generated by the Registry

• View applications (excluding payment information such as credit card numbers)

• Submit carrier status information related to specific CSCs (e.g., opt-in, opt-out)

• Add other carrier contacts for the purposes of receiving alerts, viewing applications, or submitting status information

If there is a need to change the POC the Registry will work directly with the current POC.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 13 of 35

4. Common Short Code Application Process

Registry users with an active account can submit an application for a CSC. The processes defined in this section are depicted in Attachment 2.

4.1 Application Submission

Applicants can submit an application by logging on to the Registry system using their User name and Password. If they plan on applying for a Selected CSC they should first perform a CSC query to determine if the desired CSC is available for assignment. If the desired CSC is designated as unavailable the applicant should not request it, the application will automatically be rejected.

To fill out an application the applicant would go to the CSC Application page on the secure website. The applicant can request up to twenty CSCs on one application form. Since the applicant has already set up an account with the Registry the applicant information portion of the application will already be filled out with their specific information. The applicant will then fill out the rest of the application. A CSC can be reserved for three, six, and twelve month terms.

Once the application is complete the applicant will hit the Submit button on the application. The Registry will receive an alert (all alerts associated with the Registry are via email) that an application was submitted and the application will be placed in the Registry’s work item list. (A work item list is the first page a user views after they logon to the Registry system. Attachment 3 provides examples of the work item lists provided by the Registry for each of the users.) If the application is properly submitted the applicant will receive an alert from the Registry that the application was received and will be reviewed.

4.2 Registry Review

The Registry will review the application for completeness and whether information on the application is erroneous on its face. If the application is not complete or found to be in error it will be rejected with an explanation. The applicant will receive an alert from the Registry that the application was rejected. They can then log-on to the Registry system and review the Registry’s explanation as to why it was rejected. The rejected application will be on the applicant’s work item list. If the applicant had selected a specific CSC that CSC will be reserved for the next fourteen (14) calendar days so the applicant has an opportunity to modify and resubmit their application.

Once the Registry approves an application a CSC will be assigned. If they requested a random CSC the Registry system will use a random selection algorithm to assign a CSC to the application. If they chose a Selected CSC that CSC will be assigned to the application. Upon approval the applicant/registrant and the carriers will receive an alert from the Registry that the application was approved. They can then log-on to the Registry system and view the approved application.

The information included in the application will then become part of a CSC registration record. This will serve as the form that will be viewed by the registrant, Registry and Carriers on an ongoing basis.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 14 of 35

All of the Carriers will receive an alert that a CSC has been assigned and a registration record is available to be reviewed.

The carriers can log-on to the Registry system to review the registration records. These registration records will appear in their work item list. If the carrier has any questions about the registration they can contact either the Registry or the registrant by phone or email.

4.3 CSC Addressing File

The CSC addressing file is generated from the registration records in the Registry’s master CSC address database. It is an ASCII text file containing the mapping information for CSCs and their respective Application Providers. The Registry updates the file every Friday and makes it available for download from the secure website. Carrier’s can use the file to create or verify its own CSC addressing tables.

Each line in the CSC addressing file constitutes one CSC to Application Provider mapping record whose fields are delimited by a comma (“,”). The format of the record is defined as follows:

<CSC>,<Application Provider>,<Expiration Date>,<Program Start Date>, <Program End Date>

where <CSC> is a common short code, <Application Provider> is the identity string of the Application Provider whose application is addressed by the CSC, <Expiration Date> is the expiration date of the CSC, <Program Start Date> is the date when the content program of the CSC starts, and <Program End Date> is the date when the content program of the CSC terminates.

The date format is “MM/DD/YYYY”, where MM is the two digits for a month, DD is the two digits for a date, and “YYYY” is the four digits for the year. They are separated by the forward slash (“/”). This format applies to the three date fields in a record. For single digit month or date, the left digit is default to zero (“0”).

4.4 Carrier Implementation Status

Each participating Carrier will be able to register their status with regard to whether they plan to opt-in or opt-out of the program associated with the specific CSC. The default condition will be no reply. This status information will not be disclosed, in any way, to other carriers or applicants.

4.5 CSC Expiration

Before a CSC’s term expires, the registrant and the Carriers will receive alerts notifying them of the expiration date. The alerts will be sent 30 days, 15 days, 5 days and 1 day prior to the expiration date. When the term expires the registrants and Carriers will receive an alert notifying them that the CSC has expired and it is no longer assigned to the registrant.

Once a CSC expires it is given a ninety-day aging period where it will not be available for assignment. The aging period also serves as a grace period where the past registrant can renew the registration. Once the aging period expires the CSC will be placed in the pool of available CSCs.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 15 of 35

4.6 Modify Existing Registrations

Registrant’s must notify the Registry when any information in its registration record changes. The Registrants will access the Registry’s system to modify the existing registration record. Once it is modified it will be submitted to the Registry for approval and will follow the same process defined in Section 4.2 for a new application.

4.7 Opt-in / Spam Protection

To avoid costly customer complaints due to unsolicited messages, every application must be offered on an “opt-in” basis. This requires the customer to initially participate by sending a MO message to the application or registering on a web page for the service. Customer opt-ins will be on a per campaign basis, i.e. opting in to a particular campaign does not extend to other campaigns that might be offered by the same application or content provider. A registrant may use the opt-in database created by one campaign for future campaigns, but first must obtain approval on a carrier-by-carrier basis for each new campaign.

At the time of the sign-up or opt-in, the customer needs to be clearly identified by their MSISDN and the time of the subscription shall be recorded. Users who register via a web page must be verified as the actual owner of the registered number. For example, pass codes can be sent to a registered number and registration will remain incomplete until the pass code is entered.

Furthermore, all application providers must be capable of tracing and shutting down potential Spam sources and provide customers an easy and intuitive way to opt-out of CSC applications. A universal keyword may be used to opt customers out of CSC applications. Customers would be able to opt-out of any CSC application by sending the same keyword (e.g. cancel) to the application short code.

It shall be the role of the carrier to determine whether a specific program used in connection with the CSC is not adhering to these Opt-in / Spam Protection requirements. In such an event, the carrier will discontinue service to that CSC or to entities associated with providing services for that CSC.

4.8 Monitoring Applicant and Registrant Behavior

It’s possible that some Applicants and Registrants could attempt to abuse the CSC administrative process. One example of abuse is registering a CSC for the purposes of stopping another entity from registering it or for the purposes of reselling it. The Registry will monitor the behavior of Applicants and Registrants in order to identify any potential abusive behavior. If the Registry identifies any potentially abusive behavior it will contact the Applicant or Registrant and attempt to understand and if necessary correct the behavior. It may ultimately be necessary for the Registry to take corrective action such as closing the Applicant account.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 16 of 35

5. Common Short Code Customer Care

5.1 Registry User Customer Care

Customer care will be able to address any issues related to the Registry function such as status of applications, questions about how to fill out an application and issues concerning user profiles. Users can communicate with customer service via phone calls, email or fax. Standard hours of operation are 9AM to 8PM Eastern Time, Monday through Friday, excluding holidays. There will also be customer care support beyond standard hours via pager. Of course they will restrict access to information in the same manner that the Registry system does. For example one registrant cannot find out information about another registrant’s CSC.

5.2 Public Website

The Registry public website is a place where interested parties can go to obtain general information about CSCs. There will be FAQs, general descriptions of CSC related applications and services, general descriptions of Registry functions and processes, and other general informational documentation.

In addition to general information the public will be able to perform a query on a specific CSC to see whether it is available for assignment. The only information provided to the public will be whether the code is available or not available.

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 17 of 35

ATTACHMENT 1 TO GUIDELINES
[SEE EXHIBIT E-1 BELOW]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 18 of 35

ATTACHMENT 2 TO THE ASSIGNMENT GUIDELINES
[PAGE LEFT INTENTIONALLY BLANK]

     [Graphic Omitted: Account Creation]

[Graphic Omitted: Account Log in]

[Graphic Omitted: Account Expiration]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 19 of 35

ATTACHMENT 3 TO THE ASSIGNMENT GUIDELINES: WORK ITEM LISTS

CSCA Home Page:

[Graphic Omitted: CSCA Home Page]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 20 of 35

Account Creation:

[Graphic Omitted: Account Creation]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 21 of 35

Account Creation — continued:

[Graphic Omitted: Account Creation — continued]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 22 of 35

Check CSC Availability:

[Graphic Omitted: Check CSC Availability]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 23 of 35

Possible results of availability check:

[Graphic Omitted: Possible results of availability check]

[Graphic Omitted: Public Search Page]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 24 of 35

Registrant / Applicant Specific Forms:

Applicant work list:

[Graphic Omitted: Applicant work list]

Update Registrant Account information:

[Graphic Omitted: Registrant Account Information]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 25 of 35

Search for CSC codes from Registrant Home Page:

[Graphic Omitted: Search for CSC codes from Registrant Home Page]

Application for new CSC code(s): See Schedule 1 to Exhibit E of the Common Short Code Administration License Agreement

Confirmation Page:

[Graphic Omitted: Confirmation Page]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 26 of 35

Carrier Specific Forms:

Carrier work list:

[Graphic Omitted: Carrier work list]

Review Application / Opt-in or Opt-out:

[Graphic Omitted: Opt-in or Opt-out]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 27 of 35

After selection to Opt-in for a CSC:

[Graphic Omitted: After selection to Opt-in for a CSC]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 28 of 35

Search for Specific CSC Registration:

[Graphic Omitted: Search for Specific CSC Registration]

View Reserved Short Code List:

[Graphic Removed: View Reserved Short Code List]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 29 of 35

Pending Payment Applications:

[Graphic Omitted: Pending Payment Applications]

Update Account Information:

[Graphic Omitted: Update Account Information]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 30 of 35

ATTACHMENT 4 TO THE ASSIGNMENT GUIDELINES
[SEE NEXT PAGE, THIS PAGE INTENTIONALLY BLANK]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 31 of 35

[Graphic Omitted: CSC Functional Roles]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 32 of 35

SCHEDULE 1 TO
EXHIBIT E
OF THE
COMMON SHORT CODE ADMINISTRATION AGREEMENT
Application Form

Application for new CSC code(s):

[Graphic Omitted: Application for new CSC code(s)]

Application for new CSC code(s) — continued:

[Graphic Omitted: Application for new CSC code(s) — continued]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 33 of 35

Application for new CSC code(s) — continued:

[Graphic Omitted: Application for new CSC code(s) — continued]

Application for new CSC code(s) — continued:

[Graphic Omitted: Application for new CSC code(s) — continued]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 34 of 35

Application for new CSC code(s) — continued:

[Graphic Omitted: Application for new CSC code(s) — continued]

Second Amendment to Common Short Code License Agreement v. 1
January 5, 2006
Page 35 of 35

EX-10.38.1

Exhibit 10.38.1

AMENDMENT NO. 3 TO CREDIT AGREEMENT
AND WAIVER

     This Amendment No. 3 and Waiver to Credit Agreement (this “Agreement”) dated as of February 15, 2005 is made by and between NEUSTAR, INC., a Delaware corporation having its principal place of business in Sterling, Virginia (the “Borrower”), and BANK OF AMERICA, N.A., a national banking association organized and existing under the laws of the United States (“Bank of America”), in its capacity as administrative agent for the Lenders (as defined in the Credit Agreement (as defined below)) (in such capacity, the “Administrative Agent”), and each of the Lenders signatory hereto, and each of the Guarantors (as defined in the Credit Agreement) signatory hereto.

WITNESSETH:

     WHEREAS, the Borrower, the Administrative Agent and the Lenders have entered into that certain Credit Agreement dated as of August 14, 2002, as amended by Amendment No, 1 to Credit Agreement dated as of October 1, 2003 and Amendment No. 2 to Credit Agreement dated as of August 30, 2004 (and as hereby amended and as from time to time hereafter further amended, modified, supplemented, restated, or amended and restated, the “Credit Agreement”; capitalized terms used in this Agreement not otherwise defined herein shall have the respective meanings given thereto in the Credit Agreement), pursuant to which the Lenders have made available to the Borrower a revolving credit facility, including a letter of credit facility; and

     WHEREAS, in respect of Amendment No. 2, the parties intended and agreed that the Maturity Date under the Credit Agreement would be extended for 180 days; and

     WHEREAS, Amendment No. 2 contained an scrivener’s error and incorrectly stated that the Maturity Date was amended to be “January 8, 2005” rather than “February 15, 2005”; and

     WHEREAS, the Borrower desires to extend the Maturity Date until August 15, 2005, and

     WHEREAS, the Borrower has requested that the Credit Agreement he amended to reflect such extension in the Maturity Date;

     WHEREAS, on February 1, 2005, the Borrower acquired Fiducianet, Inc., a Delaware corporation for a purchase price of 52,200,000 in cash and 25,533 share of common stock of the Borrower (the “Fiducianet Acquisition”) ; and

     WHEREAS, the Borrower has requested that the Lenders waive the requirements of the Pledge Agreement and Section 7.12 of the Credit Agreement with respect to the Fiducianet Acquisition;

     NOW, THEREFORE, in consideration of the premises and further valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties hereto agree as follows:

     1. Amendments to Credit Agreement. Subject to the terms and conditions set forth herein, the Credit Agreement is hereby amended as follows:

     A. Section 1.11 is amended to restate the definition of “Maturity Date” in its entirety to read as follows:

     “Maturity Date” means August 15, 2005.

     B. Section 8.03 is amended to restate clause (g) thereof in its entirety to read as follows:

     (g) unsecured Indebtedness in an aggregate principal amount not to exceed (i) 51,500,000 at any time outstanding during the period from the Closing Date through and including December 31, 2002 and (ii) $2,500,000 at any time outstanding after December 31, 2002 (but excluding from such amount up to $3,000,000 of Indebtedness owing to Bank of America, N.A., and incurred by the Borrower by an assumption of debt on behalf of NeuStar Funding, which Indebtedness was originally incurred by NeuStar Funding pursuant to a Credit Agreement dated as of October 1, 2003);

     2. Waiver of Joinder and Other Requirements with Respect to Fiducianet Acquisition. Subject to the terms and conditions set forth herein, the Lenders hereby waive (i) any Default arising under the Credit Agreement solely as a result of the Fiducianet Acquisition and (ii) the requirements of Section 7..12 of the Credit Agreement with respect to Fiducianet, Inc. In addition, all requirements of the Pledge Agreement with respect to the Subsidiary Securities of Fiducianet, Inc. are hereby waived.

     3. Effectiveness: Conditions Precedent. The effectiveness of this Agreement and the amendments to the Credit Agreement herein provided are subject to the satisfaction of the following conditions precedent:

     (a) the Administrative Agent shall have received each of the following documents or instruments in form and substance reasonably acceptable to the Administrative Agent:

(i)	four (4) original counterparts of this Agreement, duly executed by the Borrower, the Administrative Agent, each Guarantor and the Required Lenders; and
(ii)	such other documents, instruments, opinions, certifications, undertakings, further assurances and other matters as the Administrative Agent shall reasonably request; and

2

     (b) all fees and expenses payable to the Administrative Agent and the Lenders (including the reasonable fees and expenses of counsel to the Administrative Agent estimated to date) shall have been paid in full (without prejudice to final settling of accounts for such fees and expenses).

     4. Consent of the Guarantors. Each Guarantor hereby consents, acknowledges and agrees to the amendments set forth herein and hereby confirms and ratifies in all respects the Guaranty to which such Guarantor is a party (including without limitation the continuation of such Guarantor’s payment and performance when due of the obligations thereunder upon and after the effectiveness of this Agreement and the amendments contemplated hereby) and the enforceability of such Guaranty against such Guarantor in accordance with its terms.

     5. Representations and Warranties. In order to induce the Administrative Agent and the Lenders to enter into this Agreement, the Borrower represents and warrants to the Administrative Agent and the Lenders as follows:

     (a) The representations and warranties made by the Borrower in Article VI of the Credit Agreement and in each of the other Loan Documents to which it is a party are true and correct on and as of the date hereof, except to the extent that such representations and warranties expressly relate to an earlier date;

     (b) Since the date of the most recent financial reports of the Borrower delivered pursuant to Section 7.01 of the Credit Agreement, no act, event, condition or circumstance has occurred or arisen which, singly or in the aggregate with one or more other acts, events, occurrences or conditions (whenever occurring or arising), has had or could reasonably he expected to have a Material Adverse Effect;

     (c) The Persons appearing as Guarantors on the signature pages to this Agreement constitute all Persons who are required to be Guarantors pursuant to the terms of the Credit Agreement and the other Loan Documents, including without limitation all Persons who became Subsidiaries or were otherwise required to become Guarantors after the Closing Date, and each of such Persons has become and remains a party to a Guaranty as a Guarantor;

     (d) This Agreement has been duly authorized, executed and delivered by the Borrower and the Guarantors and constitutes a legal, valid and binding obligation of such parties, except as may be limited by genera’ principles of equity or by the effect of any applicable bankruptcy, insolvency, reorganization, moratorium or similar law affecting creditors’ rights generally; and

     (e) No Default or Event of Default has occurred and is continuing.

     6. Entire Agreement. This Agreement, together with all the Loan Documents (collectively, the “Relevant Documents”), sets forth the entire understanding and agreement of the parties hereto in relation to the subject matter hereof and supersedes any prior negotiations and agreements among the parties relating to such subject matter. No promise, condition, representation or warranty, express or implied, not set forth in the Relevant Documents shall bind any party hereto, and no such party has relied on any such promise, condition,

3

representation or warranty, Each of the parties hereto acknowledges that, except as otherwise expressly stated in the Relevant Documents, no representations, warranties or commitments, express or implied, have been made by any party to the other. None of the terms or conditions of this Agreement may be changed, modified, waived or canceled orally or otherwise, except in writing and in accordance with Section 11.01 of the Credit Agreement,

     7. Full Force and Effect of Agreement. Except as hereby specifically amended, modified or supplemented, the Credit Agreement and all other Loan Documents are hereby confirmed and ratified in all respects and shall be and remain in full force and effect according to their respective terms.

     8. Counterparts. This Agreement may be executed in any number of counterparts, each of which shall be deemed an original as against any party ‘.hose signature appears thereon, and all of which shall together constitute one and the same instrument.

     9. Governing Law. This Agreement shall in all respects be governed by, and construed in accordance with, the laws of the State of New York applicable to contracts executed and to be performed entirely within such State, and shall be further subject to the provisions of Section 11.16 of the Credit Agreement.

     10. Enforceability. Should any one or more of the provisions of this Agreement be determined to be illegal or unenforceable as to one or more of the parties hereto, all other provisions nevertheless shall remain effective and binding on the parties hereto.

     11. References. All references in any of the Loan Documents to the “Credit Agreement” shall mean the Credit Agreement, as amended hereby.

     12. Successors and Assigns. This Agreement shall be binding upon and inure to the benefit of the Borrower, the Administrative Agent and each of the Guarantors and the Lenders, and their respective successors, lea] representatives, and assignees to the extent such assignees arc permitted assignees as provided in Section 11.07 of the Credit Agreement.

[Signatures on following page.]

4

     IN WITNESS WHEREOF, the parties hereto have caused this Amendment No. 3 to Credit Agreement and Waiver to be made, executed and delivered by their duly authorized officers as of the day and year first above written.

BORROWER:

NEUSTAR, INC.

By: /s/ Jeffrey E. Ganek                    
Name: Jeffrey E. Ganek
Title: Chairman

GUARANTORS:

BIZTELONE, INC.

By: /s/ Jeffrey E. Ganek                    
Name: Jeffrey E. Ganek
Title: CEO

NIGHTFIRE ACQUISITION CORPORATION

By: /s/ Jeffrey E. Ganek                    
Name: Jeffrey E. Ganek
Title: CEO

ADMINISTRATIVE AGENT:

BANK OF AMERICA, N.A., as Administrative Agent

By: /s/ Barbara P. Levy                    
Name: Barbara P. Levy
Title: Senior Vice President

LENDERS:

BANK OF AMERICA, N.A.,

By: /s/ Barbara P. Levy                    
Name: Barbara P. Levy
Title: Senior Vice President

EX-10.38.2

Exhibit 10.38.2

AMENDMENT NO. 5 TO CREDIT AGREEMENT

     This Amendment No. 5 to Credit Agreement (this “Agreement”) dated as of February 10, 2006 is made by and between NEUSTAR, INC., a Delaware corporation having its principal place of business in Sterling, Virginia (the “Borrower”), and BANK OF AMERICA, N.A., a national banking association organized and existing under the laws of the United States (“Bank of America”), in its capacity as administrative agent for the Lenders (as defined in the Credit Agreement (as defined below)) (in such capacity, the “Administrative Agent”), and each of the Lenders signatory hereto, and each of the Guarantors (as defined in the Credit Agreement) signatory hereto.

WITNESSETH:

     WHEREAS, the Borrower, the Administrative Agent and the Lenders have entered into that certain Credit Agreement dated as of August 14, 2002, as amended by Amendment No. 1 to Credit Agreement dated as of October 1, 2003, Amendment No. 2 to Credit Agreement dated as of August 30, 2004, Amendment No. 3 to Credit Agreement and Waiver dated as of February 15, 2005 and Amendment No. 4 to Credit Agreement dated as of August 12, 2005 (and as hereby amended and as from time to time hereafter further amended, modified, supplemented, restated, or amended and restated the “Credit Agreement”; capitalized terms used in this Agreement not otherwise defined herein shall have the respective meanings given thereto in the Credit Agreement), pursuant to which the Lenders have made available to the Borrower a revolving credit facility, including a letter of credit facility; and

     WHEREAS, the Maturity Date of such revolving credit facility is February 10, 2006; and

     WHEREAS, the Borrower has requested that the Credit Agreement be amended to extend the Maturity Date to August 10, 2006;

     NOW, THEREFORE, in consideration of the premises and further valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties hereto agree as follows:

     1. Amendment to Credit Agreement. Subject to the terms and conditions set forth herein. Section 1.01 of the Credit Agreement is amended to restate the definitions of “Maturity Date” in its entirety to read as follows:

          “Maturity Date” means August 10, 2006.

     2. Effectiveness: Conditions Precedent. The effectiveness of this Agreement and the amendments to the Credit Agreement herein provided are subject to the satisfaction of the following conditions precedent:

     (a) the Administrative Agent shall have received each of the following documents or instruments in form and substance reasonably acceptable to the Administrative Agent:

(i)	four (4) original counterparts of this Agreement, duly executed by the Borrower, the Administrative Agent, each Guarantor and the Required Lenders; and
(ii)	such other documents, instruments, opinions, certifications, undertakings, further assurances and other matters as the Administrative Agent shall reasonably request: and

     (b) all fees and expenses payable to the Administrative Agent and the Lenders (including the reasonable fees and expenses of counsel to the Administrative Agent estimated to date) shall have been paid in full (without prejudice to final settling of accounts for such fees and expenses).

     3. Consent of the Guarantors. Each Guarantor hereby consents, acknowledges and agrees to the amendments set forth herein and hereby confirms and ratifies in all respects the Guaranty to which such Guarantor is a party (including without limitation the continuation of such Guarantor’s payment and performance when due of the obligations thereunder upon and after the effectiveness of this Agreement and the amendments contemplated hereby) and the enforceability of such Guaranty against such Guarantor in accordance with its terms.

     4. Representations and Warranties. In order to induce the Administrative Agent and the Lenders to enter into this Agreement, the Borrower represents and warrants to the Administrative Agent arid the Lenders as follows:

     (a) The representations and warranties made by the Borrower in Article VI of the Credit Agreement and in each of the other Loan Documents to which it is a party are true and correct on and as of the date hereof, except to the extent that such representations and warranties expressly relate to an earlier date;

     (b) Since the date of the most recent financial reports of the Borrower delivered pursuant to Section 7.01 of the Credit Agreement, no act, event, condition or circumstance has occurred or arisen which, singly or in the aggregate with one or more other acts, events, occurrences or conditions (whenever occurring or arising), has had or could reasonably be expected to have a Material Adverse Effect;

     (c) The Persons appearing as Guarantors on the signature pages to this Agreement constitute all Persons who are required to be Guarantors pursuant to the terms of the Credit Agreement and the other Loan Documents, (except as may have been waived in writing by the Required Lenders) including without limitation all Persons who became Subsidiaries or were otherwise required to become Guarantors after the Closing Date, and each of such Persons has become and remains a party to a Guaranty as a Guarantor;

     (d) This Agreement has been duly authorized, executed and delivered by the Borrower and the Guarantors and constitutes a legal, valid and binding obligation of such parties, except as may be limited by general principles of equity or by the effect of any applicable bankruptcy, insolvency, reorganization, moratorium or similar law affecting creditors’ rights generally; and

2

     (e) No Default or Event of Default has occurred and is continuing.

     5. Entire Agreement. This Agreement, together with all the Loan Documents (collectively, the “Relevant Documents”), sets forth the entire understanding and agreement of the parties hereto in relation to the subject matter hereof and supersedes any prior negotiations and agreements among the parties relating to such subject matter. No promise, condition, representation or warranty, express or implied, not set forth in the Relevant Documents shall bind any party hereto, and no such party has relied on any such promise, condition, representation or warranty. Each of the parties hereto acknowledges that, except as otherwise expressly stated in the Relevant Documents, no representations, warranties or commitments, express or implied, have been made by any party to the other. None of the terms or conditions of this Agreement may he changed, modified, waived or canceled orally or otherwise, except in writing and in accordance with Section 11.01 of the Credit Agreement.

     6. Full Force and Effect of Agreement. Except as hereby specifically amended, modified or supplemented, the Credit Agreement and all other Loan Documents are hereby confirmed and ratified in all respects and shall he and remain in full force and effect according to their respective terms.

     7. Counterparts. This Agreement may be executed in any number of counterparts, each of which shall be deemed an original as against any party whose signature appears thereon, and all of which shall together constitute one and the same instrument.

     8. Governing Law. This Agreement shall in all respects be governed by, and construed in accordance with, the laws of the State of New York applicable to contracts executed and to be performed entirely within such State, and shall be further subject to the provisions of Section 11.16 of the Credit Agreement.

     9. Enforceability. Should any one or more of the provisions of this Agreement be determined to be illegal or unenforceable as to one or more of the parties hereto, all other provisions nevertheless shall remain effective and binding on the panics hereto.

     10. References. All references in any of the Loan Documents to the “Credit Agreement” shall mean the Credit Agreement, as amended hereby.

     11. Successors and Assigns. This Agreement shall be binding upon and inure to the benefit of the Borrower, the Administrative Agent and each of the Guarantors and the Lenders, and their respective successors, legal representatives, and assignees to the extent such assignees are permitted assignees as provided in Section 11.07 of the Credit Agreement.

3

     IN WITNESS WHEREOF, the parties hereto have caused this Amendment No. 5 to Credit Agreement to be made, executed and delivered by their duly authorized officers as of the day and year first above written.

BORROWER:

NEUSTAR, INC.

By: /s/ Jeffrey Babka                    
Name: Jeffrey Babka
Title: CFO

GUARANTORS:

BIZTELONE, INC.

By: /s/ Jeffrey Babka                    
Name: Jeffrey Babka
Title: CFO

NIGHTFIRE ACQUISITION CORPORATION

By: /s/ Jeffrey Babka                    
Name: Jeffrey Babka
Title: CFO

ADMINISTRATIVE AGENT:

BANK OF AMERICA, N.A. as Administrative Agent

By: /s/ Barbara P. Levy                    
Name: Barbara P. Levy
Title: Senior Vice President

LENDERS:

BANK OF AMERICA, N.A.

By: /s/ Barbara P. Levy                    
Name: Barbara P. Levy
Title: Senior Vice President

EX-21.1

Exhibit 21.1

Subsidiaries of the Registrant

Company Name	Jurisdiction of Organization
BizTelOne, Inc.	Delaware
Foretec Seminars, Inc.	Delaware
NeuLevel, Inc.	Delaware
NeuStar Funding, LLC	Delaware
NeuStar International, Inc.	Delaware
NeuStar International Services, Inc.	Delaware
NeuStar Secretariat Services, LLC	Delaware
NeuStar Subsidiary Corporation	Delaware

EX-23.1

Exhibit 23.1

CONSENT OF INDEPENDENT REGISTERED PUBLIC ACCOUNTING FIRM

     We consent to the incorporation by reference in the Registration Statement (Form S-8 No. 333-128418) pertaining to the 1999 Equity Incentive Plan and the 2005 Stock Incentive Plan of NeuStar, Inc. of our report dated March 10, 2006, with respect to the consolidated financial statements and schedule of NeuStar, Inc., included in the Annual Report (Form 10-K) for the year ended December 31, 2005.

/s/ Ernst & Young LLP

McLean, Virginia
March 24, 2006

EX-31.1

Exhibit 31.1

CERTIFICATION OF CHIEF EXECUTIVE OFFICER

I, Jeffrey E. Ganek, certify that:

1.	I have reviewed this annual report on Form 10-K of NeuStar, Inc.;
2.	Based on my knowledge, this report does not contain any untrue statement of a material fact or omit to state a material fact necessary to make the statements made, in light of the circumstances under which such statements were made, not misleading with respect to the period covered by this report;
3.	Based on my knowledge, the financial statements, and other financial information included in this report, fairly present in all material respects the financial condition, results of operations and cash flows of the registrant as of, and for, the periods presented in this report;
4.	The registrant’s other certifying officer(s) and I are responsible for establishing and maintaining disclosure controls and procedures (as defined in Exchange Act Rules 13a-15(e) and 15d-15(e)) for the registrant and have:

a)	Designed such disclosure controls and procedures, or caused such disclosure controls and procedures to be designed under our supervision, to ensure that material information relating to the registrant, including its consolidated subsidiaries, is made known to us by others within those entities, particularly during the period in which this report is being prepared;
b)	Evaluated the effectiveness of the registrant’s disclosure controls and procedures and presented in this report our conclusions about the effectiveness of the disclosure controls and procedures, as of the end of the period covered by this report based on such evaluation; and
c)	Disclosed in this report any change in the registrant’s internal control over financial reporting that occurred during the registrant’s most recent fiscal quarter (the registrant’s fourth fiscal quarter in the case of an annual report) that has materially affected, or is reasonably likely to materially affect, the registrant’s internal control over financial reporting; and

5. The registrant’s other certifying officer(s) and I have disclosed, based on our most recent evaluation of internal control over financial reporting, to the registrant’s auditors and the audit committee of the registrant’s board of directors (or persons performing the equivalent functions):

a)	All significant deficiencies and material weaknesses in the design or operation of internal control over financial reporting which are reasonably likely to adversely affect the registrant’s ability to record, process, summarize and report financial information; and
b)	Any fraud, whether or not material, that involves management or other employees who have a significant role in the registrant’s internal control over financial reporting.

March 29, 2006	/s/ Jeffrey E. Ganek
	Jeffrey E. Ganek
	Chairman and Chief Executive Officer
	(Principal Executive Officer)

EX-31.2

Exhibit 31.2

CERTIFICATION OF CHIEF FINANCIAL OFFICER

I, Jeffrey A. Babka, certify that:

1.	I have reviewed this annual report on Form 10-K of NeuStar, Inc.;
2.	Based on my knowledge, this report does not contain any untrue statement of a material fact or omit to state a material fact necessary to make the statements made, in light of the circumstances under which such statements were made, not misleading with respect to the period covered by this report;
3.	Based on my knowledge, the financial statements, and other financial information included in this report, fairly present in all material respects the financial condition, results of operations and cash flows of the registrant as of, and for, the periods presented in this report;
4.	The registrant’s other certifying officer(s) and I are responsible for establishing and maintaining disclosure controls and procedures (as defined in Exchange Act Rules 13a-15(e) and 15d-15(e)) for the registrant and have:

a)	Designed such disclosure controls and procedures, or caused such disclosure controls and procedures to be designed under our supervision, to ensure that material information relating to the registrant, including its consolidated subsidiaries, is made known to us by others within those entities, particularly during the period in which this report is being prepared;
b)	Evaluated the effectiveness of the registrant’s disclosure controls and procedures and presented in this report our conclusions about the effectiveness of the disclosure controls and procedures, as of the end of the period covered by this report based on such evaluation; and
c)	Disclosed in this report any change in the registrant’s internal control over financial reporting that occurred during the registrant’s most recent fiscal quarter (the registrant’s fourth fiscal quarter in the case of an annual report) that has materially affected, or is reasonably likely to materially affect, the registrant’s internal control over financial reporting; and

5. The registrant’s other certifying officer(s) and I have disclosed, based on our most recent evaluation of internal control over financial reporting, to the registrant’s auditors and the audit committee of the registrant’s board of directors (or persons performing the equivalent functions):

a)	All significant deficiencies and material weaknesses in the design or operation of internal control over financial reporting which are reasonably likely to adversely affect the registrant’s ability to record, process, summarize and report financial information; and
b)	Any fraud, whether or not material, that involves management or other employees who have a significant role in the registrant’s internal control over financial reporting.

March 29, 2006	/s/ Jeffrey A. Babka
	Jeffrey A. Babka
	Senior Vice President and Chief Financial Officer
	(Principal Financial Officer)

EX-32.1

Exhibit 32.1

CERTIFICATION PURSUANT TO 18 U.S.C. 1350

Pursuant to 18 U.S.C. 1350, each of the undersigned certifies in his capacity as an officer of NeuStar, Inc. that, to the best of his knowledge:

1. The annual report on Form 10-K of NeuStar, Inc. for the year ended December 31, 2005 fully complies with the requirements of Section 13(a) or 15(d) of the Securities Exchange Act of 1934; and

2. Information contained in such annual report on Form 10-K fairly presents, in all material respects, the financial condition and results of operation of NeuStar, Inc.

March 29, 2006	By:	/s/ Jeffrey E. Ganek
		Jeffrey E. Ganek
		Chief Executive Officer
March 29, 2006	By:	/s/ Jeffrey A. Babka
		Jeffrey A. Babka
		Chief Financial Officer

This written statement is being furnished to the Securities and Exchange Commission as an exhibit to such Form 10-K. A signed original of this statement has been provided to NeuStar, Inc. and will be retained by NeuStar, Inc. and furnished to the Securities and Exchange Commission or its staff upon request.

EX-99.1

Exhibit 99.1

North American Numbering Council
(NANC)

Functional Requirements Specification

Number Portability Administration Center (NPAC)

Service Management System (SMS)

Release 3.3.2a

March 9, 2006

Related Publications

NPAC SMS Interoperable Interface Specification (IIS), Version 3.3.2a March 9, 2006.

Illinois Commerce Commission Number Portability Administration Center and Service Management System Request for Proposal (ICC NPAC/SMS RFP), February 6, 1996.

Generic Requirements for SCP Application and GTT Function for Number Portability, ICC LNP Workshop SCP Generic Requirements Subcommittee.

Generic Switching and Signaling Requirements for Number Portability, version 1.03, ICC LNP Workshop Switch Generic Requirements Subcommittee, September 4, 1996.

Report on Local Number Portability, Industry Numbering Committee (INC).

FCC 96-286 First Report And Order, CC Docket No. 95-116, July 2, 1996.

CTIA Report on Wireless Portability Version 2, July 7, 1998

Release 3.3: © COPYRIGHT 1997 — 2006 NeuStar, Inc.

The Work may be freely redistributed 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 , or requested by writing to FSF, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. 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.

The purpose of the NeuStar, Inc. copyright and GNU General Public License on this Work is to ensure that this Work and any subsequent derivations thereof remain non-proprietary.

Table of Contents

Table of Contents

0.      PREFACE	0-0
0.1      Document Structure	0-0
0.2      Document Numbering Strategy	0-1
0.3      Document Version History	0-2
0.3.1      Release 1.0	0-2
0.3.2      Release 2.0	0-2
0.3.3      Release 3.0	0-3
0.3.4      Release 3.1	0-3
0.3.5      Release 3.2	0-3
0.3.6      Release 3.3	0-3
0.4      Abbreviations and Notations	0-4
0.5      Document Language	0-6
1.      INTRODUCTION	1-1
1.1      NPAC SMS Platform Overview	1-1
1.2      NPAC SMS Functional Overview	1-1
1.2.1      Provisioning Service Functionality	1-1
1.2.2      Disconnect Service Functionality	1-2
1.2.3      Repair Service Functionality	1-2
1.2.4      Conflict Resolution Functionality	1-2
1.2.5      Disaster Recovery and Backup Functionality	1-2
1.2.6      Order Cancellation Functionality	1-3
1.2.7      Audit Request Functionality	1-3
1.2.8      Report Request Functionality	1-3
1.2.9      Data Management Functionality	1-3
1.2.9.1     NPAC Network Data	1-3
1.2.9.2     Service Provider Data	1-4
1.2.9.3     Subscription Version Data	1-4
1.2.10     NPA-NXX Split Processing	1-4
1.2.11     Business Days/Hours	1-5
1.2.12     Timer Types	1-6
1.2.13     Recovery Functionality	1-6
1.2.13.1     Network Data Recovery	1-7
1.2.13.2     Subscription Data Recovery	1-7
1.2.13.3     Notification Recovery	1-8
1.2.13.4     Service Provider Data Recovery	1-8
1.2.14     Number Pooling Overview	1-9
1.2.15     Time References in the NPAC SMS	1-12
1.2.16     SV Type and Alternative SPID in the NPAC SMS	1-14

Release 3.3: © 1997 — 2006 NeuStar, Inc.	i	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

1.3      Background	1-14
1.4      Objective	1-17
1.5      Assumptions	1-17
1.6      Constraints	1-19
2.      BUSINESS PROCESS FLOWS	2-1
2.1      Provision Service Process	2-1
2.1.1      Service provider-to-service provider activities	2-1
2.1.2      Subscription version creation process	2-1
2.1.2.1     Create Subscription Version	2-2
2.1.2.2     Request missing/late notification	2-2
2.1.2.3     Final Concurrence Notification to Old Service Provider	2-2
2.1.3      Service providers perform physical changes	2-2
2.1.4      NPAC SMS “activate and data download” process	2-2
2.1.4.1     New Service Provider sends activation to NPAC SMS	2-2
2.1.4.2     NPAC SMS broadcasts network data to appropriate Service Providers	2-3
2.1.4.3     Failure — notify NPAC	2-3
2.1.4.4     Initiate repair procedures	2-3
2.1.5      Service providers perform network updates	2-3
2.2      Disconnect Process	2-3
2.2.1      Customer notification, Service Provider initial disconnect service order activities	2-3
2.2.2      NPAC waits for effective release date	2-4
2.2.3      NPAC donor notification	2-4
2.2.4      NPAC performs broadcast download of disconnect data	2-4
2.3      Repair Service Process	2-4
2.3.2      Service provider analyzes the problem	2-5
2.3.3      Service provider performs repairs	2-5
2.3.4      Request broadcast of subscription data	2-5
2.3.5      Broadcast repaired subscription data	2-6
2.4      Conflict Process	2-6
2.4.1      Subscription version in conflict	2-6
2.4.1.1     Cancel-Pending Acknowledgment missing from new Service Provider	2-6
2.4.1.2     Old Service Provider requests conflict status	2-6
2.4.1.3     Change of status upon problem notification	2-6
2.4.1.4     Change of status upon Old Service Provider non-concurrence	2-6
2.4.1.5     Change of status upon New Service Provider non-concurrence	2-7
2.4.2      New Service Provider coordinates conflict resolution activities	2-7
2.4.2.1     Cancel pending notification	2-7
2.4.3      Subscription version cancellation	2-8
2.4.4      Conflict resolved	2-8
2.5      Disaster Recovery and Backup Process	2-8
2.5.1      NPAC personnel determine downtime requirement	2-8
2.5.2      NPAC notifies Service Providers of switch to backup NPAC and start of cutover quiet period	2-8
2.5.3      Service providers connect to backup NPAC	2-8
2.5.4      Backup NPAC notifies Service Providers of application availability and end of cutover quiet period	2-9

Release 3.3: © 1997 — 2006 NeuStar, Inc.	ii	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

2.5.5      Service providers conduct business using backup NPAC	2-9
2.5.6      Backup NPAC notifies Service Providers of switch to primary NPAC and start of cutover quiet period	2-9
2.5.7      Service providers reconnect to primary NPAC	2-9
2.5.8      Primary NPAC notifies Service Providers of availability and end of cutover quiet period	2-9
2.6      Service Order Cancellation Process	2-9
2.6.1      Service Provider issues service order cancellation	2-9
2.6.2      Service provider cancels an un-concurred Subscription Version	2-10
2.6.3      NPAC requests missing acknowledgment from Service Provider	2-10
2.6.4      NPAC cancels the Subscription Version and notifies both Service Providers	2-10
2.7      Audit Request Process	2-10
2.7.1      Service provider requests audit	2-10
2.7.2      NPAC SMS issues queries to appropriate Service Providers	2-10
2.7.3      NPAC SMS compares Subscription Version data	2-11
2.7.4      NPAC SMS updates appropriate Local SMS databases	2-11
2.7.5      NPAC SMS sends report of audit discrepancies to requesting SOA	2-11
2.7.6      NPAC SMS sends report of audit results to requesting SOA	2-11
2.8      Report Request Process	2-11
2.8.1      Service provider requests report	2-11
2.8.2      NPAC SMS generates report	2-11
2.8.3      Report delivered via NPAC Administrative or SOA Low-Tech Interface, Email, electronic file, fax, printer	2-12
2.9     Data Administration Requests	2-12
2.9.1     Service provider requests administration of data by NPAC personnel	2-12
2.9.2     NPAC SMS personnel confirms user’s privileges	2-12
2.9.3     NPAC SMS personnel inputs user’s request	2-12
2.9.4     NPAC SMS performs user’s request	2-12
2.9.5     NPAC SMS personnel logs request denial if user’s privileges are not validated	2-12
3.     NPAC DATA ADMINISTRATION	3-1
3.1     Overview	3-1
3.1.1     Data Type Legend	3-1
3.1.2     NPAC Customer Data	3-2
3.1.3     Subscription Version Data	3-11
3.1.4     Network Data	3-19
3.2     NPAC Personnel Functionality	3-21
3.2.1     Block Holder, Mass Update	3-23
3.2.2     Service Provider ID (SPID) Migration Update	3-24
3.3     System Functionality	3-28
3.4     Additional Requirements	3-32
3.4.1     NPA-NXX Data Validations	3-34
3.5     NPA Splits Requirements	3-35
3.5.1     NPA-NXX-X, NPA Splits	3-43
3.5.2     Block Holder, NPA Splits	3-46
3.6     NPA-NXX Filter Management Requirements	3-48

Release 3.3: © 1997 — 2006 NeuStar, Inc.	iii	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

3.7     Business Hour and Days Requirements	3-49
3.8     Notifications	3-51
3.8.1     TN Range Notification Indicator	3-51
3.8.2     Customer No New SP Concurrence Notification Indicator	3-51
3.8.3     SOA Notification Priority	3-52
3.8.4     TN and Number Pool Block in Notifications	3-53
3.8.5     SV Type and Alternative SPID Indicators	3-54
3.9     Multiple Service Provider Ids Per SOA Association Requirements	3-56
3.10     Bulk Data Download Functionality	3-58
3.10.1     Bulk Data Download Functionality — General	3-58
3.10.2     Network Data, Bulk Data Download	3-58
3.10.3     Subscription Version, Bulk Data Download	3-60
3.10.4     NPA-NXX-X Holder, Bulk Data Download	3-63
3.10.5     Block Holder, Bulk Data Downloads	3-63
3.10.6     Notifications, Bulk Data Download	3-65
3.10.7     Bulk Data Download Response Files	3-66
3.11     NPA-NXX-X Information	3-68
3.11.1     NPA-NXX-X Download Indicator Management	3-68
3.11.2     NPA-NXX-X Holder Information	3-69
3.11.3     NPA-NXX-X Holder, NPAC Scheduling/Re-Scheduling of Block Creation	3-71
3.11.4     NPA-NXX-X Holder, Addition	3-74
3.11.5     NPA-NXX-X Holder, Modification	3-76
3.11.6     NPA-NXX-X Holder, Deletion	3-77
3.11.7     NPA-NXX-X Holder, First Port Notification	3-79
3.11.8     NPA-NXX-X Holder, Query	3-80
3.11.9     NPA-NXX-X Holder, Bulk Data Download	3-80
3.12     Block Information	3-81
3.12.1     Version Status	3-81
3.12.2     Block Holder, General	3-83
3.12.3     Block Holder, Addition	3-93
3.12.4     Block Holder, Modification	3-94
3.12.5     Block Holder, Deletion	3-96
3.12.6     Block Holder, Query	3-98
3.12.7     Block Holder, Default Routing Restoration	3-98
3.12.8     Block Holder, Re-Send	3-99
3.12.9     Block Holder, Bulk Data Downloads	3-101
3.13     Linked Action Replies	3-101
3.14     GTT Validation Processing by the NPAC SMS	3-105
3.14.1     Sub System Number (SSN) Edit Flag Indicator	3-105
3.14.2     Global GTT Validations	3-108
4.     SERVICE PROVIDER DATA ADMINISTRATION	4-1
4.1     Service Provider Data Administration and Management	4-1
4.1.1     User Functionality	4-1
4.1.2     System Functionality	4-2

Release 3.3: © 1997 — 2006 NeuStar, Inc.	iv	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

4.1.2.1     Service Provider Data Creation	4-2
4.1.2.2     Service Provider Data Modification	4-5
4.1.2.3     Delete Service Provider Data	4-6
4.1.3     Service Provider Queries	4-7
4.1.3.1     User Functionality	4-7
4.1.3.2     System Functionality	4-7
4.1.3.2.1     Service Provider Query	4-8
4.2     Additional Requirements	4-8
5.     SUBSCRIPTION MANAGEMENT	5-1
5.1     Subscription Version Management	5-1
5.1.1     Subscription Version Management	5-2
5.1.1.1     Version Status	5-2
5.1.2     Subscription Administration Requirements	5-11
5.1.2.1     User Functionality	5-11
5.1.2.2     System Functionality	5-12
5.1.2.2.1     Subscription Version Creation	5-12
5.1.2.2.1.1     Subscription Version Creation — Inter-Service Provider Ports	5-12
5.1.2.2.1.2     Subscription Version Creation — Intra-Service Provider Port	5-20
5.1.2.2.2     Subscription Version Modification	5-25
5.1.2.2.2.1     Modification of a Pending or Conflict Subscription Version	5-25
5.1.2.2.2.2     Modification of an Active/Disconnect Pending Subscription Version	5-28
5.1.2.2.3     Subscription Version Conflict	5-33
5.1.2.2.3.1     Placing a Subscription Version in Conflict	5-33
5.1.2.2.3.2     Removing a Subscription Version from Conflict	5-35
5.1.2.2.4     Subscription Version Activation	5-37
5.1.2.2.5     Subscription Version Disconnect	5-41
5.1.2.2.6     Subscription Version Cancellation	5-47
5.1.2.2.6.1     Un-do a “Cancel-Pending” Subscription	5-52
5.1.2.2.7     Subscription Version Resend	5-53
5.1.3     Subscription Queries	5-57
5.1.3.1     User Functionality	5-57
5.1.3.2     System Functionality	5-57
5.1.4     Subscription Version Processing for National Number Pooling	5-63
5.1.4.1     Subscription Version, General	5-64
5.1.4.2     Subscription Version, Addition for Number Pooling	5-65
5.1.4.3     Subscription Version, Block Create Validation of Subscription Versions	5-66
5.1.4.4     Subscription Version, Modification for Number Pooling	5-68
5.1.4.5     Subscription Version, Deletion for Number Pooling	5-68
5.1.4.6     Subscription Version, Block Delete Validation of Subscription Versions	5-69
6.     NPAC SMS INTERFACES	6-1
6.1     SOA to NPAC SMS Interface	6-1
6.2     NPAC SMS to Local SMS Interface	6-1
6.3     Interface Transactions	6-1
6.4     Interface and Protocol Requirements	6-1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	v	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

6.4.1     Protocol Requirements	6-2
6.4.2     Interface Performance Requirements	6-2
6.4.3     Interface Specification Requirements	6-4
6.4.4     Request Restraints	6-4
6.4.5     Application Level Errors	6-5
6.5     NPAC SOA Low-tech Interface	6-7
6.6     CMIP Request Retry Requirements	6-9
6.7     Recovery –	6-10
6.7.1     Notification Recovery	6-12
6.7.2     Network Data Recovery	6-15
6.7.3     Subscription Data Recovery	6-18
6.7.4     Service Provider Recovery	6-24
6.8     Out-Bound Flow Control	6-25
6.9     Roll-Up Activity and Abort Behavior	6-26
6.10     NPAC Monitoring of SOA and LSMS Associations	6-27
6.11     Separate SOA Channel for Notifications	6-29
6.12     Maintenance Window Timer Behavior	6-30
7.     SECURITY	7-1
7.1     Overview	7-1
7.2     Identification	7-1
7.3     Authentication	7-3
7.3.1     Password Requirements	7-3
7.4     Access Control	7-5
7.4.1     System Access	7-5
7.4.2     Resource Access	7-8
7.5     Data and System Integrity	7-9
7.6     Audit	7-11
7.6.1     Audit Log Generation	7-11
7.6.2     Reporting and Intrusion Detection	7-12
7.7     Continuity of Service	7-14
7.8     Software Vendor	7-15
7.9     OSI Security Environment	7-15
7.9.1     Threats	7-15
7.9.2     Security Services	7-15
7.9.3     Security Mechanisms	7-16

Release 3.3: © 1997 — 2006 NeuStar, Inc.	vi	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

7.9.3.1     Encryption	7-16
7.9.3.2     Authentication	7-17
7.9.3.3     Data Origin Authentication	7-17
7.9.3.4     Integrity and Non-repudiation	7-18
7.9.3.5     Access Control	7-18
7.9.3.6     Audit Trail	7-19
7.9.3.7     Key Exchange	7-19
8.     AUDIT ADMINISTRATION	8-1
8.1     Overview	8-1
8.2     Service Provider User Functionality	8-1
8.3     NPAC User Functionality	8-2
8.4     System Functionality	8-3
8.5     Audit Report Management	8-5
8.6     Additional Requirements	8-6
8.7     Database Integrity Sampling	8-6
8.8     Audit Processing in a Number Pool Environment	8-7
9.     REPORTS	9-1
9.1     Overview	9-1
9.2     User Functionality	9-1
9.3     System Functionality	9-3
9.3.1     National Number Pooling Reports	9-4
9.3.2     Cause Code Reports	9-6
9.3.3     Resend Excluded Service Provider Report	9-7
10.     PERFORMANCE AND RELIABILITY	10-11
10.1     Availability and Reliability	10-11
10.2     Capacity and Performance	10-14
10.3     Requirements in RFP Not Given a Unique ID	10-14
11.     BILLING	11-1
11.1     User Functionality	11-1
11.2     System Functionality	11-1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	vii	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Table of Contents

Appendix A. BUSINESS PROCESS FLOWS	A-1
Appendix B. GLOSSARY	B-1
Appendix C. SYSTEM TUNABLES	C-1
Appendix D. ENCRYPTION KEY EXCHANGE	D-1
Appendix E. DOWNLOAD FILE EXAMPLES	E-1
Appendix F. Midwest Region Number Pooling (deleted)	F-1
Appendix G. Deleted Requirements	G-1
Appendix H. Release Migration	H-1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	viii	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

List of Figures

List of Figures

Figure 3-1 — Entity Relationship Model
Figure 3-2 — Number Pool Block Version Status Interaction Diagram	3-81
Figure 5-1 — Subscription Version Status Interaction Diagram	5-2
Figure A- 1 — NPAC Business Process Flows Legend	A-1
Figure A- 2 — NPAC SMS Provision Service Process	A-1
Figure A- 3 — Flow 2.1.2 NPAC SMS Subscription Version Creation Process	A-1
Figure A- 4 — Flow 2.1.4 NPAC SMS Activate and Data Download Process	A-1
Figure A- 5 — Flow 2.2 NPAC SMS Disconnect Process	A-1
Figure A- 6 — Flow 2.3 NPAC SMS Repair Process	A-2
Figure A- 7 — Flow 2.4.1 Conflict Process	A-2
Figure A- 8 — Flow 2.5 NPAC SMS Disaster Recovery Process	A-2
Figure A- 9 — Flow 2.6 Cancellation Process	A-2
Figure A- 10 — Flow 2.7 Audit Process	A-2
Figure A- 11 — Flow 2.8 Report Process	A-2
Figure E- 1 — Subscription Download File Example	E-2
Figure E- 2 — Network Service Provider Download File Example, SP Supports SP Type	E-4
Figure E- 2a — Network Service Provider Download File Example, SP Does Not Support SP Type	E-4
Figure E- 5 — Network NPA-NXX-X Download File Example	E-9
Figure E- 6 — Block Download File Example	E-10

Release 3.3: © 1997 — 2006 NeuStar, Inc.	ix	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

List of Tables

List of Tables

Table 0-1 Notation Key	0-6
Table 0-2 Language Key	0-6
Table 1-1 Business Day/Hour Behavior	1-5
Table 1-2 Timer Type Behaviour	1-6
Table 1-3 Vacant Number Treatment/Snapback Notification	1-12
Table 3-1 Data Type Legend	3-2
Table 3-2 NPAC Customer Data Model	3-9
Table 3-3 NPAC Customer Contact Data Model	3-10
Table 3-4 NPAC Customer Network Address Data Model	3-10
Table 3-5 NPAC Customer Associated Service Provider Data Model	3-11
Table 3-6 Subscription Version Data Model	3-15
Table 3-7 Subscription Version Failed SP List Data Model	3-16
Table 3-8 Number Pooling Block Holder Information Data Model	3-18
Table 3-9 Number Pooling Block Failed SP List Data Model	3-19
Table 3-10 Portable NPA-NXX Data Model	3-19
Table 3-11 LRN Data Model	3-20
Table 3-12 LSMS Filtered NPA-NXX Data Model	3-20
Table 3-13 Number Pooling NPA-NXX-X Holder Information Data Model	3-21
Table 3-14 Number Pool Block Version Status Interaction Descriptions	3-83
Table 5-1 Subscription Version Status Interaction Descriptions	5-8
Table 6-1 Interface Protocol Stack	6-2
Requirement Table 3-1, RR3-137.2 — Block Creation	3-87
Requirement Table 3-2, RR3-137.3 — Block Modification	3-88
Requirement Table 3-3, RR3-137.4 — Block Deletion	3-89
Requirement Table 3-4, RR3-138.2 – Failed SP List	3-91
Table C- 1 — Subscription Tunables	C-6
Table C- 2 — Communications Tunables	C-12
Table C- 3 — Audit Tunables	C-12
Table C- 4 — Logs Tunables	C-13
Table C- 5 — Keys Tunables	C-13
Table C- 6 — Block Tunables	C-14

Release 3.3: © 1997 — 2006 NeuStar, Inc.	xi	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

List of Tables

Table D- 1 — Encryption Key Exchange File Format	D-2
Table D- 2 — Encryption Key Acknowledgement File Format	D-3
Table E- 1 — Explanation of the Fields in The Subscription Download File	E-3
Table E- 2 — Explanation of the Fields in the Network Service Provider Download File	E-4
Table E- 3 — Explanation of the Fields in the Network NPA/NXX Download File	E-6
Table E- 4 — Explanation of the Fields in the Network LRN Download File	E-8
Table E- 5 — Explanation of the Fields in the Network NPA-NXX-X Download File	E-9
Table E- 6 — Explanation of the Fields in The Block Download File	E-11

Release 3.3: © 1997 — 2006 NeuStar, Inc.	xii	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	0-0	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Preface

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.
Appendix D	Encryption Key Exchange – This section provides information on exchange of keys between Service Providers and the NPAC SMS.
Appendix E	Download File Examples – This section provides descriptions of the NPAC SMS data download files.
Appendix F	Midwest Region Number Pooling – This section is deleted in release 3.0.0.
Appendix G	Deleted Requirements – This section provides a list of requirements that have been deleted from the FRS.
Appendix H	Release Migration – This section provides requirements for the data migration of the NPAC SMS from Release 2.0 to 3.0.

0.2 Document Numbering Strategy

Starting with Release 2.0 the documentation number of the FRS document will be Version X.Y.Z as follows:

X – will only be incremented when a new major release of the NPAC SMS system is authorized. It will contain only the Change Orders that have been authorized for inclusion in this new major release.

Y – Will only be incremented when a new sub-release of an existing release X is authorized. It will contain only the Change Orders that have been authorized for inclusion in this new sub-release.

Z – will be incremented when documentation only clarifications and/or backward compatibility issues or other deficiency corrections are made in the FRS and/or IIS. This number will be reset to 0 when Y is incremented.

For example, the first release of the Release 2 FRS will be numbered 2.0.0. If documentation only clarifications are introduced in the next release of the FRS document it will be numbered 2.0.1. If requirements are added to Release 2.0 that require NPAC SMS software changes then the next release of the FRS document will be numbered 2.1.0.

This number scheme is intended to make the mapping between NPAC SMS and the FRS and IIS documentation consistent.

Starting with Release 3.2, the documentation number of the FRS document will include a “lowercase letter” following the Z designation. This “lowercase letter” will essentially serve as a version indicator for the release of the documentation, such that the X.Y.Za will be a unique identifier. It will be used for both drafts and final versions.

Release 3.3: © 1997 — 2006 NeuStar, Inc.		0-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.				March 9, 2006

Preface

For example, the first release using this new convention will be 3.2.0a, followed by 3.2.0b, and so on. The “lower case letter” shall be reset to ‘a’ when Z is incremented.

0.3 Document Version History

0.3.1 Release 1.0

NANC Version 1.0, released on 04/07/97, contains changes from the ICC Subcommittee FRS Version 1.1.5.

NANC Version 1.1, released on 05/08/97, contains changes from the NANC FRS Version 1.0.

NANC Version 1.2, released on 05/25/97, contains changes from the NANC FRS Version 1.1.

NANC Version 1.3, released on 07/09/97, contains changes from the NANC FRS Version 1.2.

NANC Version 1.4, released on 08/08/97, contains changes from the NANC FRS Version 1.3.

NANC Version 1.5, released on 09/09/97, contains changes from the NANC FRS Version 1.4.

NANC Version 1.6, released on 11/12/97, contains changes from the NANC FRS Version 1.5.

NANC Version 1.7, released on 12/12/97, contains changes from the NANC FRS Version 1.6.

NANC Version 1.8, released on 2/11/98, contains changes from the NANC FRS Version 1.7.

NANC Version 1.9, released on 5/13/98, contains changes from the NANC FRS Version 1.8.

NANC Version 1.10, released on 7/8/98, contains changes from the NANC FRS Version 1.9.

0.3.2 Release 2.0

NANC Version 2.0.0, released on 12/1/98, contains changes from the NANC FRS Version 1.10.

NANC Version 2.0.1, released on 5/1/99, contains changes from the NANC FRS Version 2.0.0.

NANC Version 2.0.2, released on 9/1/99, contains changes from the NANC FRS Version 2.0.1.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	0-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Preface

0.3.3 Release 3.0

NANC Version 3.0.0, released on 1/5/00 and 2/4/00 (revised version), contains changes from the NANC FRS Version 2.0.2.

NANC Version 3.0.1, released on 6/6/00, contains changes from the NANC FRS Version 3.0.0

NANC Version 3.0.2, released on 3/1/01, contains changes from the NANC FRS Version 3.0.1

NANC Version 3.0.3, released on 3/19/01, contains changes from the NANC FRS Version 3.0.2

0.3.4 Release 3.1`

NANC Version 3.1, released on 8/6/01, contains changes from the NANC FRS Version 3.0.3.

0.3.5 Release 3.2

NANC Version 3.2.0, released on 7/19/02, contains changes from the NANC FRS Version 3.1.0.

NANC Version 3.2.1a, released on 6/27/03 contains changes from the NANC FRS Version 3.2.0.

NANC Version 3.2.2a, released on 6/30/04 contains the changes from the NANC FRS Version 3.2.1a

0.3.6 Release 3.3

NANC Version 3.3.0a, released on 3/28/05, contains changes from the NANC Version 3.2.2a

NANC Version 3.3.0b, released on 4/22/05 contains changes from the NANC FRS Version 3.3.0a

NANC Version 3.3.0c, released on 5/12/05 contains changes from the NANC FRS Version 3.3.0b

NANC Version 3.3.0d, released on 6/22/05 contains changes from the NANC FRS Version 3.3.0c

NANC Version 3.3.0e, released on 8/2/05 contains changes from the NANC FRS Version 3.3.0d

NANC Version 3.3.1a, released on 10/14/2005 contains changes from the NANC FRS Version 3.3.0e

NANC version 3.3.1b, released on 3/7/2006 contains the following changes from the NANC FRS Version 3.3.1a:

Release 3.3: © 1997 — 2006 NeuStar, Inc.	0-3	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Preface

o Documentation only changes contained in Change Order NANC 407 NPAC Range Operations and Associated Notifications

o Documentation only changes contained in Change Order NANC 409 Doc-Only Change Order: FRS Updates

NOTE: With Release 3.3 of the NPAC SMS, new functionality related to SV Type and Optional Data for a subscription version or number pool block, is implemented but is currently inactive in all NPAC Regions. To implement these features new requirements were drafted and existing requirements were impacted. Both new and existing requirements for these features reference change order, “NANC 399”. Until NAPM LLC approval, this functionality will remain inactive in the NPAC SMS system.

0.4 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 (NeuStar, Inc. as of December 1999) response to the RFP and requirements definition activities performed with the Illinois Number Portability SMS Subcommittee.

Illinois number of requirements has been adopted for the initial release of the NANC document. In Illinois as requirements were deleted the requirement number and an indication of its deletion were left in the document for tracking purposes. NANC has chosen to leave these deleted requirements in this document for the initial release of the document. Further explanation of the numbering scheme follows.

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 “X”, the item is a requirement, assumption or a constraint that was added upon award, and not in the RFP. 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 award. 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:

Release 3.3: © 1997 — 2006 NeuStar, Inc.	0-4	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Preface

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 added upon award.
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 added upon award.
CR-<nnn>	This is a constraint that was identified as a new constraint for the system, during post-award meetings with the Illinois LCC.
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.
RR-<nnn>	This is a requirement that was identified in a NPAC SMS release subsequent to 1.X.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	0-5	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Preface

RX-<nnn>	This is a requirement that was added upon award.
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 Notation Key

0.5 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,	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.
should	Statements following the words “is,” “will,” or “should” are not a mandatory deliverable for the final system.

Table 0-2 Language Key

Release 3.3: © 1997 — 2006 NeuStar, Inc.	0-6	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

1. Introduction

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

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 can receive 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.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 can 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 that may be sent from the old Service Provider. Assuming the notifications are valid, the two Service Providers will complete any physical changes required. When the new Service Provider due date is reached, the new Service Provider can 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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

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 allow the new Service Provider to proceed with activation when the new Service Provider due date is reached. If it was the new Service Provider that failed to respond, the NPAC will log the failure to respond, cancel the request, 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 the disconnect to the NPAC SMS. If the Service Provider needs to change the Customer Disconnect Date (CDD) or Effective Release Date (ERD) of the disconnect, the Service Provider will send a modify request 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 of the conflict status and the Status Change Cause Code. 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 by one of the two Service Providers. The new Service Provider can cancel the Subscription Version.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

1.2.6 Order Cancellation Functionality

If a Create Subscription has been sent by only the new Service Provider, the new Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If a Create Subscription has been sent by only the old Service Provider, the old Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If both Service Providers have sent a Create Subscription, either may send a message to the NPAC SMS to cancel the Subscription Version. If both Service Providers concur 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. If cancellation concurrence is not provided by the new Service Provider the Subscription Version is placed in conflict by the NPAC SMS. If cancellation concurrence is not provided by the old Service Provider, the Subscription Version is set to cancel by the NPAC SMS.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-3	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

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.2.10 NPA-NXX Split Processing

NPA Splits are initiated on the NPAC through regular processing of an industry source that contain industry standard data. Based on information from these files, the NPAC SMS will automatically perform all the data processing necessary (Creating/Deleting NPA-NXXs, updating Subscription Versions appropriately) to ensure reliable representation of ported telephone number data used in call processing leading up to, during and after an NPA Split has occurred.

In the case of emergency updates to NPA Split information, certain NPAC Operations personnel have the ability to manually enter all required NPA Split information into the NPAC Administrative Interface so as to ensure successful NPA Split processing within the NPAC SMS.

For an impending NPA split, there is no communication between each SOA and the NPAC via an electronic interface (SOA, LSMS, or NPAC Administrative Interface) other than providing the NPAC with the new network data (LRNs), if applicable. The NPAC will update its subscription version records when permissive dialing starts to the new NPA. During the permissive dialing period the NPAC will accept messages with either old or new NPA but broadcasts/downloads with the new NPA only. In addition, all notifications and responses to the SOA system will contain the new NPA only during the permissive dialing period regardless of whether the SOA system is using the old or new NPA in its requests to the NPAC SMS. If a delete request is received, it is broadcast with the new NPA. The subscription version ID that the NPAC SMS is aware of for the TN is used in the messages.

Based on information from the industry source, the service providers will update their networks/LSMS to accommodate the permissive dialing period and will update the data in their networks/LSMS after permissive dialing ends. There is no communication from the NPAC to cause these updates to occur. No assumptions are made about what the LSMS does during the permissive period to track the NPA-NXX split for a subscription version.

After permissive dialing ends, the NPAC removes any old NPA-NXXs and/or NPA-NXX-Xs related to the NPA Split that are no longer valid, and broadcasts these network data deletes to the appropriate SOAs/LSMSs. Additionally, the service providers can remove any old LRNs that are no longer valid due to the split, if any, via an electronic interface (SOA, LSMS, or NPAC Administrative Interface).

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-4	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

1.2.11 Business Days/Hours

For support of service providers that have different needs for business hours and days available for porting, two types of business days/hours have been defined in the NPAC SMS. The two types are long and short business days/hours.

The following table illustrates the outcome of business hours/days to be used based on the possible combinations:

OLD Service Provider
New	Business	Short	Long
Service	Type
Provider
	Short	When both the old and new service providers support short business days/hours for a subscription version port short business days/hours will be used.	When the new service provider supports short business days/hours and the old service providers supports long business days/hours for a subscription version port short business days/hours will be used.
		No action is necessary by either the old or new service provider operations personnel.	The old service provider who supports the long business days/hours will have to recognize that the short business days/hours are being used instead of the expected long business days/hours.
	Long	When the new service provider supports long business days/hours and the old service providers supports short business days/hours for a subscription version port short business days/hours will be used.	When both the old and new service providers support long timers for a subscription version port long timers will be used.
			No action is necessary by either the old or new service provider operations personnel.
		The new service provider who supports the long business days/hours will have to recognize that the short timers are being used instead of the expected long timers.

Table 1-1 Business Day/Hour Behavior

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-5	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

1.2.12 Timer Types

For support of service providers that have different needs for timers available for porting, two types of timers have been defined in the NPAC SMS. The two types are long and short timers.

The following table illustrates the outcome of timers to be used based on the possible combinations:

	OLD Service Provider
New	Timer Type	Port Out-  Short	Port Out-  Long
Service
Provider
	Port In – Short	When both the old and new service providers support short timers for a subscription version port short timers will be used.	When the new service provider supports short timers and the old service providers supports long timers for a subscription version port long timers will be used.
		No action is necessary by either the old or new service provider operations personnel.	The new service provider who supports the short timers will have to recognize that the long timers are being used instead of the expected short timers.
	Port In – Long	When the new service provider supports long timers and the old service providers supports short timers for a subscription version port long timers will be used.	When both the old and new service providers support long timers for a subscription version port long timers will be used.
		The old service provider who supports the short timers will have to recognize that the long timers are being used instead of the expected short timers.	No action is necessary by either the old or new service provider operations personnel.

Table 1-2 Timer Type Behaviour

1.2.13 Recovery Functionality

The NPAC SMS provides a mechanism that allows a Service Provider to recover messages sent to either the SOA or LSMS, during a period of time that the Service Provider was not available to receive messages from the NPAC SMS. This recovery mechanism (also referred to as resynchronization) is initiated when a Service Provider’s SOA or LSMS re-associates to the NPAC SMS, by setting the recovery mode indicator to TRUE on the Access Control structure, then requests the recovery of missed messages, by requesting the missed Network Data, Subscription Versions and/or Notifications.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-6	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

The SOA requests network data and notification data for a specific period of time from the NPAC SMS, which is sent by the NPAC SMS as requested. The NPAC SMS will send the recovery data requested based on the Service Provider’s Linked Replies Indicator setting (separate indicators for SOA and LSMS). If the Linked Replies Indicator is set to TRUE the NPAC SMS will send the updates in smaller, linked messages (e.g., groups of 50 at a time). If the Linked Replies Indicator is set to FALSE the NPAC SMS will send the updates in a single larger, non-linked message. In the case of linked replies, data is sent in multiple linked M-ACTION replies, followed by an “empty” non-linked normal response (indicating the end of the linked reply data). During the recovery process, new messages are queued on the NPAC SMS. Additionally, during the recovery process, the “x by y” retry functionality (where “x” is the number of attempts, and “y” is the interval in number of minutes in between attempts) continues on the NPAC SMS, but message sending is suspended to the SOA, and the retry attempts counter is not decremented, as long as the SOA is still in recovery mode. Once the recovery is finished, the SOA sends a recovery complete message to the NPAC SMS, which in turn triggers the NPAC SMS to send the previously queued messages to the SOA, at the next normally scheduled retry interval. At the completion of sending the previously queued messages, the interaction between the SOA and the NPAC SMS resumes for normal message processing.

The LSMS recovery functionality works similar to the SOA, with the addition of recovering subscription data.

Service Provider systems may implement an optional recovery method called, “Send What I Missed” (SWIM). This implementation uses the existing recovery messages, and incorporates a new attribute (SWIM, rather than a time range). When the NPAC SMS receives a SWIM recovery request it issues a SWIM recovery response that contains only the messages that were previously missed by the requesting Service Provider system. Linked Reply functionality is utilized in the SWIM responses, so a Service Provider system must support that feature as well. SWIM improves the efficiency of recovery processing for the NPAC SMS and Service Providers because guesswork of determining a recovery timeframe that includes the actual messages that were missed is eliminated.

1.2.13.1 Network Data Recovery

Network Data Recovery in the NPAC SMS allows a Service Provider for both SOA and LSMS to capture, via a recovery process, all network data downloads that were missed during a downtime period for the Service Provider. The processing steps for this functionality include:

1.	The Service Provider system sends a network data recovery request to the NPAC.
2.	The NPAC takes the time range in the requested criteria, and compares the number to the current tunable value.
3.	If the time range exceeds the tunable value, a DownloadReply is returned to the SP system with the status field populated with value 2, signifying “time-range-invalid”. No network data will be included with this reply.
4.	When an SP system sees this response, the suggested behavior is to reduce the time range requested in the network data recovery action and re-issue the request.

NOTE: Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system or a record-based recovery request to recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.

1.2.13.2 Subscription Data Recovery

Subscription Data Recovery in the NPAC SMS allows a Service Provider’s LSMS to capture, via a recovery process, all subscription data downloads that were missed during a downtime period for the Service Provider. The processing steps for this functionality include:

1.	The Service Provider system sends a subscription data recovery request to the NPAC.
2.	The NPAC takes the time range in the requested criteria, and compares the number to the current tunable value.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-7	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

3.	If the time range exceeds the tunable value, a DownloadReply is returned to the SP system with the status field populated with value 2, signifying “time-range-invalid”. No subscription data will be included with this reply.
4.	When an SP system sees this response, the suggested behavior is to reduce the time range requested in the subscription data recovery action and re-issue the request.

NOTE: Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system or a record-based recovery request to recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.

1.2.13.3 Notification Recovery

Notification Recovery in the NPAC SMS allows a Service Provider for both SOA and LSMS to capture, via a recovery process, all notifications that were missed during a downtime period for the Service Provider. The processing steps for this functionality include:

1.	The Service Provider system sends a notification recovery request to the NPAC.
2.	The NPAC retrieves the records that match the requested criteria, and compares the number to the current tunable value.
3.	If the number of records exceeds the tunable value, a NetworkNotificationRecoveryReply is returned to the SP system with the status field populated with value 3, signifying “criteria-too-large”. No notifications will be included with this reply.
4.	When an SP system sees this response, the suggested behavior is to reduce the time range requested in the notification recovery action and re-issue the request.

NOTE: Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system. This type of recovery request does not require a time range.

1.2.13.4 Service Provider Data Recovery

Service Provider Data Recovery in the NPAC SMS allows a Service Provider for both SOA and LSMS to capture, via a recovery process, all Service Provider data updates that were missed during a downtime period. The processing steps for this functionality include:

1.	The Service Provider system sends a service provider data recovery request to the NPAC.
2.	The NPAC takes the time range in the request criteria, and compares the number to the current tunable value.
3.	If the time range exceeds the tunable value, a DownloadReply is returned to the SP system with the status field populated with value 2, signifying “time-range-invalid”. No service provider data will be included with this reply.
4.	When an SP system sees this response, the suggested behavior is to reduce the time range requested in the service provider data recovery action and re-issue the request.

NOTE: Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system or a record-based recovery request to recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-8	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

1.2.14 Number Pooling Overview

At the present time, the National Number Pooling approach includes the following:

1.	Pre-Port 1K Blocks to a single switch (i.e., all Pooled TNs contain same LRN).
2.	EDR (Efficient Data Representation) is captured through the use of “1K Blocks” in the NPAC, and over the SOA-to-NPAC and NPAC-to-LSMS interfaces.
3.	The NPA-NXX-X Holder Information in the NPAC is a representation of the 1K Block managed by the Pooling Administrator, and represented in the LERG Routing Guide.
4.	The NPAC Customer SOA NPA-NXX-X Indicator in the NPAC Customer Data Model will be added to indicate whether or not the Service Provider accepts NPA-NXX-X downloads from the NPAC (TRUE = yes, FALSE = no) to their SOA via the SOA-to-NPAC SMS Interface.
5.	The NPAC Customer LSMS NPA-NXX-X Indicator in the NPAC Customer Data Model will be added to indicate whether or not the Service Provider accepts NPA-NXX-X downloads from the NPAC (TRUE = yes, FALSE = no) to their LSMS via the NPAC SMS-to-Local SMS Interface.
6.	The NPAC Customer Data Model (logical) and Service Provider Profile (physical) refer to the same information.
7.	The NPA-NXX-X Holder Information is broadcast over the SOA-to-NPAC SMS Interface to all Service Providers in that NPAC region (exclusive of those that have filters for that NPA-NXX, and those who have a SOA NPA-NXX-X indicator in the Customer Data Model set to FALSE), for the block allocation of NPA-NXX-X data to the NPA-NXX-X Holder.
8.	The NPA-NXX-X Holder Information is broadcast over the NPAC SMS-to-Local SMS Interface to all Service Providers in that NPAC region (exclusive of those that have filters for the NPA-NXX, and those who have an LSMS NPA-NXX-X indicator in the Customer Data Model set to FALSE), for the block allocation of NPA-NXX-X data to the NPA-NXX-X Holder.
9.	The NPA-NXX-X Holder Information’s “Effective Date” is the date the LERG Routing Guide, the Pooling Administrator, and the NPAC, consider to be the “ownership switchover” date for the 1K Block from the Code Holder (NPA-NXX owning SP) to the Block Holder (NPA-NXX-X owning SP).
10.	At the time of NPA-NXX-X creation, the NPAC will check for “pending-like, no-active” SVs or “pending-like Port-To-Original” SVs. If any are found, the NPAC will reject the creation of this NPA-NXX-X. An error message will be generated for the NPAC personnel. Additionally, the NPAC Personnel will be able to view the discrepant TNs (on the screen in the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version REPORT format), then be able to select multiple output destinations for the report, or exit the NPA-NXX-X Creation and continue with other GUI activities.
11.	The Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report will be available to NPAC personnel. The report will contain TN, Old SPID, New SPID, Due Date, and Status.
12.	The recipients of the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report (e.g., Pooling Administrator, Code Holder) will have their own M&P (outside of NPAC) to clean up these SVs (either cancel or activate). Once they are cleaned up, NPAC personnel will attempt the NPA-NXX-X creation again.
13.	Once the NPA-NXX-X has been created on the NPAC, the Code Holder is prohibited from performing intra-service provider ports. If TNs were missed during the Code Holder’s pre-donation intra-port activities, then NPAC personnel only are allowed to perform these intra-service provider port creates of SVs with no previously active SV, on behalf of the Code Holder. The NPAC will allow NPAC personnel, via the OpGUI, to create these LISP ports up to the effective date (11:59p of the day prior to the effective date), and to activate these LISP ports up to the Block’s activation date/time. The Code Holder can also assist in the activation of the LISP ports up to the Block’s activation date/time.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-9	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

14.	Once the NPA-NXX-X’s Effective Date has been reached, but prior to the Block’s activation, snapback messages will go to the Block Holder, and default routing will be the responsibility of the Code Holder. The exception to this is during the de-pool process for the NPA-NXX-X (see #31 below).
15.	Once the Block has been created (the record exists in the NPAC SMS and the Creation Timestamp in the Object has been set) in the NPAC, either from a scheduled event on the NPAC, or from a Service Provider SOA sending up the Block, then NPAC processing considers the Block to be “activated” for the Block Holder, and all snapback messages and default routing will go to the Block Holder.
16.	The Block Holder Information is broadcast over the NPAC-to-LSMS interface, when the SP’s LSMS EDR flag in the Customer Profile record in the NPAC, is set to TRUE (non-EDR LSMSs get individual SVs, since the SP’s LSMS EDR flag is set to FALSE).
17.	The Block Holder Information’s “Activation Timestamp” is the date/time the NPAC broadcasts block or SV data to the applicable LSMSs. Only at this point in time are all SPs notified of the “ownership switchover” date for the 1K Block from the Code Holder (NPA-NXX owning SP) to the Block Holder (NPA-NXX-X owning SP).
18.	Block Create messages over the SOA-to-NPAC SMS Interface will set the SOA Origination to TRUE.
19.	The Block Holder Information’s SOA notification is broadcast over the SOA to NPAC Interface, when the SOA Origination on the Block record is set to TRUE.
20.	At the time of Block creation by the NPAC (attempted on or after the NPA-NXX-X’s Effective Date), the NPAC will check for “pending-like, no-active” SVs. If any are found, the NPAC will reject the creation of this Block. A unique alarmable error message (new error message and error number for Block) will be generated and alarm NPAC personnel.
21.	At the time of Block creation by the SP’s SOA (attempted on or after the NPA-NXX-X’s Effective Date), the NPAC will check for “pending-like, no-active” SVs. If any are found, the NPAC will reject the creation of this Block. A unique alarmable error message (new error message and error number for Block, but no alarm to NPAC Personnel) will be generated and sent back to the SP’s SOA. A new M&P will require the SP to contact NPAC personnel (USA) and request the generation of the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report.
22.	The Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report will be created and will contain TN, Old SPID, New SPID, Due Date, and Status.
23.	The recipients of the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report (e.g., Pooling Administrator, Code Holder) will have their own M&P (outside of NPAC) to clean up these SVs (either cancel or activate) by the Code Holder and the NPAC Personnel. Once they are cleaned up, NPAC personnel will attempt the Block creation again (if it is NPAC initiated), or contact the Block Holder SP and inform them that they could re-submit the Block request.
24.	If during the broadcast of the Pooled Data (Blocks and SVs), one or more Service Providers cause the Block to go into a Partial Failure or Failed status, the NPAC will generate a unique alarmable message, and NPAC Personnel will be notified of the error, only when the SOA Origination is FALSE (if value is TRUE, existing M&Ps for partial failure or failed conditions will be used). M&P will be established to have NPAC Personnel resolve the broadcast failures with the Service Providers on the Block’s Failed SP List.
25.	The NPAC will execute a background process, once a day, to check for Block completeness. During this background process, the NPAC will check for active blocks that haven’t been verified to contain 1000 SVs (combination of POOL, LISP, LSPP) for that Block.. This is designed to capture any “disconnect requests that were sending on it’s way to old”, which may result in an orphan TN that does NOT have an Active SV. This background process will be run for the first time within 24 hours of Block Creation (with an Active status), and once every 24 hours thereafter for incomplete Blocks. For missing TNs that are identified during this process, the NPAC will create, activate and broadcast the missing SVs to non-EDR Local SMSs (i.e., self-fixing create, activate and broadcast of missing SVs). Once all 1000 TNs have been accounted for in the NPAC, this Block will no longer be checked by the NPAC.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-10	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

26.	The NPAC will manage the synchronization of, and maintain the integrity of, the data between a Block and the subordinate Pooled Subscription Versions within the Block. This means that, at all times, the LRN and GTT routing data for the Block and all SVs with LNP Type of POOL within the 1K Block, will contain the same values. The status for the Block and status for each SV with LNP Type of POOL within the 1K Block, may not always contain the same value. The matrix to coordinate the status is found in the detailed requirements. The failed SP List for the Block and Failed SP List for each SV with LNP Type of POOL within the 1K Block, may not always contain the same Service Providers. The matrix to coordinate the various Failed SP Lists is found in the detailed requirements.
27.	Once a Block is “active”, the routing data can be modified. This may be performed by NPAC Personnel using the NPAC OpGUI, Service Provider Personnel using the NPAC Low-tech Interface, or Service Provider via the SOA-to-NPAC SMS Interface.
28.	At the time of NPA-NXX-X deletion (i.e., de-pool), the NPAC will check for “pending-like, with Active POOL” SVs, or “pending-like, port-to-original” SVs. If any are found, the NPAC will reject the Deletion of this NPA-NXX-X. An error message will be generated for the NPAC personnel. Additionally, the NPAC Personnel will be able to view the discrepant TNs (on the screen in the Pending-Like With Active POOL Subscription Version and Pending-Like Port-To-Original REPORT format), then be able to select multiple output destinations for the report, or exit the NPA-NXX-X Deletion and continue with other GUI activities.
29.	The Pending-Like With Active POOL Subscription Version and Pending-Like Port-to-Original Subscription Version report will be available to NPAC personnel. The report will contain TN, Old SPID, New SPID, Due Date, and Status.
30.	The recipients of the Pending-Like With Active POOL Subscription Version and Pending-Like Port-to-Original Subscription Version report (e.g., Pooling Administrator, Block Holder) will have their own M&P (outside of NPAC) to clean up these SVs (either cancel or activate). Once they are cleaned up, NPAC personnel will await notification from the Pooling Administrator prior to attempting the NPA-NXX-X deletion again.
31.	The NPAC performs a “cascading delete” when processing an NPA-NXX-X Deletion. This includes sending deletes of Pooled SV data to non-EDR LSMSs, and sending deletes of Block data to EDR LSMSs. Once all LSMSs have successfully deleted the Pooled data (the status of all SVs and the Block is Old, and both Failed SP Lists are empty), the NPA-NXX-X is deleted. Similar to the NPA-NXX-X Creation, the NPA-NXX-X Deletion is broadcast to the appropriate Service Providers, based on the values in their NPA-NXX-X Indicators.
32.	During the de-pooling process, the vacant number treatment responsibility and snapback for TN re-assignment notifications have unique behavior, once the Block has migrated to a status of Old. As defined in #14 above, snapback messages will go to the Block Holder, and default routing will be the responsibility of the Code Holder, once the NPA-NXX-X’s Effective Date has been reached. However, in this de-pooling situation, both snapback messages and default routing responsibility will be the Code Holder. So, even though the NPA-NXX-X still exists, it has the same behavior as the “pre-effective date” NPA-NXX-X situation.
33.	Once the Block has been deleted in the NPAC, then NPAC processing considers the Block to be “deleted” for the Block Holder, and all snapback messages and default routing will go to the Code Holder. Additionally, the Block is now available to be allocated to another Service Provider.
34.	For NPA Split processing, at the start of the Split, the NPAC SMS will automatically create a New NPA-NXX-X to correspond to the Old NPA-NXX-X, and will reject the NPA Split request if the New NPA-NXX-X already exists at the time of the NPA Split entry. The NPAC will remove the New NPA-NXX-X and convert the Block and SVs back to the Old NPA-NXX, if the New NPA-NXX is removed from the NPA Split, prior to the end of PDP. When adding an NPA-NXX-X during an NPA Split, the NPAC will automatically add a corresponding New/Old NPA-NXX-X for an NPA-NXX involved in a Split. During PDP, the NPAC will treat Block data similar to the treatment of SV data (i.e., either the Old or New NPA-NXX can be sent to the NPAC, but the NPAC will broadcast the New NPA-NXX).
35.	The NPAC Customer LSMS EDR Indicator in the NPAC Customer Data Model will be added to indicate whether or not the Service Provider uses Efficient Data Representation on the Local SMS (TRUE = yes, FALSE = no).

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-11	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

36.	The two new objects that will be broadcast over the interface include the NPA-NXX-X (1K Block) block allocation, and Block for EDR compatible Local SMSs that represent the 1000 TNs of POOL’ed numbers as the 1K Block.
37.	The basis for the National Number Pooling requirements was the Illinois Number Pooling NPAC Release 1.4. The Number Pooling Delta document, National Number Pooling requirements, represents the requirements for National Number Pooling functionality.

The following table portrays “vacant number treatment” responsibility and “snapback for TN re-assignment” notifications throughout each phase of number pooling, once the Block has been donated to the Pooling Administrator:

Vacant Number	Pre effective date	post effective date	post Block	during Block de-
Treatment			activation	pool
Contaminated	Code holder	Code holder	Block holder	Code holder
disconnect
Non-contaminated	Code holder	Code holder	Block holder	Code holder
Snapback for TN
re-assignment
Contaminated	Code holder*	Block holder	Block holder	Code holder*
disconnect
Non-contaminated	N/A	N/A	Block holder	N/A

Table 1-3 Vacant Number Treatment/Snapback Notification

* = Code Holder receives a notification but CANNOT reassign this TN.

Note: for the last column (during Block de-pool), the behavior is the same as the pre-effective date column. A block may still exist in the NPAC SMS with a status of Old. At the time of de-pooling, the Block goes back to the Pooling Administrator and is awaiting re-assignment to the next Block Holder. The NPA-NXX-X may also exist in the NPAC SMS until a Block is successfully deleted from all Local SMSs.

1.2.15 Time References in the NPAC SMS

Time references in the NPAC SMS can be confusing because multiple time zones are involved across the seven US regions, as well as the Canadian region. Additionally, the universal time zone (UTC/GMT) is also used. The descriptions below are designed to point out the various time references that are used throughout the system.

Universal Time Zone – As a general rule, the NPAC SMS application runs on the universal time zone. The following items use UTC/GMT:

1.	NPAC DB (all timestamp fields)
2.	CMIP interface messages (SOA and LSMS)
3.	NPAC timers (short and long)
4.	NPAC parameters

a.	Short Business Day Start Time
b.	Long Business Day Start Time

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-12	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

c. Conflict Restriction Window (18:00/17:00 GMT)

5.	NPA Split Permissive Dial Dates (the Time portion)
6.	NPAC reports
7.	NPAC BDD files

NPAC GUI – The NPAC GUI (both administrative GUI for USAs and LTI GUI for NPAC customers) is based on the setting for each specific user’s PC. Therefore, even though NPAC data is stored in UTC/GMT, it is converted and displayed for a user in their local time zone as defined in their PC setting.

The only exception to this rule is on the administrative GUI, for the following data. In both of these cases, the data is displayed in Central Time.

1.	NPA-NXX-X Effective Date
2.	Number Pool Block Scheduled Activation Date

Business Hours/Days – The definition of Business Hours/Days in the NPAC SMS are defined using a combination of three variables. Wireline Service Providers typically use SHORT variables, and Wireless Service Providers typically use LONG variables.

Wireline	Short Business Days	Monday – Friday (five days)
	Short Business Day Start Time	13:00/12:00 GMT
	Short Business Day Duration	12 hours
Wireless	Long Business Days	Sunday – Saturday (seven days)
	Long Business Day Start Time	14:00/13:00 GMT (for eastern regions)
		15:00/14:00 GMT (for central regions)
		15:00/14:00 GMT (for Canadian region)
		16:00/15:00 GMT (for mountain region)
		17:00/16:00 GMT (for pacific region)
	Long Business Day Duration	12 hours

Using this information, the region equivalents are defined by the table below:

Region	SPs using Short Hours/Days	SPs using Long Hours/Days
NE	Monday – Friday, 8a-8p ET	Sunday – Saturday, 9a-9p ET
MA	Monday – Friday, 8a-8p ET	Sunday – Saturday, 9a-9p ET
SE	Monday – Friday, 8a-8p ET	Sunday – Saturday, 9a-9p ET
MW	Monday – Friday, 7a-7p CT	Sunday – Saturday, 9a-9p CT
SW	Monday – Friday, 7a-7p CT	Sunday – Saturday, 9a-9p CT
WE	Monday – Friday, 6a-6p MT	Sunday – Saturday, 9a-9p MT
WC	Monday – Friday, 5a-5p PT	Sunday – Saturday, 9a-9p PT
CA	Monday — Friday, 7a-7p CT	Sunday — Saturday, 9a-9p CT

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-13	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

Concurrence Windows/Timers – Various porting activities initiated by one Service Provider require some type of concurrence from a second Service Provider. This concurrence is defined as performing some activity within x number of business hours. At the time an activity occurs in the NPAC that requires the use of a window/timer, the future expiration time is calculated and stored, based on the NPAC settings in the table above, at the time of the activity. These windows/timers will then expire based on the pre-calculated date/time.

Standard Time/Daylight Time – The following NPAC tunables are adjusted twice a year for Standard/Daylight.

1.	Short Business Day Start Time
2.	Long Business Day Start Time
3.	Conflict Restriction Window

A note regarding concurrence windows/timers: As mentioned in the previous section, a timer is not a meter that “runs” only during the Business Day intervals, but rather is a calculation in GMT of the timer’s expiration date/time. When the Short or Long Business Day Start Time, or Conflict Restriction Window, is adjusted twice each year to reflect the daylight savings adjustment in local time (of the predominant time zone within each region), a timer that started just prior to the daylight savings adjustment will continue to “run” as if the adjustment had not been made. So in terms of local time, each Spring for a few days certain timers will appear to run for one hour too short and each Fall for a few days these same timers will appear to run for one hour too long.

1.2.16 SV Type and Alternative SPID in the NPAC SMS

SV Type and Alternative SPID functionality is implemented in NPAC software release 3.3 but is currently inactive in all NPAC Regions. Until NAPM LLC approval, this functionality will remain inactive in the NPAC SMS system.

With implementation of software release 3.3, the NPAC SMS will provide an SV Type indicator in each SV and Pooled Block record. This indicator will initially distinguish every TN and Pooled Block as being served by Wireline, Wireless, VoIP, or VoWIFI service. The SV Type indicator will be able to distinguish additional “types” as deemed necessary in the future by adding additional values. This information will be provisioned by the SOA and broadcast to the LSMS upon initial creation of the SV or Pooled Block and upon modification of the SV Type for those SOA and LSMS associations optioned “on” to send and receive this data.

The SV Type attribute will be populated by the SP Type, if this attribute is not supported by the Service Provider. The SV Type attribute must be provided if supported by the Service Provider.

The NPAC SMS shall provide an Alternative SPID field for each SV and Pooled Block record. This new field shall identify (if applicable) a second service provider – either a facility-based provider or reseller, acting as a non facility-based service provider associated with each TN or Pooled Block via their 4-digit SPID. The Alternative SPID must be a valid SPID defined in the NPAC SMS database. Alternative SPID is an optional attribute in a SV or Pooled Block record, even if it is supported by the Service Provider.

1.3 Background

Release 1.0

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-14	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

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 that year, the task force made significant progress in defining and resolving the issues related to implementing number portability. All North American regions for deployment in all North American Local Number Portability Regions then used the work done by the Illinois task force to move forward with LNP implementation. A group was formed under NANC called the LNPA Working Group that oversaw implementation issues and documentation clarifications to the FRS and IIS for Release 1.0.

Midwest Region Number Pooling

To support number pooling in the Midwest Region requirements were developed and implemented. The requirements are included in Appendix F for completeness. If a service provider system is implementing Midwest Region Number Pooling then some of these requirements will supercede other requirements in this FRS document.

Release 2.0

The industry through work in the LNPA Working Group defined requirements for the next major release to be adopted by all regions. The Release 2.0 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality as well as modifications to existing functionality. The major enhancements include service bureau support and network data support for SOA systems as well as enhancements to support service providers implementing wireless portability.

Release 3.0

Through the work of the LNPA Working Group, requirements for National Number Pooling were defined for Release 3.0 of the NPAC SMS. National Number Pooling is implemented as a replacement to the Midwest Region Number Pooling solution that was implemented as Release 1.4 of the NPAC SMS. This approach includes the optional use of a new Block object over the interface, such that the NPAC SMS now supports both the 1K Block of TNs using Subscription Versions and the new Block object, to represent a 1K block of pooled numbers. This approach is further defined in section 1.2.14 Number Pooling Overview, of this document.

Release 3.1

With the deployment of NPAC Release 3.0 in the Northeast region a SOA – NPAC Interface problem surfaced. The improved performance of NPAC Release 3.0 and the faster hardware platform that this software is running on is resulting in transactions being processed for broadcast to the industry quicker than the SOA – NPAC interface can transmit them. During peak periods the interface cannot support the volumes of notifications that the NPAC SMS is generating, thus there is a long delay in notification delivery that results in operational issues. There are several change orders that, together, have the potential of alleviating this problem. NeuStar and the LNPA Working Group has bundled these change orders together for NPAC Release 3.1.

Release 3.2

The industry through work in the LNPA Working Group defined requirements for the next release to be adopted by all regions. The Release 3.2 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality as well as modifications to existing functionality. The major enhancements include enhanced Bulk Data Download File processing capabilities, improved recovery functionality that supports the generation of linked reply messages over the NPAC SMS to SOA and/or LSMS interface, enhanced DPC/SSN value edits to ensure the data is formatted based on industry LNP standards, enhanced NPA Split processing that includes automated processing based on industry standard information, further Subscription Version processing capabilities, additional NPAC SMS edits to ensure that telephone numbers are not ported outside of a single LATA, and capabilities that will ease partial and full SPID migration (in the event of a purchase or merger between Service Providers).

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-15	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

Release 3.3

The industry through work in the LNPA Working Group defined requirements for the next release to be adopted by all regions. The Release 3.3 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality as well as modifications to existing functionality. The major enhancements include restriction of conflict resolution to alleviate inadvertent porting, improved recovery, flow control to assist with congestion situations, “un-do” cancel-pending SVs, improved abort behavior, BDD for notifications, performance improvements, resend exclusion, association heartbeat, application level error messages, and separate SOA association for notifications.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-16	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

1.4 Objective

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

1.5 Assumptions

A1-1 Proportional Billing

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

AR1-1 Service Provider ID

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

A1-2 Resource Accounting

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

AR3-1 Greenwich Mean Time

Specific time of day references in the Functional Requirements Specification are assumed to be in Greenwich Mean Time (GMT) for the following:

• SOA to NPAC SMS Messages

• NPAC SMS to Local SMS Messages

• Reports

• Bulk Data Download Files

AN3-4.1 NPA Split Information Source

The default information source for NPA Split processing shall be the NPA Split Load Flat File, which is processed automatically based on a housekeeping process.

AR3-2 NPAC Administrative and SOA Low-Tech Interface Time

DELETED

AR3-3 System Tunable Time

DELETED

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-17	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

AR4-1.1 Service Provider ID

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

AR5-2 Conflict Resolution Tunable due date value

The time used for the conflict restriction tunable calculation relies on the time value specified in the New Service Provider due date.

AR5-3 Changing of TN Range Notification Indicator while Notifications are Queued

In the event that the TN Range Notification Indicator is changed from TRUE to FALSE any notifications for multiple TNs that were already created and are in queue will be sent in the range format and in the event that the TN Range Notification Indicator is changed from FALSE to TRUE any notifications for multiple TNs that were already created and are in queue will be sent in the single format.

AR6-1 Range Activations

DELETED

AR6-2 Percent of Range Activations

DELETED

AR6-3 TN-to-Transaction Ratio

There is one TN per CMIP transaction as specified in R6-28.1, R6-28.2, R6-29.2, RR6-107, RR6-108, and RR6-109. (previously NANC 393, AR-New-1)

AR6-4 CMIP Transaction Definition

A CMIP transaction is a request/notification and it’s corresponding response. (previously NANC 393, AR-New-2)

AR6-5 Peak Period Definition

Peak, as specified in R6-28.2 and R6-29.2, is defined as a five-minute period, and one peak can occur within any 60-minute window. (previously NANC 393, AR-New-3)

AR6-6 Number of Local SMS Associated to the NPAC SMS

There are thirty (30) Local SMSs associated to the NPAC SMS as specified in RR6-109, related to the total NPAC SMS bandwidth for a single NPAC SMS region. (previously NANC 393, AR-New-4)

A8-1 Service Provider Audits Issued Immediately

NPAC SMS will process audit requests from service providers immediately.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-18	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

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.

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.

A3-5 Associated Service Provider Multiple Service Provider Ids

Associated service providers using SOA functionality from another primary service provider must use another service provider id if they choose to interact with the NPAC independently from the primary service provider for SOA functionality.

1.6 Constraints

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

C1-1 Real Time Call Processing

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

C1-2 Service Provider Activity Tracking

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

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-19	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

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.

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

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.

C3-1 Associated Service Provider Notification Aggregation

NPAC SMS aggregation of all messages over the SOA to NPAC SMS interface for primary and associated service provider ids will not be supported.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	1-20	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Introduction

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 Appendix A, Flow 2.1 NPAC SMS Provision Service Process, on page A-1.

2.1.1 Service provider-to-service provider activities

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

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 Appendix A, Flow 2.1.2 NPAC SMS Subscription Version Creation Process, on page A-1.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.1.2.1 Create Subscription Version

When a number is ported, both the old and new Service Providers can 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 process 2.1.3, as illustrated in Appendix A, Flow 2.1 NPAC SMS Provision Service Process, on page A-1. If concurring notification or explicit non-concurrence from the new Service Provider is not received, the process flows to 2.6 (Cancel).

2.1.2.3 Final Concurrence Notification to Old Service Provider

The NPAC will send a final concurrence notification to the Old Service Provider who did not send a concurring notification.

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.1.4 NPAC SMS “activate and data download” process

The NPAC network data broadcast download flow is shown in Appendix A, Flow 2.1.4 NPAC SMS Activate and Data Download Process, on page A-1.

2.1.4.1 New Service Provider sends activation to NPAC SMS

The new Service Provider sends an activate notification to the NPAC SMS. If the current date is greater than or equal to the new Service Provider due date, the flow continues. Otherwise, broadcast of the activation is rejected.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.1.4.2 NPAC SMS broadcasts network data to appropriate Service Providers

Upon receipt of the activation notification, the NPAC SMS broadcasts the network update data in real time to the appropriate Service Providers’ Local SMSs.

2.1.4.3 Failure — notify NPAC

If the NPAC SMS does not receive positive acknowledgment of the broadcast from all Service Providers, 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 the list of Service Providers associated with each failed or partial failure subscription version 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.

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 Appendix A, Flow 2.2 NPAC SMS Disconnect Process, on page A-1.

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, optionally, the date that the disconnect information is to be broadcast to all Local SMSs (the ‘effective release date’).

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-3	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

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 donor notification

The NPAC SMS will broadcast the effective release date and disconnect date to the donor SOA.

2.2.4 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 Appendix A, Flow 2.3 NPAC SMS Repair Process, on page A-2.

2.3.1-A Service provider receives problem notification from customer

If a customer determines there is a problem with their service, they may contact the Service Provider and request Repair Service. This is one possible entry point to the Repair Process flow.

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

If another Service Provider determines there is a problem with a customer’s service, they may contact the current Service Provider and request Repair Service. This is one possible entry point to the Repair Process flow.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-4	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.3.1-C Service provider receives problem notification from NPAC SMS

If the NPAC determines there is a problem with a customer’s service, they may contact the current Service Provider and request Repair Service. This is one possible entry point to the Repair Process flow.

2.3.2 Service provider analyzes the problem

If NPAC SMS intervention is needed to resolve the problem, up to three repair actions may be required before repairs can be initiated.

2.3.2-A Subscription data query required

If a Subscription data query is required to initiate the repair, a query is launched to the Local Service Providers.

2.3.2-B Subscription data audit required

If a Subscription data audit is required before the repair can be initiated, an audit is initiated with the local Service Providers.

2.3.2-C Network synchronization required

If network synchronization is required, the process flows to 2.3.5, Request broadcast of subscription data.

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 subscription data

There will be audit capabilities in the NPAC SMS to aid in isolating problems. A Service Provider may request a download of subscription data to assist in the repair process, if necessary.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-5	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.3.5 Broadcast repaired subscription data

If inaccurate routing data is found, the NPAC SMS will broadcast the correct subscription data to any involved Service Provider’s networks to correct inaccuracies.

2.4 Conflict 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 Appendix A, Flow 2.4.1 Conflict Process, on page A-2.

2.4.1 Subscription version in conflict

A Subscription Version may be put into a conflict state either by the old Service Provider (assuming certain conditions are true), or as a result of a failure to acknowledge a Subscription Version in Cancel-Pending state by the new Service Provider. Subscription Versions set to either conflict or cancel initiate the creation of an entry in the Subscription Cause Code field identifying the cause of the status change.

2.4.1.1 Cancel-Pending Acknowledgment missing from new Service Provider

If the new Service Provider has not yet acknowledged a Subscription Version in Cancel-Pending state, the Subscription Version is put into Conflict, and the Cause Code is updated accordingly.

2.4.1.2 Old Service Provider requests conflict status

If the old Service Provider requests that a Subscription Version be put in conflict, it must be the first time the request has been made (a request to put a Subscription Version in conflict can only be made once by the old Service Provider). The request must be received in the NPAC a tunable number of hours prior to 12:00 A.M. of the new Service Provider due date and the expiration of the Final Concurrence Window unless short timers are being used for the port. If the old Service Provider has not satisfied these conditions then the Subscription Version cannot be put into conflict.

2.4.1.3 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. The old Service Provider can only place a “pending” Subscription Version in “conflict” one time.

2.4.1.4 Change of status upon Old Service Provider non-concurrence

A Subscription Version creation with authorization set to “False” from the Old Service Provider causes the NPAC SMS to place the Subscription Version in conflict during the “Create Version” process (2.1.2).

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-6	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.4.1.5 Change of status upon New Service Provider non-concurrence

Non-concurrence from the New Service Provider causes the NPAC SMS to cancel the Subscription Version 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. If the conflict is resolved, the new Service Provider sets the Subscription Version status to pending. If the conflict is not resolved with the tunable maximum number of days, the NPAC SMS cancels the Subscription Version, and sets the Cause Code for the Subscription Version.

2.4.2.1 Cancel pending notification

The cancel-pending notification is used for Subscription Versions where both the Old and New Service Providers have sent their Create message to the NPAC SMS. The status will be either pending or conflict.

If the Old Service Provider sends the Cancel message, the Subscription Version is set to cancel-pending. A notification is sent to both Old and New Service Providers.

1.	If the New Service Provider sends a cancellation acknowledgment, the status is set to Canceled.
2.	If the New Service Provider does NOT send a cancellation acknowledgment, the NPAC SMS waits for both Cancellation Concurrence Windows to expire, at which time the status is set to Conflict and the NPAC SMS sends a notification to both the Old and New Service Providers indicating the status change.
3.	The Old Service Provider may optionally send the cancellation acknowledgment.

If the New Service Provider sends the Cancel message, the Subscription Version is set to cancel-pending. A notification is sent to both Old and New Service Providers.

1.	If the Old Service Provider sends a cancellation acknowledgment, the status is set to Canceled.
2.	If the Old Service Provider does NOT send a cancellation acknowledgment, the NPAC SMS waits for both Cancellation Concurrence Windows to expire, at which time the status is set to Cancel.
3.	The New Service Provider may optionally send the cancellation acknowledgment.

If the Service Provider (either Old or New) that sent the Cancel message, issued the cancel request in error, that Service Provider can “un-do” the request by sending a subsequent modify request, and the Subscription Version is set back to pending. A notification is sent to both Old and New Service Providers.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-7	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.4.3 Subscription version cancellation

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, set the Cause Code for the Subscription Version, and notify both the old and new Service Providers of the cancellation.

2.4.4 Conflict resolved

When both Service Providers agree to resolve the conflict, one of the Service Providers will send a request to the NPAC SMS to change the Subscription Version status to pending. In the case of cause codes 50 or 51, the NPAC will only accept the resolve conflict message from the Old Service Provider.

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 Appendix A, Flow 2.5 NPAC SMS Disaster Recovery Process, on page A-1.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

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.

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.

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 Appendix A, Flow 2.6 Cancellation Process, on page A-2.

2.6.1 Service Provider issues service order cancellation

From the time both Service Providers have sent a valid 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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.6.2 Service provider cancels an un-concurred Subscription Version

If a Service Provider issues a cancel on a Subscription Version that was created by that Service Provider and not concurred to by the other Service Provider involved in that port, or if the Subscription Version was initiated, then subsequently canceled by the NPAC, the Subscription Version will be canceled immediately and a notification will be sent to both Service Providers.

2.6.3 NPAC requests missing acknowledgment from Service Provider

When notified that a Subscription Version has been set to cancel-pending, the non-requesting Service Provider must concur by returning a cancel-pending acknowledgment to the NPAC SMS within a tunable amount of hours. If the NPAC does not receive acknowledgment in the allowable time from the Service Provider, a request is sent to that Service Provider for a cancel-pending-acknowledgment. If the missing cancel-pending-acknowledgment is not received within a tunable time frame, the Subscription Version status is set to “conflict” if it is the new Service Provider that failed to acknowledge, but is set to cancel if the old Service Provider failed to acknowledge. In either case, the Cause Code is then set for the Subscription Version, and both Service Providers are then notified of the Subscription Version status change.

2.6.4 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, update the Cause Code for the Subscription Version, 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 Appendix A, Flow 2.7 Audit Process, on page A-1.

2.7.1 Service provider requests audit

Any Service Provider can request an audit of another Service Provider’s LSMS.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

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.

2.7.5 NPAC SMS sends report of audit discrepancies to requesting SOA

Once the NPAC SMS has completed updates to the appropriate Local SMSs, the NPAC SMS generates an Audit Discrepancy report to the Service Provider SOA that initiated the Audit request.

2.7.6 NPAC SMS sends report of audit results to requesting SOA

The NPAC SMS sends the audit results to the Service Provider SOA that initiated the audit request, to indicate the audit is complete.

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 Appendix A, Flow 2.8 Report Process, on page A-2.

2.8.1 Service provider requests report

Service Provider personnel request report generation via either the SOA Low Tech Interface or by contacting NPAC personnel.

2.8.2 NPAC SMS generates report

The NPAC SMS generates the report that Service Provider Personnel requested via either the SOA Low Tech to NPAC SMS interface or based on NPAC personnel input into the NPAC Administrative GUI.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Business Process Flows

2.8.3 Report delivered via NPAC Administrative or SOA Low-Tech Interface, Email, electronic file, fax, printer

The NPAC SMS delivers the report to the destination specified in the request.

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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	2-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

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 Entity Relationship Model illustrates the logical data model associated with the data elements for the NPAC SMS, and the relationship between NPAC Customer data and other data tracked or created by the system.

AR3-1     Greenwich Mean Time

DELETED

AR3-2     NPAC Administrative and SOA Low-Tech Interface Time

DELETED

AR3-3     System Tunable Time

DELETED

[Graphic Omitted: 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
Address	Network Address: raw binary data stored as unformatted bytes.
B	Boolean (True or False) indicator.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

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: 3digit NPA, 3digit NXX, 4digit Station Number.

Table 3-1 Data Type Legend

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 the tables that follow:

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	Required	Description
	(Size)
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 Function	ns M	Ö	Each bit in the mask represents a Boolean indicator for the following functional options: •    SOA Management •    SOA Network Data Management •    SOA Data Download •    LSMS Network Data Management •    LSMS Data Download •    LSMS Queries/Audits

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
NPAC New Functionality Support	B	Ö	Each value represents a Boolean indicator is set to true if a service provider supports the functionality defined below. This Boolean is used to support backward compatibility. All values default to FALSE. •    Timer Type – True if the SOA supports timer type over the interface. •    Business Hours – True if the SOA supports business days/hours over the interface. •    LSMS WSMSC DPC SSN Data – True if the LSMS system supports WSMSC DPC and SSN Data in subscription versions. •    SOA WSMSC DPC SSN Data – True if the SOA system supports WSMSC DPC and SSN Data in subscription versions.
Port In Timer Type	E	Ö	Timer type supported by the Service Provider for porting where they are the New Service Provider: S – Short Timers L – Long Timers
Port Out Timer Type	E	Ö	Timer type supported by the Service Provider for porting where they are the Old Service Provider: S – Short Timers L – Long Timers
Business Hour/Days	E	Ö	Business Hours supported by the Service Provider: S – Short Business Hours L – Long Business Hours
NPA-NXX-X downloads Indicator	B	Ö	A Boolean that indicates whether NPAC Customer SOA NPA-NXX-X the NPAC Customer accepts

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
			from the NPAC SMS to their SOA. This would be used in conjunction with the SOA Data Download bit mask value. The default value is False.
NPAC Customer LSMS NPA-NXX-X Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer accepts NPA-NXX-X downloads from the NPAC SMS to their LSMS. This would be used in conjunction with the LSMS Data Download bit mask value. The default value is False.
NPAC Customer LSMS EDR Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer utilizes Efficient Data Representation (EDR) on the LSMS. This would be used in conjunction with the LSMS Data Download bit mask value. The default value is False.
TN Range Notification Indicator	B	Ö	A Boolean that indicates whether or not the NPAC Customer supports receiving the range format for SOA Notifications. The default value is False.
No New SP Concurrence Notification Indicator	B	Ö	A Boolean that indicates whether or not the NPAC Customer supports receiving the SOA Notification “No New SP Concurrence Notification. The default value is False.
SOA Notification Priority Tunable Parameters	C	Ö	Allows a NPAC Customer to establish the priority to be used for transmitting the notifications listed in Appendix C, Table C7 to his SOA. Valid priority values for these notifications are HIGH, MEDIUM, LOW, and NONE. A priority of NONE indicates that the NPAC Customer does NOT wish to receive that particular notification. The default value is MEDIUM.
NPAC Customer SOA Linked Replies	B	Ö	A Boolean that indicates whether or not the

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
Indicator			NPAC Customer supports receiving Linked Reply recovery responses over the NPAC SMS to SOA interface. The default value is FALSE.
NPAC Customer Local SMS Linked Replies Indicator	B	Ö	A Boolean that indicates whether or not the NPAC Customer supports receiving Linked Reply recovery responses over the NPAC SMS to Local SMS interface. The default value is FALSE.
Maximum TN Download in Recovery Request	N	Ö	A Service Provider specific tunable indicating the maximum number of TNs that can be recovered in a single timebased, recovery request. Valid range is 11-0000. The default value is 2000. Refer to Appendix C System Tunables for information on the maximum for TN-based SV recovery requests.
Service Provider SOA SWIM Recovery Indicator	B	Ö	A Service Provider Boolean that indicates whether or not this Service Provider supports SWIM Recovery over their SOA to NPAC SMS interface. The default value is FALSE.
Service Provider LSMS SWIM Recovery Indicator	B	Ö	A Service Provider Boolean that indicates whether or not this Service Provider supports SWIM Recovery over their LSMS to NPAC SMS interface. The default value is FALSE.
NPAC SMS-to-SOA Application Level Heartbeat Indicator	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer SOA supports an Application Level Heartbeat message. The default value is FALSE.
NPAC SMS-to-LSMS Application Level	B	Ö	A Service Provider Boolean that defines

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
Heartbeat Indicator			whether the NPAC Customer LSMS supports an Application Level Heartbeat message. The default value is FALSE.
SOA Action Application Level Errors Indicator	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer supports Application Level Errors across the SOA Interface for M-ACTIONs. The default is FALSE.
LSMS Action Application Level Errors Indicator	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer supports Application level Errors across the LSMS Interface for M-ACTIONs. The default is FALSE.
SOA Non-Action Application Level Errors Indicator	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer supports Application Level Errors across the SOA Interface for all non-M-ACTIONs.
LSMS Non-Action Application Level Errors Indicator	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer supports Application Level Errors across the LSMS Interface for all non-M-ACTIONs.
SOA Notification Channel Service Provider Tunable	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer SOA supports a separate SOA association dedicated to notifications. The default is FALSE.
Subscription Version TN Attribute Flag Indicator	B	Ö	A Service Provider Boolean that defines whether the NPAC Customer supports receipt of the Subscription Version TN attribute in a Subscription Version Status Attribute Value Change or Subscription Version Attribute Value Change notification. The default is FALSE.
Number Pool Block NPA-NXX-X			A Service Provider Boolean that defines

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
Attribute Flag Indicator	B	Ö	whether the NPAC Customer supports receipt of the Number Pool Block NPA-NXX-X attribute in a Number Pool Block Status Attribute Value Change or Number Pool Block Attribute Value Change notification. The default is FALSE.
Cancel-Pending-to-Conflict Cause Code Indicator	B	Ö	A Service Provider Boolean that defines whether a SOA NPAC Customer supports a Conflict message that uses the CancelPendingtoConflict Cause Code. The default is FALSE.
Service Provider SOA SV Query Indicator	B	Ö	A Service Provider Boolean that defines whether a SOA NPAC Customer supports enhanced Subscription Verison query functionality over their SOA to Service Provider SOA SV Query NPAC SMS Interface. The default is FALSE.
Service Provider LSMS SV Query Indicator	B	Ö	A Service Provider Boolean that defines whether a LSMS NPAC Customer supports enhanced Subscription Version query functionality over their LSMS to Service Provider LSMS SV Query  NPAC SMS Interface. The default is FALSE.
Service Provider Type	E	Ö	Enumeration indicating what type of service provider the NPAC Customer is: •   Wireline (0) •   Wireless (1) •   Non-Carrier (2) •   SP Type3 (3) (supported by the interface, but not accepted until industry use defined) •   SP Type 4 (4) (supported by the interface, but not accepted until industry use defined)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
			•   SP Type 5 (5) (supported by the interface, but not accepted until industry use defined)
Service Provider Type SOA Indicator	B		A Service Provider Boolean that indicates whether the NPAC Customer SOA supports the Service Provider Type attribute. Default value is FALSE.
Service Provider Type LSMS Indicator	B		A Service Provider Boolean that indicates whether the NPAC Customer LSMS supports the Service Provider Type attribute. Default value is FALSE.
NPAC Customer SOA SV Type Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports SV Type (or Number Pool Block SV Type) information from the NPAC SMS to their SOA. The default value is False.
NPAC Customer SOA Alternative SPID Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alternative SPID information (a second service provider – either a facility-based provider or reseller, acting as a non facility-based provider) from the NPAC SMS to their SOA. The default value is False.
NPAC Customer LSMS SV Type Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports SV Type (or Number Pool Block SV Type) information from the NPAC SMS to their LSMS. The default value is False.
NPAC Customer LSMS Alternative SPID Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alternative SPID information (a second service provider — either a facility-based provider or reseller, acting as a non facility-based provider) from the NPAC SMS to their LSMS.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
			The default value is False.

Table 3-2 NPAC Customer Data Model

NPAC CUSTOMER CONTACT DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
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.
Contact City	C (20)	Ö	Contact Organization city.
Contact State	C (2)	Ö	Contact Organization state.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER CONTACT DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
Contact Zip	C (9)	Ö	Contact Organization zip code or postal code.
Contact Country	C (20)	Ö	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-3 NPAC Customer Contact Data Model

NPAC CUSTOMER NETWORK ADDRESS DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
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 (12)	Ö	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-4 NPAC Customer Network Address Data Model

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NPAC CUSTOMER ASSOCIATED SERVICE PROVIDER DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
Primary NPAC Customer ID	C (4)	Ö	An alphanumeric code which uniquely identifies an NPAC Customer that will act as a primary SPID
Associated NPAC Customer ID	C (4)	Ö	An alphanumeric code that uniquely identifies an NPAC Customer that will act as a SPID associated with a primary SPID.

Table 3-5 NPAC Customer Associated Service Provider Data Model

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 the table that follows:

SUBSCRIPTION VERSION DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
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.
			Number Portability Type. Valid enumerated values are:
Local Number Portability Type	E	Ö	• LSPP — Local Service Provider Portability (0) • LISP — Local Intra-Service Provider Portability • POOL — Pooled Block Number Port (2)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
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) •   DP — Disconnect Pending (6) •   O — Old (7) •   C — Canceled (8) •   CP — Cancel Pending (9)
CLASS DPC	N (9)	Ö	DPC for 10-digit GTT for CLASS features.
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.
WSMSC DPC	N (9)	Ö	DPC for 10-digit GTT for WSMSC features. This field is only required if the service provider supports WSMSC data.
WSMSC SSN	N (3)	Ö	WSMSC SSN for the Subscription Version. This field is only required if the service provider supports WSMSC data.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
New Service Provider Due Date	T	Ö	The due date planned by the new Service Provider for Subscription Version Transfer. The seconds’ field should always be populated with zeros.
Old Service Provider Due Date	T	Ö	The due date planned by the old Service Provider for Subscription Version Transfer. The seconds’ field should always be populated with zeros.
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 at least one Local SMS system successfully acknowledged the broadcast for the activate of 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 Complete Time Stamp	T		The date and time that at least one Local SMS system successfully acknowledged the broadcast for the disconnect of the Subscription Version.
Effective Release Date	T		The date that the Subscription Version is to be deleted 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) •   DP — Disconnect Pending (6)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
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 last placed in conflict.
Conflict Resolution Time Stamp	T		The date and time that the resolution of a Subscription Version in conflict is acknowledged.
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.
End User Location Value	N (12)		For future use.
End User Location Value Type	N (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 at least one local SMS system successfully acknowledged the broadcast for the modification of the Subscription Version.
Billing ID C	(1- 4)		For future use. Can be variable 1-4 alphanumeric characters.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL

Attribute Name	Type	Required	Description
	(Size)
Status Change Cause Code	N (2)		Used to specify reason for conflict when old Service Provider Authorization is set to False, or to indicate NPAC SMS initiated cancellation. Valid values are: 0 — No value 1 — NPAC SMS Automatic Cancellation 2 – NPAC SMS Automatic Conflict from Cancellation 50 – LSR/WPR Not Received 51 – Initial Confirming FOC/WPRR Not Issued 52 — Due Date Mismatch 53 — Vacant Number Port 54 – General Conflict
Timer Type	E	Ö	Timer type used for the subscription version. S – Short Timers L – Long Timers
Business Hour Type	E	Ö	Business Hours used for the subscription version. S – Short Business Hours L – Long Business Hours
Alternative SPID	C (4)		An alphanumeric code which uniquely identifies Alternative SPID information (a second service provider – either a facility-based provider or reseller, acting as a non facility-based provider) for this SV. This field may only be specified if the service provider SOA supports Alternative SPID.
SV Type	E	Ö	Subscription Version Type. Valid enumerated values are: • Wireline – (0) • Wireless – (1) • VoIP – (2) • VoWIFI – (3) • SV Type 4– (4) • SV Type 5– (5) • SV Type 6– (6) This field is only required if the service provider supports SV Type data.

Table 3-6 Subscription Version Data Model

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

SUBSCRIPTION VERSION FAILED SP LIST DATA MODEL

Attribute Name	Type (Size)	Required	Description
Subscription Version ID (Key)	N	Ö	A unique sequential number assigned upon creation of the Subscription Version.
SPID	C(4)	Ö	The Service Provider ID of the discrepant SP.
SP Name	C(40)	Ö	The NPAC Customer Name of the discrepant SP.

Table 3-7 Subscription Version Failed SP List Data Model

NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL

Attribute Name	Type (Size)	Required	Description
Block ID	N	Ö	A unique sequential number assigned upon creation of the Block.
Block Holder SPID	C(4)	Ö	The Service Provider Id of the block holder.
NPA-NXX-X	N(7)	Ö	NPA-NXX-X of the 1K Block.
LRN	TN	Ö	The LRN is an identifier for the switch on which the pooled NPA-NXX-X resides for the 1K Block.
CLASS DPC	N (9)	Ö	DPC for 10-digit GTT for CLASS features for the 1K Block.
CLASS SSN	N (3)	Ö	CLASS SSN for the 1K Block.
LIDB DPC	N (9)	Ö	DPC for 10-digit GTT for LIDB features for the 1K Block.
LIDB SSN	N (3)	Ö	LIDB SSN for the 1K Block.
CNAM DPC	N (9)	Ö	DPC for 10-digit GTT for CNAM features for the 1K Block.
CNAM SSN	N (3)	Ö	CNAM SSN for the 1K Block.
ISVM DPC	N (9)	Ö	DPC for 10-digit GTT for ISVM features for the 1K Block.
ISVM SSN	N (3)	Ö	ISVM SSN for the 1K Block.
WSMSC DPC	N (9)	Ö	DPC for 10-digit GTT for WSMSC features for the 1K Block. This field is only required if the service provider

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL

Attribute Name	Type (Size)	Required	Description
			supports WSMSC data, as defined in the NPAC Customer Data Model.
WSMSC SSN	N (3)	Ö	WSMSC SSN for the 1K Block. This field is only required if the service provider supports WSMSC data, as defined in the NPAC Customer Data Model.
Creation Date	T		The date and time (GMT) that this Block Holder record was created.
Activation Start Timestamp	T		Date and time (GMT) of the Start of the Activation. This field defines the date and time of the start of the activation request (i.e., the date and time the NPAC begins the broadcasts to the LSMSs).
Activation Broadcast Complete Timestamp	T		Date and time (GMT) of the Completion of the Activation. This field defines the date and time of the completion of the activation request (i.e., the date and time the NPAC receives at least one Local SMS acknowledgment of the broadcast, for the activation of the Block).
Last Modified Timestamp	T		Date and time (GMT) of the Last Modification to the Block. The initial value is the Creation Timestamp.
Disconnect Request Time Stamp	T		The date and time that the Block disconnect request was made by the NPAC personnel.
Disconnect Broadcast Time Stamp	T		The date and time that broadcasting began to all local SMS systems for the disconnect of the Block.
Disconnect Complete Time Stamp	T		The date and time that at least one Local SMS system successfully acknowledged the broadcast, for the disconnect of the Block.
Old Time Stamp	T		The date and time that the Block became old.
Modify Request Timestamp	T		The date and time that the Block 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 Block.
Modify Broadcast Complete Timestamp	T		The date and time that at least one local SMS system successfully acknowledged the broadcast, for the modification of the Block.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL

Attribute Name	Type (Size)	Required	Description
SOA Orgination Indicator	B	Ö	A Boolean that indicates whether or not the NPA-NXX-X Holder’s SOA initiated the Block over the SOA to NPAC SMS Interface, and whether or not to send notifications to the SOA.
			This attribute will be initially set by the NPAC SMS at the time of Block creation.
			If originated by SOA, value is TRUE.
			If originated by NPAC, value is FALSE.
Status	E	Ö	Status of the Block.
			The initial value is S for Sending.
			Valid enumerated values are:
			A - Active (1)
			S - Sending (3)
			F - Failed (4)
			PF - Partial Failure (5)
			O - Old (7)
Download Reason	E		The reason the Block is being downloaded to the SOA or LSMS. Valid values are:
			0 – new1
			1 – delete1
			2 – modified
			3 – audit-discrepancy

Table 3-8 Number Pooling Block Holder Information Data Model

NUMBER POOLING BLOCK FAILED SP LIST DATA MODEL

Attribute Name	Type (Size)	Required	Description
Block ID (Key)	N	Ö	A unique sequential number assigned upon creation of the Block.
SPID	C(4)	Ö	The Service Provider ID of the discrepant SP.
SP Name	C(40)	Ö	The NPAC Customer Name of the discrepant SP.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

Table 3-9 Number Pooling Block Failed SP List Data Model

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 the tables that follow:

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	C (6)		The new NPA-NXX for an NPA split.
Split Activation Date	T		The date that the new NPA-NXX becomes available for use in an NPA 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 split. This date represents the end of the permissive dialing period.
NPA-NXX has been Ported	T		A timestamp that indicates when the first TN within this NPA-NXX has been ported.

Table 3-10 Portable NPA-NXX Data Model

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 a ported TN or Number Pool Block resides.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

LRN DATA MODEL

Attribute Name	Type (Size)	Required	Description
NPAC Customer ID	C (4)	Ö	An alphanumeric code which uniquely identifies an NPAC Customer.

Table 3-11 LRN Data Model

LSMS FILTERED NPA-NXX DATA MODEL

Attribute Name	Type (Size)	Required	Description
LSMS Filter NPA-NXX ID	N	Ö	A unique sequential number assigned upon creation of the LSMS Filtered NPA-NXX record.
NPAC Customer ID	C (4)	Ö	An alphanumeric code that uniquely identifies the LSMS NPAC Customer who is filtering subscription version broadcasts.
NPA-NXX	C (6)	Ö	The NPA-NXX for which the LSMS is filtering subscription version broadcasts.
Creation Timestamp	T	Ö	Date the filtered NPA-NXX was created.

Table 3-12 LSMS Filtered NPA-NXX Data Model

NUMBER POOLING NPA-NXX-X HOLDER INFORMATION DATA MODEL

Attribute Name	Type (Size)	Required		Description
NPA-NXX-X ID	N		Ö	A unique sequential number assigned upon creation of the NPA-NXX-X.
NPAC Customer ID-	C(4)		Ö	The Service Provider Id of the NPA-NXX-X holder.
NPA-NXX-X	N(7)		Ö	NPA-NXX-X of the 1K Block.
NPA-NXX-X Effective Date	T		Ö	The effective date of the 1K Block. The time for this field will be stored in GMT, but equivalent to 00:00:00 network data time CST.
Creation Time Stamp	T			The date and time (GMT) that this NPA-NXX-X Holder record was created.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

NUMBER POOLING NPA-NXX-X HOLDER INFORMATION DATA MODEL

Attribute Name	Type (Size)	Required	Description
Last Modified Time Stamp	T		The date and time (GMT) of the Last Modification to this NPA-NXX-X Holder record. The default value is the Creation Timestamp.
Download Reason	E		The reason the NPA-NXX-X is being downloaded to the SOA or LSMS. Valid values are: 0 – new1 1 – delete1 2 – modified 3 – audit-discrepancy
Alternative SPID	C (4)		An alphanumeric code which uniquely identifies Alternative SPID information (a second service provider – either a facility-based provider or reseller, acting as a non facility-based provider) for this Number Pool Block. This field may only be specified if the service provider SOA supports Alternative SPID.
Number Pool Block SV Type	E	Ö	Number Pool Block SV Type. Valid enumerated values are:
			• Wireline – (0) • Wireless – (1) • VoIP – (2) • VoWIFI – (3) • SV Type 4– (4) • SV Type 5– (5) • SV Type 6– (6) This field is only required if the service provider supports Number Pool Block SV Type data.

Table 3-13 Number Pooling NPA-NXX-X Holder Information Data Model

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

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-6.2     Mass Update Filter Usage

NPAC SMS shall, for a mass update request, only send updates for subscription versions that are not filtered on the Local SMS.

R3-7.1     Select Subscription Versions mass changes for one or more Subscription Versions

NPAC SMS shall allow NPAC personnel to select Subscription Versions for mass update which match a user defined combination of any of the following: SPID, LNP Type (any single LNP Type or none), TN, TN range (NPA-NXX-xxxx through yyyy, where yyyy is greater than xxxx), LRN, DPC values, SSN values, Billing ID, End User Location Type or End User Location Value, on the NPAC Administrative Interface. (Previously part of B-760 and B-761)

Note: If a single LNP Type is selected, then only that LNP Type will be used, otherwise, if no LNP Type is selected, then no restriction is imposed on the LNP Type as a selection criteria.

R3-7.2     Administer Mass update on one or more selected Subscription Versions

NPAC SMS shall allow NPAC personnel to 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, disconnect pending or canceled) for LRN, DPC values, SSN values, SV Type, Alternative SPID (if the requesting SOA supports Alternative SPID data), Billing ID, End User Location Type or End User Location Value. (reference NANC 399)

R3-7.3    Mass Update Selection Criteria

NPAC SMS shall require at least one selection criteria to be entered for a mass update.

R3-7.4     Mass Update Service Provider Id

NPAC SMS shall match the Service Provider Id entered as selection criteria with the New or current Service Provider Id in the Subscription Version.

R3-7.5     Mass Update — Creation of Old Subscription Version

DELETED

R3-7.6     Mass Update — Old Subscription Version No Broadcast

DELETED.

R3-7.7     Mass Update Error Processing

NPAC SMS shall log an exception and proceed with Mass Update processing upon finding a subscription version in sending, disconnect pending, or partial failed status.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

R3-7.8    Mass Update Exception Report

NPAC SMS shall produce an exception report for NPAC Personnel when requested that lists the Subscription Versions that were exceptions not processed during Mass Update processing.

RR3-254    Validation of LATA ID Errors on Mass Updates

NPAC SMS shall log an entry to be used for the mass update exception report when any of the LATA ID data edits are violated when mass updating a Subscription Version or Number Pool Block, and continue processing the mass update request. (Previously NANC 319 req 10)

Note: In an example where 2000 SVs are being mass updated and 100 encountered LATA ID edit errors, the NPAC will perform the mass update by updating the 1900 SVs that are valid, and logging the remaining 100 SVs to be picked up on the mass update exception report.

R3-7.9    Mass Update Required Entry of Service Provider ID

NPAC SMS shall require NPAC personnel to specify a Service Provider ID when entering Selection Criteria for a Mass Update.

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.2.1     Block Holder, Mass Update

RR3-210     Block Holder Information Mass Update – Update Fields

NPAC SMS shall allow NPAC Personnel, via a mass update, to update the block holder default routing information (LRN, DPC(s), and SSN(s)), SV Type, Alternative SPID (if the requesting SOA supports Alternative SPID data) for a 1K Block as stored in the NPAC SMS. (Previously B-762, reference NANC 399)

RR3-211    Block Holder Information Mass Update – Block Intersection Rejection

NPAC SMS shall reject a mass update request by NPAC Personnel, and issue an error message, if the TN Range and LNP Type of either POOL or none, is entered as Selection Criteria, for the requesting Service Provider, and intersects an existing 1K Block, for that requesting Service Provider, as stored in the NPAC SMS, other than Blocks with a status of old. (Previously B-763)

RR3-212    Block Holder Information Mass Update – Block Status Validation

NPAC SMS shall reject a mass update request to a Block, if the Block’s status is NOT active, or if the Block Failed SP List contains one or more Service Providers. (Previously B-764)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-213    Block Holder Information Mass Update – Download to EDR Local SMS

NPAC SMS shall download Number Pooling Block Information, for mass updates, using the Number Pooling Block Object, via the NPAC SMS to Local SMS Interface, when the Service Provider’s EDR Indicator is TRUE, at the time of the mass update request. (Previously B-780)

RR3-214    Block Holder Information Mass Update – Download to non-EDR Local SMS

NPAC SMS shall download Number Pooling Block Information, for mass updates, using Subscription Version(s) with LNP Type of POOL, via the NPAC SMS to Local SMS Interface, when the Service Provider’s EDR Indicator is FALSE, at the time of the mass update request. (Previously B-790)

RR3-215    Block Holder Information Mass Update – Download of SVs of Type POOL to non-EDR Local SMS

NPAC SMS shall NOT break up Subscription Versions of LNP Type POOL in a 1K Block, when downloading Number Pooling Block Information, for mass updates, via the NPAC SMS to Local SMS Interface, to non-EDR Local SMSs. (Previously B-800)

RR3-216     Block Holder Information Mass Update — Creation of Old Block

DELETED.

RR3-217     Block Holder Information Mass Update — Old Block No Broadcast

DELETED.

3.2.2     Service Provider ID (SPID) Migration Update

The following section defines how the NPAC SMS supports modification of Service Provider ID on Local Number Portability information. NPAC Personnel generate Selection Input Criteria SPID Migration Update Request Files (SIC-SMURF) that are used by both NPAC and Service Providers to update their databases. The update is performed off-line during a maintenance window. No data is transmitted across the interface.

RR3-255    SPID Migration Update – OpGUI Entry

NPAC SMS shall allow NPAC Personnel, via the NPAC SMS Administrative Interface, to enter selection input criteria (mandatory: migrating away from SPID, migrating to SPID; at least one of the following three: NPA-NXX, LRN, and/or NPA-NXX-X) for a partial SPID Migration Update Request Process. (Previously NANC 323 Req 1)

RR3-256    SPID Migration Update – Generation of SIC-SMURF Files

NPAC SMS shall provide a mechanism that generates SIC-SMURF for NPA-NXX, LRN, and/or NPA-NXX-X upon completion of the entry of the selection input criteria in the NPAC SMS Administrative Interface, for a partial SPID Migration Update Request Process in the NPAC SMS. (Previously NANC 323 Req 2)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-257     SPID Migration Update — NPAC SMS Processing of Requested Data

NPAC SMS shall provide a mechanism to migrate SPID information according to the requested selection input criteria, when changing from one SPID to another SPID in selected NPA-NXX, LRN, and/or NPA-NXX-X data, and subordinate Number Pool Block and Subscription Version data in the NPAC SMS. (Previously NANC 323
Req 3)

RR3-258     SPID Migration Update — Suppression of Notifications

NPAC SMS shall suppress notifications to all Service Providers via the SOA to NPAC SMS Interface and NPAC SMS to LSMS Interface, when performing the partial SPID Migration Update Request Process. (Previously NANC 323 Req 4)

RR3-259     SPID Migration Update — NPAC SMS Processing of Requested Data Based on Status

NPAC SMS shall migrate NPA-NXX, LRN, and/or NPA-NXX-X data, as well as Number Pool Block and Subscription Version data that have ‘active-like’ statuses when performing the partial SPID Migration Update Request Process. (Previously NANC 323 Req 5)

Notes:

• ‘Active-like’ Blocks or Subscription Versions are defined to be Blocks or Subscription Versions that contain a status of active, sending, partial failure, old with a Failed SP List, or disconnect pending.

• ‘Pending-like’ Blocks or Subscription Versions are defined to be Blocks or Subscription Versions that contain a status of pending, conflict, cancel-pending, or failed. These will be required to be cleaned-up (activated or cancelled) prior to the execution of the migration process, so that none exist during the migration process.

• “Old” history data containing a status of cancelled or old with an empty FailedSP-List will NOT be migrated.

RR3-260     SPID Migration Update — SIC-SMURF File Names

NPAC SMS shall follow the SIC-SMURF file naming convention as described in Appendix E. (Previously NANC 323 Req 6)

RR3-261     SPID Migration Update — SIC-SMURF File Formats

NPAC SMS shall follow the SIC-SMURF file format as described in Appendix E. (Previously NANC 323 Req 7)

RR3-262     SPID Migration Update — SIC-SMURF NPA-NXX File Processing — Update NPA-NXX Network Data

NPAC SMS shall use the SIC-SMURF NPA-NXX file to update the SPID associated with NPA-NXXs in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 8)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-25 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-263     SPID Migration Update — SIC-SMURF NPA-NXX File Processing — Update Old SPID on SV Data

NPAC SMS shall use the SIC-SMURF NPA-NXX file to update the old service provider SPID on ‘active-like’ subscription versions when the NPA-NXX code holder SPID is the same as the migrating away from SPID value in the old service provider SPID on the ‘active-like’ subscription version, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 9)

Note: Service Providers need to be aware that if they query the NPAC SMS, historical copies of subscription versions and number pool blocks will still contain the SPIDs they had prior to migration.

RR3-264     SPID Migration Update — SIC-SMURF LRN File Processing — Update LRN Data

NPAC SMS shall use the SIC-SMURF LRN file to update the SPID associated with LRNs in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 10)

RR3-265     SPID Migration Update — SIC-SMURF LRN File Processing — Update Block Data

NPAC SMS shall update the blockholder SPID on Number Pool Blocks associated with the LRN that was updated in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 11)

RR3-266     SPID Migration Update — SIC-SMURF-LRN File Processing — Update SV Data

NPAC SMS shall update the new service provider SPID on subscription versions, regardless of LNP Type, associated with the LRN that was updated in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 12)

RR3-267     SPID Migration Update — SIC-SMURF NPA-NXX-X File Processing — Update NPA-NXX-X

NPAC SMS shall use the SIC-SMURF NPA-NXX-X file to update the SPID associated with NPA-NXX-Xs in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 13)

RR3-268     SPID Migration Update — Maximum Level of Granularity

NPAC SMS shall perform the partial SPID Migration Update Request Process at a maximum level of granularity of a single SPID. (Previously NANC 323 Req 14)

RR3-269     SPID Migration Update — Minimum Level of Granularity

NPAC SMS shall perform the partial SPID Migration Update Request Process at a minimum level of granularity of an NPA-NXX-X. (Previously NANC 323 Req 15)

RR3-270     SPID Migration Update — Creation of Number Pool Block for Old Service Provider

DELETED

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-26 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-271     SPID Migration Update — Creation of Number Pool Block for Old Service Provider — No Broadcast

DELETED

RR3-272     SPID Migration Update — Creation of Subscription Version for Old Service Provider

DELETED

RR3-273     SPID Migration Update — Creation of Subscription Version for Old Service Provider — No Broadcast

DELETED

RR3-274     SPID Migration Update — Exclusion of Data During Recovery

NPAC SMS shall exclude data in a recovery request for activity related to partial SPID Migration Update Request Process activity. (Previously NANC 323 Req 20)

RR3-275     SPID Migration Update — Rejection for ‘pending-like’ Number Pool Blocks or Subscription Versions

NPAC SMS shall reject a SPID Migration Update Request Process by NPAC Personnel, via the NPAC SMS Administrative Interface, if any “pending-like” Number Pool Blocks or Subscription Versions exist where the migrating away from SPID value is present. (Previously NANC 323 Req 21)

Note: For Number Pool Blocks this will be the Block Holder SPID, and for Subscription Versions this will be either the New SPID or Old SPID.

RR3-276     Update SPID on Messages Queued for Recovery

NPAC SMS shall apply the SPID update to any messages that are in the queue for recovery. (Previously NANC 323 Req 24)

RR3-277     SPID Migration Update — Consistency Check Across Network Data and LRN

NPAC SMS shall perform a consistency check across the selection criteria for NPA-NXX, LRN, and/or NPA-NXX-X, to ensure applicable data belonging to the migrating away from SPID is included in the SMURF files for NPA-NXX, LRN, and/or NPA-NXX-X, and issue an error to NPAC Personnel, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 25)

Note: The selection criteria of network data and/or LRN will have consistency edits enforced. In the case where all applicable data are NOT in the selection criteria, an error will be issued to the NPAC Personnel. As an example, NPA-NXX of 703-222 is owned by the migrating from SPID, which also uses 703-222-0000 as it’s primary LRN, and has an Number Pool Block of 703-567-2 which uses the 703-222-0000 LRN. When performing the input data for the migration, only one of these are specified as selection criteria, which will cause an error to be issued to the NPAC user. The NPA-NXX, LRN, and NPA-NXX-X must all be specified for the migration process to continue and generate the correct SMURF files.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-27 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

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, NPA-NXX-X Information, Number Pool Block and Service Provider Network data. (reference NANC 399)

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

- WSMSC DPC (for Local SMSs that support WSMSC data)

- WSMSC SSN (for Local SMSs that support WSMSC data)

- End User Location — Value

- End User Location — Type

- Billing ID

- LNP Type

- Download Reason

- SV Type (for Local SMSs that support SV Type data)

- Alternative SPID (for Local SMSs that support Alternative SPID data)

• 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

• NPA-NXX-X Data

- Service Provider ID

- NPA-NXX-X ID

- NPA-NXX-X Value

- Creation Timestamp

- Effective Timestamp

- Download Reason

• Block Data

- Block ID

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-28 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

- NPA-NXX-X

- LRN

- New Current Service Provider ID

- Activation Timestamp

- CLASS DPC

- CLASS SSN

- LIDB DPC

- LIDB SSN

- ISVM DPC

- ISVM SSN

- CNAM DPC

- CNAM SSN

- WSMSC DPC (for Local SMSs that support WSMSC data)

- WSMSC SSN (for Local SMSs that support WSMSC data)

- Download Reason

- Number Pool Block SV Type (for Local SMSs that support SV Type data)

- Alternative SPID (for Local SMSs that support Alternative SPID data)

• LRN-Download Data:

- LRN ID

- LRN Value

- Download Reason

R3-9     NPAC SMS download of network data to the Local SMS and SOA

NPAC SMS shall be able to communicate creation or deletion of NPA-NXX data and LRN data for a Service Provider to Local SMSs and SOAs.

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

RR3-66     Number Pool NPA-NXX-X Holder Information — NPAC SMS download of network data to the SOA or Local SMS

NPAC SMS shall be able to communicate creation, modification, or deletion of NPA-NXX-X data for a Service Provider to SOAs or Local SMSs. (Previously N-61)

The contents of the network download are:

• Network data:

- NPAC Customer ID

- NPAC Customer Name

• NPA-NXX-X Download Data:

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-29 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

- NPA-NXX-X ID

- NPA-NXX-X

- NPA-NXX-X Effective Date

- Last Modified TimeStamp

- Download Reason

RR3-67.1     Number Pool NPA-NXX-X Holder Information — NPAC SMS download via SOA and/or Local SMS Interface of NPA-NXX-X allocation to the Service Providers

NPAC SMS shall inform all Service Providers about the allocation of the NPA-NXX-Xs for pooling to the Block Holder via the SOA to NPAC SMS Interface and/or NPAC SMS to Local SMS interface. The NPA-NXX-X data fields sent via the SOA to NPAC SMS interface and/or NPAC SMS to Local SMS interface are: (Previously N-62.1)

• NPAC Customer ID

• NPAC Customer Name

• NPA-NXX-X ID

• NPA-NXX-X

• NPA-NXX-X Effective Date

• Creation TimeStamp

• Last Modified TimeStamp

• 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 and SOA to NPAC SMS interfaces or the Web bulletin board. The NPA-NXX data fields sent via the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces interface are:

• NPAC Customer ID

• 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 LRNs and Service Provider data by Service Provider

NPAC SMS shall inform all Service Providers about a new Service Provider and the associated LRNs via the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces. 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

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-30 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

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

• NPAC Customer ID

• NPAC Customer Name

• LRN Value

RR3-67.2     Number Pool NPA-NXX-X Holder Information — NPAC SMS download via Web Bulletin Board of NPA-NXX-X allocation to the Service Providers

NPAC SMS shall inform all Service Providers about the allocation of the NPA-NXX-Xs for pooling to the Block Holder via the Web bulletin board. The NPA-NXX-X data fields sent to the WEB bulletin board are: (Previously N-62.2)

• NPAC Customer ID

• NPAC Customer Name

• NPA-NXX-X

• NPA-NXX-X Effective Date

RR3-278     LATA ID Information Source

NPAC SMS shall obtain LATA ID information from an industry source. (Previously NANC 319 Req 1)

RR3-279     Association of LATA ID with NPA-NXXs

NPAC SMS shall associate a LATA ID with each NPA-NXX used by the NPAC SMS. (Previously NANC 319 Req 2)

RR3-280     Association of LATA ID with LRNs

NPAC SMS shall associate a LATA ID with each LRN used by the NPAC SMS. (Previously NANC 319 req 3)

RR3-439     Validation of LATA ID for NPA-NXX Creates

NPAC shall reject NPA-NXX Create requests if a valid LATA ID reference does not exist in the industry source data.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-31 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-440     Validation of LATA ID for LRN Creates

NPAC shall reject LRN Create requests if a valid LATA ID reference does not exist in the industry source data.

3.4 Additional Requirements

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

RX3-1.1.2     Service Provider NPA-NXX Data Effective Date Validation

NPAC SMS shall allow Service Providers to add their NPA-NXX data with an effective date that is set to a past, present, or future date.

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

RX3-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, Number Pooling NPA-NXX-X or Number Pooling Block Information.

RX3-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, or Number Pooling Block Information.

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 and/or SOA via the SOA to NPAC SMS interface.

RR3-2     Service Provider Download Indicator

NPAC SMS shall download NPA-NXX data and LRN data via the NPAC SMS to Local SMS Interface and/or the SOA to NPAC SMS interface if the indicator is ON.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-32 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

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.

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.

RR3-3     NPAC SMS Input Restrictions

NPAC SMS shall prevent the entry of pipe characters (|) as part of text strings.

RR3-4     Create LRN data for a Service Provider

NPAC SMS shall allow NPAC personnel to create a new LRN for a service provider.

RR3-15     NPAC Clock Synchronization

NPAC SMS shall synchronize its system clock using NTP to a Stratum 1 host.

RR3-474     NPA-NXX Availability — First Usage Effective Date Window — Tunable Parameter

NPAC SMS shall provide a First Usage Effective Date Window tunable parameter, which is defined as the minimum length of time between the current date (exclusive) and the effective date/due date (inclusive), when creating a NPA-NXX-X or Subscription Version for the first time within that NPA-NXX. (previously NANC 394, Req 1)

RR3-475     NPA-NXX Availability — First Usage Effective Date Window — Tunable Parameter Default

NPAC SMS shall default the First Usage Effective Date Window tunable parameter to five (5) business days. (previously NANC 394, Req 2)

Note: The value of five (5) business days is selected because of the first port notification, since this would affect SPs operationally if this value is set to less than five business days.

RR3-476     NPA-NXX Availability — First Usage Effective Date Window — Tunable Parameter Modification

NPAC SMS shall allow NPAC SMS Personnel, via the NPAC Administrative Interface, to modify the NPA-NXX Availability First Usage Effective Date Window tunable parameter. (previously NANC 394, Req 2.5)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-33 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-477     NPA-NXX— Live TimeStamp

NPAC SMS shall calculate an NPA-NXX Live TimeStamp for every NPA-NXX, which is the sum of the First Port Notification Broadcast TimeStamp (or the current system TimeStamp in cases where the first port notification has NOT been sent), plus the First Usage Effective Date Window tunable parameter. (previously NANC 394, Req 3)

Note: This is an internal TimeStamp, and therefore, not represented in the NPA-NXX Data Model.

RR3-478     Region Supports First Usage Effective Date Indicator

NPAC SMS shall provide a Region Supports First Usage Effective Date Indicator, which is defined as an indicator on whether or not First Usage Effective Date Window functionality will be supported by the NPAC SMS for a particular NPAC Region. (previously NANC 394, Req 8)

RR3-479     Region Supports First Usage Effective Date Modification

NPAC SMS shall provide a mechanism for NPAC Personnel to modify the Region Supports First Usage Effective Date Indicator. (previously NANC 394, Req 9)

RR3-480     Region Supports First Usage Effective Date Indicator — Default Value

NPAC SMS shall default the Region Supports First Usage Effective Date Indicator to TRUE. (previously NANC 394, Req 10)

3.4.1     NPA-NXX Data Validations

RR3-441     Valid NPAs for each NPAC Region

NPAC SMS shall establish a list of valid NPAs for each NPAC region using information obtained from an industry source. (previously NANC 321, Req1)

RR3-442     Maintaining List of Valid NPAs for Each NPAC Region

NPAC SMS shall maintain the list of valid NPAs for each NPAC region. (previously NANC 321, Req 2)

RR3-443     Updating List of Valid NPAs for Each NPAC Region

NPAC SMS shall update the list of valid NPAs for each NPAC region using information obtained from an industry source. (previously NANC 321, Req 3)

RR3-444     Rejection of NPA-NXXs that Do Not Belong to a Valid NPA for the NPAC Region

NPAC SMS shall reject a Service Provider request to open an NPA-NXX for portability if the associated NPA is not valid for the region. (previously NANC 321, Req 4)

Note: The 859 (Lexington, KY and surrounding area) exception needs to be correctly processed.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-34 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-445     Regional NPAC NPA Edit Flag Indicator

NPAC SMS shall provide a Regional NPA Edit Flag Indicator, which is defined as an indicator on whether or not NPA edits will be enforced by the NPAC SMS for a particular NPAC Region. (previously NANC 321, Req 5)

RR3-446     Regional NPAC NPA Edit Flag Indicator Modification

NPAC SMS shall provide a mechanism for NPAC Personnel to modify the Regional NPA Edit Flag Indicator. (previously NANC 321 Req 6)

RR3-447     Regional NPAC NPA Edit Flag Indicator — Default Value

NPAC SMS shall default the Regional NPA Edit Flag Indicator to TRUE. (previously NANC 321, Req 7)

RR3-448     Valid NPA-NXXs for 859 KY Exception

NPAC SMS shall establish a list of valid NPA-NXXs for the KY 859 NPA using information obtained from and industry source. (previously NANC 321, Req 8)

RR3-449     Maintaining List of Valid NPA-NXXs for 859 KY Exception

NPAC SMS shall maintain the list of valid NPA-NXXs for the KY 859 NPA. (previously NANC 321, Req 9)

RR3-450     Updating List of Valid NPAs for 859 KY Exception

NPAC SMS shall update the list of valid NPA-NXXs for the KY 859 NPA using information obtained from an industry source. (previously NANC 321, Req 10)

RR3-451     Rejection of NPA-NXXs that Do Not Belong to a Valid NPA for the 859 KY Exception

NPAC SMS shall reject a Service Provider request to open an NPA-NXX for portability if the associated 859-xxx NPA-NXX is not valid for the region as defined below:

• 859-xxx with LATA 922 may only be opened in the Midwest NPAC Region.

• 859-xxx with LATA OTHER THAN 922 may only be opened in the Southeast NPAC Region.

(previously NANC 321, Req 11)

3.5 NPA Splits Requirements

The following section defines NPA Split functionality within the NPAC SMS. The primary means of processing NPA Split information within the NPAC SMS is through automated and regular processing of NPA Split Load Flat Files from industry source data. In the event of an ‘emergency’ there is a manual process by which authorized NPAC personnel may enter required NPA Split information in order to initiate appropriate processing. This manual process is reserved for only ‘back-up or emergency’ situations as deemed by industry and NPAC representatives.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-35 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

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-NXX, except for query requests that span NPAs.

RN3-3     NPA Split Permissive Dialing Cleanup

NPAC SMS shall perform an update to remove NPAC SMS mapping of the old NPA-NXX(s) to the new NPA-NXX(s) for Subscription Versions associated with an NPA split after the expiration date of the permissive dialing period.

RR3-281     NPA Split — Load File from Industry Source Data

NPAC SMS shall allow an NPA Split Load Flat File from an industry source, to be used to enter, modify, or remove NPA Split information into/from the NPAC SMS. (Previously NANC 192 Req 1)

Note: The information from an industry source is assumed to include all necessary updates, including, but not limited to monthly plus emergency updates. (Previously NANC 192 Req 1)

RR3-282     NPA Split — Load File from Industry Source Data During Housekeeping Process

NPAC SMS shall allow the NPA Split Load Flat File to be loaded into the NPA Split information in the NPAC SMS during the current housekeeping process. (Previously NANC 192 Req 2)

RR3-283     NPA Split — Load File from Industry Source Data Processing Results

NPAC SMS shall be capable of storing NPA Split Load Flat File processing data that can be used to generate the NPA Split Load Flat File Exception Report. (Previously NANC 192 Req 3)

RR3-284     NPA Split — Load File from Industry Source Data, Reject existing new NPA-NXX

NPAC SMS shall process the NPA Split Load Flat File and for each new NPA split that is not yet scheduled in the NPAC SMS, reject the request, log an entry to be used for the NPA Split exception report, and continue processing the NPA Split Load Flat File, when the new NPA-NXX already exists in the NPAC SMS and is not already part of an NPA Split. (Previously NANC 192 Req 3.1)

RR3-285     NPA Split — Load File from Industry Source Data, Generate new NPA-NXX

NPAC SMS shall process the NPA Split Load Flat File and for each new NPA split that is not yet scheduled in the NPAC SMS, automatically generate and broadcast the new NPA-NXX, using the PDP start date/time as the value to populate the effective date for the new NPA-NXX. (Previously NANC 192 Req 3.2)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-36 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-286     NPA Split — Load File from Industry Source Data, Delete new NPA-NXX

NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is scheduled in the NPAC SMS and being removed as an NPA Split, automatically delete and broadcast the delete of the new NPA-NXX. (Previously NANC 192 Req 3.3)

RR3-287     NPA Split — NPA Split Load Flat File Exception Report with An Existing New NPA-NXX

NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA split processing errors:

1.	- NPA splits that cannot be added to the NPAC SMS because the new NPA-NXX already exists in the NPAC SMS at the time the NPA Split Load Flat File from an industry source is processed by the NPAC SMS, and that NPA-NXX is NOT already scheduled for an NPA Split in the NPAC SMS.
2.	- NPA splits already scheduled in the NPAC SMS where the PDP start date is modified, and pending SVs exist in the new NPA-NXX. (Previously NANC 192 Req 4)

RR3-288     NPA Split — Load File from Industry Source Data, Verifying Old and New NPA-NXX

NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, verify the old and new NPA-NXXs exist, and generate an error if at least one does not exist. (Previously NANC 192 Req 5)

RR3-289    | NPA Split — Load File from Industry Source Data, Pushing Out PDP Start Date

NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, check for an effective date change in the new NPA-NXX where the PDP start date is pushed out to a further date in the future, and if no pending subscription versions exist in the new NPA-NXX, update both the new NPA-NXX Effective Date and the PDP start date. (Previously NANC 192 Req 6)

Note: The update of the new NPA-NXX effective date will be accomplished via a delete and re-add of the new NPA-NXX. Both of these will be broadcast to all accepting SOAs and LSMSs.

RR3-290     NPA Split — Load File from Industry Source Data, Pulling In PDP Start Date

NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, check for an effective date change in the new NPA-NXX where the PDP start date is pulled in to a closer date, and if no pending subscription versions exist in the new NPA-NXX update both the new NPA-NXX Effective Date and PDP start date. (Previously NANC 192 Req 7)

Note: The update of the new NPA-NXX effective date will be accomplished via a delete and re-add of the new NPA-NXX. Both of these will be broadcast to all accepting SOAs and LSMSs.

RR3-291     NPA Split — Load File from Industry Source Data, Error Modifying PDP Start Date with Existing Subscription Versions

NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, check for an effective date change in the new NPA-NXX where the PDP start date is modified, and if pending subscription versions exist in the new NPA-NXX, perform no updates to the NPA Split or new NPA-NXX, and log an error. (Previously NANC 192 Req 8)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-37 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-292     NPA Split — Load File from Industry Source Data, Complete Processing of File

NPAC SMS shall process the NPA Split Load Flat File for each NPA split in the file, and shall NOT process any subsequent NPA Split Load Flat Files until the current file has been processed to completion, except in conditions where a subsequent file corrects an error in a previous file. (Previously NANC 192 Req 9)

RR3-293     NPA Split — Load File from Industry Source Data, Re-Processing of File

NPAC SMS shall be capable of re-processing the NPA Split Load Flat File in cases where the file was not completely processed due to NPA split processing errors, except in conditions where a subsequent file corrects an error in a previous file. (Previously NANC 192 Req 10)

RR3-294     NPA Split — Load File from Industry Source Data, Error Modifying PDP Start Date for NPA Split Already in Progress

NPAC SMS shall process the NPA Split Load Flat File for each NPA split in the file, and shall reject a modify PDP start date request, if the beginning of PDP has already passed for that NPA Split. (Previously NANC 192 Req 11)

RR3-295     NPA Split — Load File from Industry Source Data, Adding an NXX to an Existing Split

NPAC SMS shall process the NPA Split Load Flat File and for an NPA split that is already scheduled or in permissive dialing in the NPAC SMS, and an additional NXX is being added to the split, the NPAC SMS shall accept the addition of the NXX to the existing split. (Previously NANC 192 Req 12)

Note: The NPAC SMS will handle the additional split data appropriately (whether adding the NXX to the existing split, or creating a new split for the NPA-NXX), and maintain split data relationships between the existing split (NPA with different NXXs) and this newly added NXX (NPA with this new NXX), such that any subsequent actions on this split data will treat the relationship between all of the existing NPA-NXXs, and this newly added NXX, as part of the same split.

RR3-296     NPA Split — Load File from Industry Source Data Information on the Web

NPAC SMS shall inform all Service Providers about the processing of the NPA Split Load Flat File from industry source data via the Web bulletin board. The data field sent to the WEB bulletin board is the unique identifier for the file that is processed. (Previously NANC 192 Req 13)

Note: The Web will contain the latest full monthly file, plus the most recent incremental file.

AN3-4.1     NPA Split Information Source

The default information source for NPA Split processing shall be the NPA Split Load Flat File, which is processed automatically based on a housekeeping process.

AN3-4.2     NPAC Personnel Manual NPA Split Request

NPAC SMS shall support a mechanism by which NPAC Personnel may manually enter the required information to initiate NPA Split processing.

Note: Manual entry of NPA Split information by NPAC Personnel is available in ‘emergency’ situations as deemed by industry and NPAC representatives. Manual entry of NPA Split information is not the default method for initiating NPA Split processing on the NPAC SMS.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-38 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RN3-4.1     NPA Split — NPA-NXX existence prior to the NPA Split

NPAC SMS shall verify that only the old NPA-NXX(s) involved in an NPA Split exist when NPAC personnel manually enter the split information.

Note: When NPAC Personnel have to manually enter an NPA Split the New NPA-NXX(s) will automatically be broadcast to all accepting SOAs and LSMSs prior to the NPA Split.

RN3-4.2     NPA Split — New NPA-NXX existence prior to the NPA Split — Error

NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that the new NPA-NXX(s) involved in an NPA Split already exist(s) at the time of entry.

RR3-436     NPA Split —Old NPA-NXX non-existence prior to the NPA Split — Error

NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that the old NPA-NXX(s) involved in an NPA Split do(es) not already exist(s) at the time of entry.

RN3-4.3     NPA Split — NPA-NXX Effective Date Validation — DELETED

RR3-437     NPA Split — New NPA-NXX Creation

NPAC SMS shall automatically generate and broadcast the New NPA-NXX using the permissive dial period start date as the value to populate the effective date for the new NPA-NXX upon successful creation of the respective NPA Split information.

RN3-4.4     DELETED

RN3-4.5     DELETED

RN3-4.6     NPA Split — NPA-NXX involved in one NPA Split Validation

NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that a new NPA-NXX involved in an NPA Split is currently involved in another NPA Split.

RR3-297    NPA Split — NPA Split Load Flat File Exception Report with New NPA-NXX Already Involved in NPA Split

NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the new NPA-NXX is currently involved in another NPA Split. (Previously NANC 192 Req 16)

RN3-4.7    NPA Split — No Active Subscription Versions in the new NPA-NXX

NPA SMS shall verify that only pending, old, conflict, canceled, or cancel pending Subscription Versions exist in the new NPA-NXX involved in an NPA Split upon entering split information.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-39 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RN3-4.8     NPA Split — No Active Subscription Versions in the new NPA-NXX — Error

NPA SMS shall report an error and reject the NPA Split upon determining that there are Subscription Versions with a status other than pending, old, conflict, canceled, or cancel pending in the new NPA-NXX involved in an NPA Split.

RN3-4.9     NPA Split — Prevention of NPA-NXX Deletion

NPAC SMS shall prevent an old or new NPA-NXX involved in an NPA split from being deleted from the network data during permissive dialing.

RN3-4.11     NPA Split — No modification of LRN data

NPAC SMS shall leave the LRN information in Subscription Versions involved in the split unchanged during NPA split processing.

Note: The LRN data if necessary will be changed via mass update.

RN3-4.12     NPA Split — Exception Processing for Subscription Versions that exist in the New and Old NPA-NXX

NPAC SMS shall upon finding a subscription version that exists in the new NPA-NXX that currently exists in the old NPA-NXX during NPA split processing shall do the following and continue processing:

• log an error

• the Subscription Version in the new NPA-NXX will be moved to old if active or to canceled if it is in any pending state.

• the Subscription Version in the old NPA-NXX will be modified to the new NPA-NXX.

RN3-4.13     NPA Split — No Modification of Filter Data

NPAC SMS shall leave filters for NPA-NXX(s) involved in an NPA split unchanged.

Note: Service Providers are responsible for setting filters appropriately.

RN3-4.14     NPA Split — Audit Processing

NPAC SMS shall query the LSMS systems for the new NPA-NXX(s) when an audit is run during the NPA split permissive dialing period.

Note: It is the responsibility of the LSMS to recognize and return the new NPA-NXX in the subscription versions returned.

RN3-4.15     NPA Split — Entering of Split Data

The NPAC SMS shall require the following data for manual entry of NPA Split information into the NPAC:

• the Service Provider Id

• the old and new NPA

• the affected NXX(s)

• the start date of the permissive dialing period

• the end date of the permissive dialing period

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-40 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RN3-4.16     NPA Split — Modification of End Date of Permissive Dialing Date

NPAC SMS shall allow the modification of the end of permissive dialing during permissive dialing provided the date is not less than the current date.

RR3-438     NPA Split — Modification of Start Date of Permissive Dialing Date

NPAC SMS shall allow the modification of the permissive dial start date provided the modification is made prior to the scheduled permissive dial period start date and is modified to a date that is still prior to the permissive dial period end date.

RN3-4.17     NPA Split — Removal of NPA-NXX during Permissive Dialing

NPAC SMS shall allow the removal of an NPA-NXX during permissive dialing from the NPA Split information as an NPA-NXX involved in the NPA Split.

RN3-4.18     NPA Split — Removal of NPA-NXX during Permissive Dialing — Subscription Version Processing

NPAC SMS shall upon removal of an NPA-NXX during permissive dialing modify the TN of any subscription versions involved in a split existing in the new NPA-NXX to the old NPA-NXX. This processing includes subscription versions that did not previously exist prior to the NPA Split.

RN3-4.19     DELETED

RN3-4.20     NPA Split — Removal of NPA Split Information prior to NPA Split

NPAC SMS shall allow the removal of pending NPA Split information prior to the start of the permissive dialing period.

RN3-4.21     NPA Split — Removal of NPA Split Information after Permissive Dialing Period End Date

NPAC SMS shall log and remove NPA Split Information from the NPAC SMS at the end of the permissive dialing period.

RN3-4.22     NPA Split — No Broadcast of Subscription Version Modification

NPAC SMS shall broadcast no information to the SOA(s) or LSMS(s) about the creation, modification, or deletion of Subscription Versions due to NPA Split processing on the NPAC SMS.

Note: The LSMS and SOA systems are responsible for creating, deleting, or modifying subscription versions due to an NPA Split.

RN3-4.23     NPA Split — Retention of Subscription Version Id

NPAC SMS shall retain the Subscription Version Id of the Subscription Versions involved in an NPA Split.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-41 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RN3-4.24     NPA Split — Update of Subscription Versions at the Beginning of Permissive Dialing

NPAC SMS shall update all Subscription Versions with a status other than old or canceled with the new NPA at the beginning of the Permissive Dialing Period.

RN3-4.25     NPA Split — Old NPA-NXX involved in one NPA Split Validation

NPAC SMS shall verify that the old NPA-NXX(s) involved in an NPA Split are not currently involved in another NPA Split when NPAC personnel manually enter the NPA split information or the NPA Split Load Flat File is processed.

RN3-4.26     NPA Split — Old NPA-NXX involved in one NPA Split Validation — Error

NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that an old NPA-NXX involved in an NPA Split is currently involved in another NPA Split.

RR3-298     NPA Split — NPA Split Load Flat File Exception Report with Old NPA-NXX Already Involved in NPA Split

NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the old NPA-NXX is currently involved in another NPA Split. (Previously NANC 192 Req 17)

RN3-4.27     NPA Split — Validation of the Permissive Dialing Period

NPAC SMS shall verify that the end date of permissive dialing is greater than the start date except in cases where there is no permissive dialing period.

RN3-4.28     NPA Split — Old NPA-NXX and New NPA-NXX Ownership Validation

NPAC SMS shall verify that the owner of the old NPA-NXX matches the owner of the new NPA-NXX for each NXX in a NPA split.

RN3-4.29     NPA Split — Old NPA-NXX and New NPA-NXX Ownership Validation — Error — DELETED

RR3-299     NPA Split — NPA Split Load Flat File Exception Report with Mismatched SPIDs for Old and New NPA-NXX

NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the owner of the old NPA-NXX does not match the owner of the new NPA-NXX. (Previously NANC 192 Req 18)

RN3-4.30     NPA Split — Creation of a Subscription Version during the Permissive Dialing Period

NPAC SMS shall change the old NPA-NXX to the new NPA-NXX when a Subscription Version is created with the old NPA-NXX during the permissive dialing period.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-42 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RN3-4.31     NPA Split Current and Pending NPA Split Report

NPAC SMS shall support a Current and Pending NPA Split Report for NPA Splits before or during their permissive dialing period that contains all split data as defined in RN3-4.15.

RN3-4.32     NPA Split — NPA Split History Report

NPAC SMS shall support a NPA Split History Report for completed NPA Splits that contains all split data as defined in RN3-4.15.

RN3-4.33     DELETED

RN3-4.34     DELETED

RN3-4.35     DELETED

RN3-4.36     NPA Split -Creation of Old Subscription Version

DELETED

RN3-4.37     NPA Split — Old Subscription Version No Broadcast

DELETED

RR3-219     NPA Splits — Deletion of Old NPA-NXX at the end of permissive dialing

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.

3.5.1 NPA-NXX-X, NPA Splits

RR3-31     NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split Automatic Create of New NPA-NXX-X

NPAC SMS shall automatically create a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, when a valid request is made to add an NPA Split, if the old NPA-NXX-X exists, but the new NPA-NXX-X does NOT exist in the Number Pooling NPA-NXX-X Information. (Previously N-300)

RR3-32     NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split Error Message if New NPA-NXX-X Already Exists

NPAC SMS shall reject the request and generate an error message when a request is made to add an NPA Split, and the new NPA-NXX-X already exists in the Number Pooling NPA-NXX-X Information. (Previously N-301)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-43 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-300     NPA Split — NPA Split Load Flat File Exception Report with Already Existing New NPA-NXX-X

NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the new NPA-NXX-X already exists in the Number Pooling NPA-NXX-X Information. (Previously NANC 192 Req 19)

RR3-33     NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split Field Values for Automatic Add of New NPA-NXX-X

NPAC SMS shall populate the fields for the automatically generated new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, when a request is made to add an NPA Split or an old NPA-NXX-X is created during a split, as follows: (Previously N-302)

• NPA-NXX-X ID — value automatically generated by NPAC.

• NPA-NXX-X Holder SPID — value set to old NPA-NXX-X.

• NPA-NXX-X — value set to the new NPA-NXX, plus the seventh digit of the old NPA-NXX-X.

• Effective Date — value set to the latest of, the same field in old NPA-NXX-X, or the start of PDP.

• Creation Date — value set to current date/time.

• Last Modified Date — value set to current date/time.

• Download Reason — value set to “new1”.

RR3-34     NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split, Skip Block and Subscription Version Create

NPAC SMS shall NOT schedule the Creation of a Block and Subscription Versions with LNP Type of POOL, for an NPA-NXX-X that is automatically generated by the NPAC SMS in the Number Pooling NPA-NXX-X Information, as a result of a request to add an NPA Split. (Previously N-303)

Note: The Block and SVs will be created at PDP Start based on Block and SV split requirements.

RR3-35     NPA Splits and the Number Pool NPA-NXX-X Information — NXX Removal from NPA Split prior to the end of PDP

NPAC SMS shall upon the removal of an NPA-NXX from an NPA Split prior to the end of permissive dialing, remove the new NPA-NXX-X from the NPA-NXX-X Information. (Previously N-310)

RR3-36.1     NPA Splits and the Number Pool NPA-NXX-X Information — Addition of an NPA-NXX-X scheduled for an NPA Split

NPAC SMS shall, upon entry of an old NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically add an entry for the new NPA-NXX-X for an NPA-NXX scheduled for an NPA Split. (Previously N-320.1)

RR3-36.2     NPA Splits and the Number Pool NPA-NXX-X Information — New Addition of an NPA-NXX-X scheduled for an NPA Split With an Error Message

NPAC SMS shall reject the request and generate an error message to the NPAC Personnel when a request is made to add a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, and the NPA-NXX is scheduled for an NPA Split. (Previously N-320.2)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-44 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-36.3     NPA Splits and the Number Pool NPA-NXX-X Information — Addition of an NPA-NXX-X currently in Permissive Dialing in an NPA Split

NPAC SMS shall, upon entry of an NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically add an entry for the new/old NPA-NXX-X for an NPA-NXX currently in Permissive Dialing in an NPA Split. (Previously N-320.3)

Note: Therefore, if entering the new NPA-NXX-X, then the old NPA-NXX-X will be automatically added; and if entering the old NPA-NXX-X, then the new NPA-NXX-X will be automatically added.

RR3-37.1     NPA Splits and the Number Pool NPA-NXX-X Information — Modification of an NPA-NXX-X scheduled for an NPA Split

NPAC SMS shall, upon modification of an old NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically modify the corresponding entry for the new NPA-NXX-X for an NPA-NXX scheduled for an NPA Split, if the new Effective Date is Greater Than or Equal To the start of the Permissive Dialing Period. If the modified Effective Date value is Less Than the start of the Permissive Dialing Period, then the new NPA-NXX-X’s Effective Date is Equal To the start of the Permissive Dialing Period. (Previously N-321.1)

RR3-37.2     NPA Splits and the Number Pool NPA-NXX-X Information — New Modification of an NPA-NXX-X scheduled for an NPA Split With an Error Message

NPAC SMS shall reject the request and generate an error message to the NPAC Personnel when a request is made to modify a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, and the NPA-NXX is scheduled for an NPA Split. (Previously N-321.2)

RR3-37.3     NPA Splits and the Number Pool NPA-NXX-X Information — Modification of an NPA-NXX-X involved in an NPA Split

NPAC SMS shall, upon modification of an NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically modify the old/new NPA-NXX-X for an NPA-NXX currently in Permissive Dialing in an NPA Split.

Note: Therefore, if modifying the new NPA-NXX-X, then the old NPA-NXX-X will be automatically modified; and if modifying the old NPA-NXX-X, then the new NPA-NXX-X will be automatically modified. (Previously N-321.3)

RR3-38.1     NPA Splits and the Number Pool NPA-NXX-X Information — Deletion of an NPA-NXX-X involved in an NPA Split

NPAC SMS shall, upon de-pooling of an old NPA-NXX-X in the Number Pooling NPA-NXX-X Information, prior to the start of the Permissive Dialing Period, automatically de-pool the corresponding entry for the new NPA-NXX-X for an NPA-NXX scheduled for an NPA Split, at the time the requested NPA-NXX-X is de-pooled. (Previously N-322.1)

RR3-38.2     NPA Splits and the Number Pool NPA-NXX-X Information — New Deletion of an NPA-NXX-X scheduled for an NPA Split With an Error Message

NPAC SMS shall reject the request and generate an error message to the NPAC Personnel when a request is made to de-pool a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, and the NPA-NXX is scheduled for an NPA Split. (Previously N-322.2)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	3-45	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-38.3     NPA Splits and the Number Pool NPA-NXX-X Information — Deletion of an NPA-NXX-X involved in an NPA Split

NPAC SMS shall, upon de-pool of an NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically de-pool the old/new NPA-NXX-X for an NPA-NXX currently in Permissive Dialing in an NPA Split, at the time the requested NPA-NXX-X is de-pooled.

Note: Therefore, if de-pooling the new NPA-NXX-X, then the old NPA-NXX-X will be automatically de-pooled; and if de-pooling the old NPA-NXX-X, then the new NPA-NXX-X will be automatically de-pooled. (Previously N-322.3)

RR3-39     NPA Splits and the Number Pool NPA-NXX-X Information — Broadcast of Addition or Deletion of NPA-NXX-X Split Data

NPAC SMS shall broadcast NPA-NXX-X data defined in RR3-31, RR3-35, RR3-36.1, RR3-36.3, RR3-37.1, RR3-37.3, RR3-38.1, and RR3-38.3, that is added or deleted for an NPA Split; this broadcast shall occur as defined in requirements RR3-66, RR3-67.1, RR3-67.2, RR3-68, RR3-69, RR3-70, RR3-71, RR3-72 and RR3-73. (Previously N-325)

RR3-40     NPA Splits and the Number Pool NPA-NXX-X Information — Deletion of Old NPA-NXX-X at the end of permissive dialing

NPAC SMS shall automatically delete the old NPA-NXX-X from the Number Pooling NPA-NXX-X Information, upon reaching the end of the permissive dialing period for the old NPA-NXX of the NPA-NXX-X. (Previously N-326)

3.5.2 Block Holder, NPA Splits

RR3-41     NPA Splits and the Number Pooling Block Holder Information — Recognition of Both Old NPA and New NPA

NPAC SMS shall upon the start of permissive dialing for an NPA Split, convert the old NPA-NXX to the new NPA-NXX in the Number Pooling Block Information. (Previously B-490)

RR3-42     NPA Splits and the Number Pooling Block Holder Information — NXX Removal from Split

NPAC SMS shall upon the removal of an NPA-NXX from an NPA Split, after the start of permissive dialing, reinstate the original NPA for the NXX-X in the Block Holder Information. (Previously B-500)

RR3-43     NPA Splits and the Number Pool Block Holder Information — Addition of a Block involved in an NPA Split

NPAC SMS shall convert the old NPA-NXX to the new NPA-NXX for a Block involved in an NPA Split upon creation in the Number Pooling Block Holder Information, if the old NPA-NXX is currently in permissive dialing. (Previously B-510)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-46 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-44     NPA Splits and the Number Pool Block Holder Information — Addition of a Block for an NPA-NXX involved in an NPA Split

NPAC SMS shall accept a Block create request from NPAC personnel, Service Provider via the SOA to NPAC SMS Interface or Service Provider via the NPAC SOA Low-tech Interface, with either the old NPA-NXX or the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-520)

RR3-45     NPA Splits and the Number Pool Block Holder Information — Broadcast of a Block Create for an NPA-NXX involved in an NPA Split

NPAC SMS shall broadcast a Block create to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, by sending a Block using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-530)

RR3-46     NPA Splits and the Number Pool Block Holder Information — Modification of a Block for an NPA-NXX involved in an NPA Split

NPAC SMS shall accept a Block modify active request from NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, with either the old NPA-NXX or the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-540)

RR3-47     NPA Splits and the Number Pool Block Holder Information — Broadcast of a Block Modify Active for an NPA-NXX involved in an NPA Split

NPAC SMS shall broadcast a Block modify active to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, by sending a Block using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-550)

RR3-48     NPA Splits and the Number Pool Block Holder Information — De-pooling of the Block during PDP

NPAC SMS shall broadcast a Block delete request to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, by sending a Block using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-551)

RR3-49     NPA Splits and the Number Pool Block Holder Information — Mass Update that includes one or more Blocks for an NPA-NXX involved in an NPA Split

NPAC SMS shall accept a mass update request from NPAC personnel that spans one or more Blocks that are part of an NPA Split that is currently in permissive dialing only when the new NPA-NXX is used.

RR3-50     NPA Splits and the Number Pool Block Holder Information — Broadcast of a Mass Update that includes one or more Blocks for an NPA-NXX involved in an NPA Split

NPAC SMS shall broadcast a mass update that could span one or more Blocks to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-553)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-47 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-51.1     NPA Splits and the Number Pool Block Holder Information — Creation of Old Block

DELETED

RR3-51.2     NPA Splits and the Number Pool Block Holder Information — Old Block No Broadcast

DELETED

RR3-218     NPA Splits and the Number Pool Block Holder Information — Broadcast of Subscription Versions for an NPA-NXX involved in an NPA Split

NPAC SMS shall broadcast the Subscription Versions with LNP Type of POOL using the new NPA-NXX, for an addition, modification, deletion, re-send, resync, or mass update, to a non-EDR Local SMS, via the NPAC SMS to Local SMS Interface, for an NPA-NXX that is currently in permissive dialing. (Previously SV-430)

3.6 NPA-NXX Filter Management Requirements

RR3-5     Create Filtered NPA-NXX for a Local SMS

NPAC SMS shall allow a Service Provider to create a filtered NPA-NXX for a given Local SMS, via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface, which results in the SMS NOT broadcasting NPA-NXX information, subscription versions, NPA-NXX-X information or Number Pool Blocks with the filtered NPA-NXX to the Local SMS.

RR3-6     Delete Filtered NPA-NXX for a Local SMS

NPAC SMS shall allow a Service Provider to delete a filtered NPA-NXX for a given Local SMS, via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface, which results in the SMS broadcasting NPA-NXX information, subscription versions, NPA-NXX-X information and Number Pool Blocks with the filtered NPA-NXX to the given Local SMS.

RR3-7     Query Filtered NPA-NXXs for a Local SMS

NPAC SMS shall allow a Service Provider to query filtered NPA-NXXs for a given Local SMS via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface.

RR3-8     Query Filtered NPA-NXXs — NPA-NXX Not Provided

NPAC SMS shall return to the requesting Service Provider all filtered NPA-NXXs for a given Local SMS when the NPA-NXX is NOT input upon a Filter NPA-NXX Query via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface.

RR3-9     Query Filtered NPA-NXXs — NPA-NXX Provided

NPAC SMS shall return to the requesting Service Provider a single NPA-NXX for a given Local SMS when the NPA-NXX is input upon a filtered NPA-NXX Query via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-48 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.7 Business Hour and Days Requirements

RR3-10     Business Hours and Days

NPAC SMS shall support definition and processing of long and short business hours and days for operations involving business time calculation.

RR3-11

DELETED

RR3-30

DELETED

RR3-229     Short Business Days Tunable Parameter

NPAC SMS shall provide a Short Business Days tunable parameter that defines the days of the week that are valid for operations involving business time calculation excluding NPAC operations-defined holidays. (Formerly NANC 328 Req 5)

RR3-230     Short Business Days Tunable Parameter — Default Value

NPAC SMS shall default the Short Business Days tunable parameter to Monday through Friday. (Formerly NANC 328 Req 6)

RR3-231     Short Business Days Tunable Parameter — Valid Values

NPAC SMS shall use days of the week as valid values for the Short Business Days tunable parameter. (Formerly NANC 328 Req 7)

RR3-232     Short Business Days Tunable Parameter — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface to modify the Short Business Days Tunable Parameter. (Formerly NANC 328 Req 8)

RR3-233     Long Business Days Tunable Parameter

NPAC SMS shall provide a Long Business Days tunable parameter that defines the days of the week that are valid for operations involving business time calculation excluding NPAC operations-defined holidays. (Formerly NANC 328 Req 1)

RR3-234     Long Business Days Tunable Parameter — Default Value

NPAC SMS shall default the Long Business Days tunable parameter to Sunday through Saturday. (Formerly NANC 328 Req 2)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-49 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-235     Long Business Days Tunable Parameter — Valid Values

NPAC SMS shall use days of the week as valid values for the Long Business Days tunable parameter. (Formerly NANC 328 Req 3)

RR3-236     Long Business Days Tunable Parameter — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Long Business Days Tunable Parameter. (Formerly NANC 328 Req 4)

RR3-12.1     Business Day Duration — Tunable Parameter

NPAC SMS shall provide long and short Business Day Duration tunable parameters, which are defined as the number of hours from the tunable business day start time.

RR3-12.2     Business Day Duration — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Business Day Duration tunable parameters.

RR3-12.3     Short Business Day Duration — Tunable Parameter Default

NPAC SMS shall default the short Business Day Duration tunable parameter to 12 hours.

RR3-12.4     Long Business Day Duration — Tunable Parameter Default

NPAC SMS shall default the long Business Day Duration tunable parameter to 12 hours.

RR3-13.1     Business Day Start Time — Tunable Parameter

NPAC SMS shall provide long and short Business Day Start Time tunable parameters, which are defined as the start of the business day in local time of the predominant time zone within the region (stored in UTC).

RR3-13.2     Business Day Start Time — Tunable Parameter Modification

NPAC SMS shall set the long and short Business Day Start Time tunable parameters to the value specified by the contracting region.

RR3-13.3     Short Business Day Start Time — Tunable Parameter Default

NPAC SMS shall default the short Business Day Start Time tunable parameter to 13:00/12:00 UTC (adjusted for Standard/Daylight time changes).

RR3-13.4     Long Business Day Start Time — Tunable Parameter Default

NPAC SMS shall default the long Business Day Start Time tunable parameter to 9:00 AM local time of the predominant time zone within the region, stored in UTC and adjusted for Standard/Daylight time changes.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-50 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-14     Business Holidays

NPAC SMS shall allow NPAC operations personnel to add/delete business holidays.

3.8 Notifications

3.8.1     TN Range Notification Indicator

RR3-237     NPAC Customer TN Range Notification Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving TN Range Notifications via the SOA to NPAC SMS Interface. (Formerly NANC 179 Req 1)

RR3-238     NPAC Customer TN Range Notification Indicator — Default

NPAC SMS shall default the TN Range Notification Indicator to FALSE. (Formerly NANC 179 Req 2)

RR3-239     NPAC Customer TN Range Notification Indicator — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the TN Range Notification Indicator on the NPAC Customer record. (Formerly NANC 179 Req 3)

3.8.2     Customer No New SP Concurrence Notification Indicator

RR3-240     NPAC Customer No New SP Concurrence Notification Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports the Final Create Window Expiration Notification for a Subscription Version upon the expiration of the New Service Provider Final Create Window. (Formerly NANC 240 Req 3)

RR3-241     NPAC Customer No New SP Concurrence Notification Indicator — Default

NPAC SMS shall default the No New SP Concurrence Notification Indicator to FALSE. (Formerly NANC 240 Req 4)

RR3-242     NPAC Customer No New SP Concurrence Notification Indicator — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the No New SP Concurrence Notification Indicator on the NPAC Customer record. (Formerly NANC 240 Req 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-51 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-243     Subscription Version Information — Suppress Notification when Service Provider No New SP Concurrence Notification Indicator is False

NPAC SMS shall suppress the Final Create Window Expiration Notification, if the Service Provider’s No New SP Concurrence Notification Indicator is FALSE. (Formerly NANC 240 Req 6)

RR3-244     Subscription Version Information — Send Notification when Service Provider No New SP Concurrence Notification Indicator is True

NPAC SMS shall send the Final Create Window Expiration Notification, if the Service Provider’s No New SP Concurrence Notification Indicator is TRUE. (Formerly NANC 240 Req 7)

3.8.3   SOA Notification Priority

RR3-245     SOA Notification Priority Tunable Parameter

NPAC SMS shall provide a SOA Notification Priority tunable parameter for each SOA notification that defines the priority of the SOA notification for the given region. (Formerly NANC 329 Req 1)

RR3-246     SOA Notification Priority Based on Attributes

NPAC SMS shall allow SOA Notifications to have separate priorities associated with the value of certain attributes based on the information contained in Appendix C, Table C-7 — SOA Notification Priority Tunables. (Formerly NANC 329 Req 2)

Note: The table referenced above is new and is appended to this document.

RR3-247     SOA Notification Priority Tunable Parameter based on Old or New Service Provider Status

NPAC SMS shall allow different SOA Notification Priority values for Status Attribute Value Change notifications based on whether the Service Provider is acting as the Old Service Provider or as New Service Provider for the port as indicated in Appendix C, Table C-7 — SOA Notification Priority Tunables. (Formerly NANC 329 Req 6)

RR3-248     SOA Notification Priority Tunable Parameter — Valid Values

NPAC SMS shall use HIGH, MEDIUM, LOW, and NONE as valid values for the SOA Notification Priority tunable parameters. (Formerly NANC 329 Req 3)

RR3-249     SOA Notification Priority Tunable Parameter — Default Value

NPAC SMS shall default the SOA Notification Priority tunable parameter values to MEDIUM. (Formerly NANC 329 Req 4)

RR3-250     Modifying the SOA Notification Priority Tunable Parameter Value

NPAC SMS shall allow NPAC Personnel to modify the SOA Notification Priority tunable parameter values based on Service Provider requests. (Formerly NANC 329 Req 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-52 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-251     SOA Notification Priority Processing

NPAC SMS shall send HIGH priority messages prior to sending MEDIUM priority messages and MEDIUM priority messages prior to LOW priority messages. (Formerly NANC 329 Req 3.5)

RR3-252     SOA Notification Priority Tunable Parameter —Value Equal to NONE

NPAC SMS shall use the SOA Notification Priority tunable parameter equal to NONE to indicate that the notification is not generated for that Service Provider. (Formerly NANC 329 Req 7)

RR3-253     Processing of SOA Notification Queues

NPAC SMS shall send SOA notifications to a Service Provider based on the SOA notification priority and ‘first in, first out’ within the priority. (Formerly NANC 329 Req 8)

3.8.4 TN and Number Pool Block in Notifications

RR3-452     Subscription Version Status Attribute Value Change — Send TN

NPAC SMS shall, based on the Subscription Version TN Attribute Flag Indicator, send the Subscription Version TN when sending a Subscription Version Status Attribute Value Change notification. (previously NANC 151, Req 1)

RR3-453     Subscription Version Attribute Value Change — Send TN

NPAC SMS shall, based on the Subscription Version TN Attribute Flag Indicator, send the Subscription Version TN when sending a Subscription Version Attribute Value Change notification. (previously NANC 151, Req 2)

RR3-454     Number Pool Block Status Attribute Value Change — Send NPA-NXX-X

NPAC SMS shall, based on the Number Pool Block NPA-NXX-X Attribute Flag Indicator, send the Number Pool Block NPA-NXX-X when sending a Number Pool Block Status Attribute Value Change notification. (previously NANC 151, Req 3)

RR3-455     Number Pool Block Attribute Value Change — Send NPA-NXX-X

NPAC SMS shall, based on the Number Pool Block NPA-NXX-X Attribute Flag Indicator, send the Number Pool Block NPA-NXX-X when sending a Number Pool Block Attribute Value Change notification. (previously NANC 151, Req 4)

RR3-456     Subscription Version TN Attribute Flag Indicator

NPAC SMS shall provide a Subscription Version TN Attribute Flag Indicator, which is defined as an indicator on whether or not the Service Provider supports receipt of the Subscription Version TN attribute in a Subscription Version Status Attribute Value Change or Attribute Value Change notification. (previously NANC 151, Req 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-53 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-457     Modification of Subscription Version TN Attribute Flag Indicator

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the Subscription Version TN Attribute Flag Indicator. (previously NANC 151, Req 6)

RR3-458     Subscription Version TN Attribute Flag Indicator Default Value

NPAC SMS shall default the Subscription Version TN Attribute Flag Indicator to FALSE. (previously NANC 151, Req 7)

RR3-459     Number Pool Block NPA-NXX-X Attribute Flag Indicator

NPAC SMS shall provide a Number Pool Block NPA-NXX-X Attribute Flag Indicator, which is defined as an indicator on whether or not the Service Provider supports receipt of the Number Pool Block NPA-NXX-X attribute in a Number Pool Block Status Attribute Value Change or Attribute Value Change notification. (previously NANC 151, Req 8)

RR3-460     Modification of Number Pool Block NPA-NXX-X Attribute Flag Indicator

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the Number Pool Block NPA-NXX-X Attribute Flag Indicator. (previously NANC 151, Req 9)

RR3-461     Number Pool Block NPA-NXX-X Attribute Flag Indicator Default Value

NPAC SMS shall default the Number Pool Block NPA-NXX-X Attribute flag Indicator to FALSE. (previously NANC 151, Req 10)

3.8.5 SV Type and Alternative SPID Indicators

The following section of requirements defines service provider tunable features that indicate if a service provider system supports optional data functionality defined as part of NANC 399. Until NAPM LLC approval, this functionality remains inactive in the NPAC SMS.

RR3-484     Service Provider SOA SV Type Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA SV Type Edit Flag Indicator tunable parameter which defines whether a SOA supports SV Type. (previously NANC 399, Req 1)

RR3-485     Service Provider SOA SV Type Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA SV Type Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 2)

RR3-486     Service Provider SOA SV Type Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SV Type Edit Flag Indicator tunable parameter. (previously NANC 399, Req 3)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-54 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-487     Service Provider LSMS SV Type Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS SV Type Edit Flag Indicator tunable parameter which defines whether an LSMS supports SV Type. (previously NANC 399, Req 4)

RR3-488     Service Provider LSMS SV Type Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS SV Type Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399,
Req 5)

RR3-489     Service Provider LSMS SV Type Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SV Type Edit Flag Indicator tunable parameter. (previously NANC 399, Req 6)

RR3-490     Service Provider SOA Alternative SPID Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA Alternative SPID Edit Flag Indicator tunable parameter which defines whether a SOA supports Alternative SPID. (previously NANC 399, Req 7)

RR3-491     Service Provider SOA Alternative SPID Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA Alternative SPID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 8)

RR3-492     Service Provider SOA Alternative SPID Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Alternative SPID Edit Flag Indicator tunable parameter. (previously NANC 399, Req 9)

RR3-493     Service Provider LSMS Alternative SPID Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS Alternative SPID Edit Flag Indicator tunable parameter which defines whether an LSMS supports Alternative SPID. (previously NANC 399, Req 10)

RR3-494     Service Provider LSMS Alternative SPID Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS Alternative SPID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 11)

RR3-495     Service Provider LSMS Alternative SPID Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Alternative SPID Edit Flag Indicator tunable parameter. (previously NANC 399, Req 12)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-55 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.9 Multiple Service Provider Ids Per SOA Association Requirements

RR3-16     Addition of NPAC Customer Associated Service Provider Information

NPAC SMS shall allow NPAC personnel to store a primary service provider id with the associated service provider id that it will service.

RR3-17     Deletion of NPAC Customer Associated Service Provider Information

NPAC SMS shall allow NPAC personnel to delete an associated service provider id that is serviced by a primary service provider id.

RR3-18     NPAC Customer Associated Service Provider Information — SPID validation

NPAC SMS shall validate that the primary and associated service provider ids specified in the NPAC Customer Associated Service Provider Information are valid service provider ids defined in the NPAC SMS.

RR3-19     NPAC Customer Associated Service Provider Information — Associated SPID

NPAC SMS shall validate that the associated service provider id is not already specified as a primary or associated service provider id in the NPAC Customer Associated Service Provider Information.

A3-5     Associated Service Provider Multiple Service Provider Ids

Associated service providers using services from another primary service provider’s SOA must use another service provider id if they choose to interact with the NPAC independently from the primary service provider.

RR3-20     NPAC Customer Associated Service Provider Information — Validation Error

NPAC SMS shall report an error to the user and reject the addition of NPAC Customer Associated Service Provider Information if validation errors occur.

RR3-21     NPAC Deletion of Service Provider Validation

NPAC SMS shall prevent a service provider from being deleted in the NPAC SMS if it exists in the NPAC Customer Associated Service Provider Information as a primary or associated service provider id.

RR3-22     Association Rejection for Associated Service Provider Id

NPAC SMS shall reject any SOA to NPAC SMS association attempt by a Service Provider Id that is a service provider associated with the primary Service Provider Id in the NPAC Customer Associated Service Provider Information.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-56 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-23     Associated Service Provider Id Use over a Primary Service Provider Id Association

NPAC SMS shall support the specification of an associated service provider id in the access control field over a SOA to NPAC SMS association for the primary service provider provided the associated service provider id is defined in the NPAC Associated Service Provider Information for the primary service provider id.

RR3-24     Validation of Old and New/Current for Associated Service Provider Id

NPAC SMS shall validate the old and new/current service provider id for a message sent over the SOA to NPAC SMS association for the primary association as is done today using the service provider id specified in the access control for the message.

RR3-25     Use of Primary Service Provider Key List

NPAC SMS shall accept and send keys from the key lists associated with the primary service provider for all SOA to NPAC SMS messages sent over the association for the primary service provider.

RR3-26     Notifications for Associated Service Providers

NPAC SMS shall send all SOA notifications for an associated Service Provider over the SOA to NPAC SMS interface association for the primary service provider.

C3-1     Associated Service Provider Notification Aggregation

NPAC SMS aggregation of all messages over the SOA to NPAC SMS interface for primary and associated service provider ids will not be supported by the NPAC SMS.

RR3-27     Filters for Associated Service Providers

NPAC SMS shall apply NPA-NXX filters for the associated Service Provider Id before sending them over the SOA to NPAC SMS interface association for the primary service provider.

RR3-28     Associated Service Provider and Primary Service Provider messages

NPAC SMS shall support messages containing primary and associated service provider ids that are interleaved over the SOA to NPAC SMS interface association for the primary service provider.

RR3-29     Recovery for an Associated Service Provider

NPAC SMS shall support the recovery of network data or notifications for an associated Service Provider over a SOA to NPAC SMS association in recovery mode for a primary service provider.

Note: Recovery of information for associated service providers is the responsibility of the primary service provider. The primary service provider must establish an association in recovery mode, send the recovery actions for each service provider id, primary and associated, and then as the primary SPID indicate recovery is complete.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-57 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.10 Bulk Data Download Functionality

This section describes Bulk Data Download functionality supported by the NPAC SMS. The NPAC can generate files for Network Data (including SPID, LRN, NPA-NXX and NPA-NXX-X), and Subscription Versions (including Number Pool Blocks). The NPAC SMS also has the ability to process Bulk Data Download Response files from Service Providers.

3.10.1 Bulk Data Download Functionality — General

RR3-220     Bulk Data Download File Creation

NPAC SMS shall provide a mechanism that allows a Service Provider to recover network data, notification data and subscription data in file format.

RR3-221     Bulk Data Download — File Naming Convention

NPAC SMS shall follow the file naming convention as described in Appendix E.

RR3-222     Bulk Data Download — File Format

NPAC SMS shall follow the file format as described in Appendix E.

RR3-223     Bulk Data Download — Selection Criteria for File Creation

NPAC SMS shall allow network data only, subscription data only, notification data only, or all, as selection criteria for bulk data download file generation.

3.10.2 Network Data, Bulk Data Download

RR3-224     Bulk Data Download — Required Selection Criteria for Network Data File Generation

NPAC SMS shall require, as selection criteria for network bulk data download file generation, a Service Provider filter of either a single Service Provider ID or ‘All Service Providers’.

RR3-301     Network Data Information Bulk Download File Creation — Selection Criteria

NPAC SMS shall include the Requesting Service Provider, All Network Data or Latest View of Network Data Activity Choice, and Time Range as Selection Criteria fields for the Network Data bulk data download files via the NPAC Administrative Interface. (Previously NANC 354
Req 2)

RR3-302     Network Data Information Bulk Download File Creation — All Network Data or Latest View of Network Data Activity Choice

NPAC SMS shall allow NPAC Personnel to select either All Network Data or Latest View of Network Data Activity, and shall use the selected choice, for Network Data. (Previously NANC 354 Req 3)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-58 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-303     Network Data Information Bulk Download File Creation — Data in All Network Data Choice

NPAC SMS shall use the All Network Data selection to include all Network Data in the Network Data Bulk Data Download files. (Previously NANC 354 Req 4)

RR3-304     Network Data Information Bulk Download File Creation — Data in Latest View of Network Data Activity Choice

NPAC SMS shall use the Latest View of Network Data Activity selection to include all Network Data, in order to capture activation, modification (NPA-NXX-X only), and deletion transactions for Network Data, but only include the latest instance of the Network Data in the Network Data Bulk Data Download files, when Network Data has more than one activity (e.g., addition, then modification of an NPA-NXX-X) within the specified time range. (Previously NANC 354 Req 5)

Note: The format of the BDD file doesn’t change based on the status of the Network Data but some of the fields may be blank. Example: Creates and modifies would have all the attributes specified but disconnect and deletes would have many fields null.

RR3-305     Network Data Information Bulk Download File Creation — Time Range Fields

NPAC SMS shall use the Start Time Range entry field as an inclusive start range, and the End Time Range entry field as an inclusive end range, for Network Data data that were broadcast during the specified Time Range. (Previously NANC 354 Req 6)

Note: The NPAC Administrative Interface is settable for the GUI user’s local time (e.g., a USA in Sterling will have the local time set to Eastern Time). M&Ps will be established to determine the correct time range on the request of the BDD file.

RR3-306     Network Data Information Bulk Download File Creation — Time Range Fields and Network Data Data Model

NPAC SMS shall use the Start and End Time Range entry fields to include Network Data, based on the appropriate Broadcast Time Stamp, in order to capture the start of broadcast activity for Activation/Modification/Disconnect, when generating the file for the Latest View of Network Data Activity selection. (Previously NANC 354 Req 7)

RR3-307     Network Data Information Bulk Download File Creation — Selection Criteria Combinations

NPAC SMS shall edit the selection criteria combination as shown in the table below:

	Time Range	TN Range
All Network Data	Rejected	Not Available
Latest View of Network Data Activity	Required	Not Available

Such that a combination of:

•	All with a Time Range shall be rejected.
•	Latest View shall require a Time Range.
•	TN Range shall not be available for either All or Latest View.
	(Previously NANC 354 Req 8)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-59 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-308 Network Data Information Bulk Data Download – Network Data Results

NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Network Data in the NPAC SMS. (Previously NANC 354 Req 9)

RR3-309 Network Data Information Bulk Data Download – Network Data Results Sort Order

NPAC SMS shall sort the Network Data Bulk Data Download files, in ascending order based on the value in the NPA-NXX/LRN/NPA-NXX-X attribute. (Previously NANC 354 Req 10)

RR3-310 Network Data Information Bulk Data Download – Filters for Network Data

NPAC SMS shall apply NPA-NXX Filters to Network Data in the creation of bulk data download files. (Previously NANC 354 Req 11)

RR3-311 Network Data Information Bulk Data Download – FTP Sub-Directory

NPAC SMS shall automatically put the Network Data bulk data download files into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the Network Data bulk data download files. (Previously NANC 354 Req 12)

RR3-481 Service Provider Data Information Bulk Data Download – Support for Service Provider Type Data

NPAC SMS shall apply the Service Provider Type tunable support of the requesting Service Provider, in the creation of Service Provider bulk data download files. (previously NANC 357, Req 8)

3.10.3 Subscription Version, Bulk Data Download

RR3-225 Bulk Data Download –Required Selection Criteria for Subscription Data File Generation

NPAC SMS shall require, as selection criteria for subscription bulk data download file generation, a Service Provider filter of either a single Service Provider ID or ‘All Service Providers’.

RR3-226 Bulk Data Download – Optional Selection Criteria for Subscription Data File Generation -DELETED.

RR3-312 Subscription Version Information Bulk Download File Creation – Selection Criteria

NPAC SMS shall include the Requesting Service Provider, Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity Choice, Time Range and TN Range as Selection Criteria fields for the Subscription Version bulk data download file via the NPAC Administrative Interface. (Previously NANC 169 Req 2)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-60 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-313 Subscription Version Information Bulk Download File Creation – Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity Choice

NPAC SMS shall allow NPAC Personnel to select either Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity, and shall use the selected choice, for Subscription Version data. (Previously NANC 169 Req 3)

RR3-314 Subscription Version Information Bulk Download File Creation – Data in Active/Disconnect Pending/Partial Failure Subscription Versions Only Choice

NPAC SMS shall use the Active/Disconnect Pending/Partial Failure Subscription Versions Only selection to only include Subscription Versions with a status of either Active, Disconnect Pending, Partial Failure, or Sending that is being downloaded for either an activate or modify but not a disconnect, in the Subscription Version Bulk Data Download file. (Previously NANC 169 Req 4)

RR3-315 Subscription Version Information Bulk Download File Creation – Data in Latest View of Subscription Version Activity Choice

NPAC SMS shall use the Latest View of Subscription Version Activity selection to include all Subscription Versions, regardless of status, in order to capture activation, modification, and deletion transactions for Subscription Version data, but only include the latest instance of the TN in the Subscription Version Bulk Data Download file, for a given NPA-NXX, when a Subscription Version has more than one activity (e.g., addition, then modification) within the specified time range. (Previously NANC 169 Req 5)

Note: The format of the BDD file doesn’t change based on the status of the SV but some of the fields may be blank. Example: Creates and modifies would have all the attributes specified but disconnect and deletes would have many fields null.

RR3-316 Subscription Version Information Bulk Download File Creation – Time Range Fields

NPAC SMS shall use the Start Time Range entry field as an inclusive start range, and the End Time Range entry field as an inclusive end range, for Subscription Version data that were broadcast during the specified Time Range. (Previously NANC 169 Req 6)

Note: The NPAC Administrative Interface is settable for the GUI user’s local time (e.g., a USA in Sterling will have the local time set to Eastern Time).

RR3-317 Subscription Version Information Bulk Download File Creation – Time Range Fields and SV Data Model

NPAC SMS shall use the Start and End Time Range entry fields to include Subscription Version data, based on the appropriate Broadcast Time Stamp, in order to capture the start of broadcast activity for Activation/Modification/Disconnect, when generating the file for the Latest View of Subscription Version Activity selection. (Previously NANC 169 Req 7)

RR3-318 Subscription Version Information Bulk Download File Creation – TN Range Fields

NPAC SMS shall use the first TN Range entry field as an inclusive start range, and the second TN Range entry field as an inclusive end range, for Subscription Version data. (Previously NANC 169 Req 8)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-61 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-319 Subscription Version Information Bulk Download File Creation – Selection Criteria Combinations

NPAC SMS shall edit the selection criteria combination as shown in the table below:

	Time Range	TN Range
Active/Disconnect Pending/Partial Failure Sending with a Download Reason of New or Modify SVs Only	Rejected	Optional
Latest View of SV Activity	Required	Optional

Such that a combination of:

•	Active with a Time Range shall be rejected.
•	Latest View shall require a Time Range.
•	TN Range shall be optional for both Active and Latest View.
	(Previously NANC 169 Req 9)

RR3-320 Subscription Version Information Bulk Data Download – Subscription Version Results

NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Subscription Versions in the NPAC SMS. (Previously NANC 169 Req 10)

RR3-321 Subscription Version Information Bulk Data Download – Subscription Version Results Sort Order

NPAC SMS shall sort the Subscription Version Bulk Data Download file, in ascending order based on the value in the TN attribute. (Previously NANC 169 Req 11)

RR3-322 Subscription Version Information Bulk Data Download – Filters for Subscription Versions

NPAC SMS shall apply NPA-NXX Filters to Subscription Versions in the creation of bulk data download files. (Previously NANC 169
Req 12)

RR3-323 Subscription Version Information Bulk Data Download – EDR LSMSs

NPAC SMS shall use the Service Provider’s profile (EDR Flag True or False) to determine if it should include Pooled SVs in the bulk data download file. (Previously NANC 169 Req 13)

RR3-227 Bulk Data Download – FTP Sub-Directory

NPAC SMS shall automatically put the subscription bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the subscription bulk data download file.

RR3-324 Bulk Download File Creation – Pooled Subscription Versions Filtered for EDR Local SMS

NPAC SMS shall filter out Subscription Versions with LNP Type of POOL for Bulk Data Download files of Subscription Version data, when the requesting Service Provider has an EDR Indicator set to TRUE. (Previously SV-521 and RR5-112)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-62 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.10.4 NPA-NXX-X Holder, Bulk Data Download

This section of requirements was previously 3.13.9 NPA-NXX-X Holder, Bulk Data Download and was moved to this new section for document consistency. The requirement numbers remain static to their original FRS numbering.

RR3-116 Number Pool NPA-NXX-X Holder Information Bulk Download File – Separate File containing all NPA-NXX-X Data

NPAC SMS shall provide a separate bulk data download file that contains all NPA-NXX-Xs in the NPAC SMS, when generating bulk data download files for Network Data. (Previously N-373)

RR3-117 Number Pool NPA-NXX-X Holder Information Bulk Download File – Filters for NPA-NXX-X Data

NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-Xs in the creation of a bulk data download file. (Previously N-374)

RR3-118 Number Pool NPA-NXX-X Holder Information Bulk Download File – FTP Sub-Directory

NPAC SMS shall automatically put the NPA-NXX-X bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the bulk data download file for Network Data. (Previously N-375)Subscription Version, Bulk Data Download

3.10.5 Block Holder, Bulk Data Downloads

This section of requirements was previously 3.14.9 Block Holder, Bulk Data Download and was moved to this new section for document consistency. The requirement numbers remain static to their original FRS numbering.

RR3-198 Number Pool Block Holder Information Bulk Download File Creation – Blocks

NPAC SMS shall allow NPAC personnel to request a bulk data download file for Block data via the NPAC Administrative Interface. (Previously B-640)

RR3-199 Number Pool Block Holder Information Bulk Download File Creation – Selection Criteria

NPAC SMS shall include the Requesting Service Provider, Active and Partial Failure Blocks Only or Latest View of Block Activity Choice, Time Range, and Block Range as Selection Criteria fields for the Block bulk data download file via the NPAC Administrative Interface. (Previously B-650)

RR3-200.1 Number Pool Block Holder Information Bulk Download File Creation – Active and Partial Failure Blocks Only or Latest View of Block Activity Choice

NPAC SMS shall allow NPAC Personnel to select either Active and Partial Failure Blocks Only or Latest View of Block Activity, and shall use the selected choice, for Block data. (Previously B-652.1)

RR3-200.2 Number Pool Block Holder Information Bulk Download File Creation – Data in Active Blocks Only Choice

NPAC SMS shall use the Active and Partial Failure Blocks Only selection to only include Blocks with a status of either Active or Partial Failure in the Block Bulk Data Download file. (Previously B-652.2)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-63 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-200.3 Number Pool Block Holder Information Bulk Download File Creation – Data in Latest View of Block Activity Choice

NPAC SMS shall use the Latest View of Block Activity selection to include all Blocks, regardless of status, in order to capture activation, modification, and deletion transactions for Block data, but only include the latest instance of the Block in the Block Bulk Data Download file, for a given NPA-NXX-X, when a Block has more than one activity (e.g., addition, then modification) within the specified time range. (Previously B-652.3)

RR3-201.1 Number Pool Block Holder Information Bulk Download File Creation – Time Range Fields

NPAC SMS shall use the Start Time Range entry field as an inclusive start range in GMT, and the End Time Range entry field as an inclusive ending range in GMT, for Block data that were broadcast during the specified Time Range. (Previously B-654.1)

RR3-201.2 Number Pool Block Holder Information Bulk Download File Creation – Time Range Fields and Block Data Model

NPAC SMS shall use the Start and End Time Range entry fields to include Block data, based on the appropriate Timestamps, in the NPAC’s Block Data Model, when generating the file for the Latest View of Block Activity selection. (Previously B-654.2)

RR3-202 Number Pool Block Holder Information Bulk Download File Creation – Block Range Fields

NPAC SMS shall use the first Block Range entry field as an inclusive start range, and the second Block Range entry field as an inclusive ending range, for Block data. (Previously B-655)

Note: If the Block Range was 303-242-2 through 303-355-6, the inclusive range would contain all Blocks within the TN Range of 303-242-2000 through 303-355-6999.

RR3-203 Number Pool Block Holder Information Bulk Download File Creation – Selection Criteria Combinations

NPAC SMS shall edit the selection criteria combination as shown in the table below: (Previously B-657)

	Time Range	Block Range
Active and Partial Failure Blocks Only	Rejected	Optional
Latest View of Block Activity	Required	Optional

Such that a combination of:

• Active with a Time Range shall be rejected.

• Latest View shall require a Time Range.

• Block Range shall be optional for both Active and Latest View.

RR3-204 Number Pool Block Holder Information Bulk Data Download – Block Results

NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Blocks in the NPAC SMS, regardless of the value in the Service Provider’s EDR Indicator. (Previously B-660)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-64 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-205 Number Pool Block Holder Information Bulk Data Download – Block Results Sort Order

NPAC SMS shall sort the Block Bulk Data Download file, in ascending order based on the value in the NPA-NXX-X attribute. (Previously B-662)

RR3-206 Number Pool Block Holder Information Bulk Data Download – Filters for Blocks

NPAC SMS shall apply NPA-NXX Filters to Blocks in the creation of bulk data download files. (Previously B-670)

RR3-207 Number Pool Block Holder Information Bulk Data Download – FTP Sub-Directory

NPAC SMS shall automatically put the bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the bulk data download file. (Previously B-680)

3.10.6 Notifications, Bulk Data Download

RR3-462 Notification BDD Selection Criteria Fields

NPAC SMS shall include the requesting Service Provider and a time range, as selection criteria fields for the Notification bulk data download file, via the NPAC Administrative Interface. (previously NANC 348, Req 2)

RR3-463 Notification BDD Required Selection Criteria

NPAC SMS shall require, as selection criteria for notification bulk data download file generation, a requesting Service Provider ID and a time range. (previously NANC 348, Req 3)

RR3-464 Notification BDD File Name

NPAC SMS shall provide a bulk data download file for notification data, using a file name that indicates the Notification data and requested time range. (previously, NANC 348, Req 4)

RR3-465 Notification BDD Time Range

NPAC SMS shall use the Start Time Range entry field as an exclusive start range, and the End Time Range entry field as an inclusive end range, for Notification data that were broadcast during the specified time range, based on notification attempt timestamp. (previously NANC 348, Req 5)

RR3-466 Notification BDD Results

NPAC SMS shall provide a bulk data download file, based on selection criteria, that contains all Notification data in the NPAC SMS. (previously NANC 348, Req 6)

RR3-467 Notification BDD Sort Order

NPAC SMS shall sort the Notification bulk data download file, in ascending order based on the value for date and time. (previously NANC 348, Req 7)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-65 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-468 Notification BDD Filters

NPAC SMS shall apply SP Profile Flags for ranges and notification type (based on the settings at the time the notification was created). (previously NANC 348, Req 8)

RR3-469 Notification BDD FTP Sub-Directory

NPAC SMS shall automatically put the Notification bulk data download file into the FTP sub-directory of the Service Provider, based on the SPID value of the requesting Service Provider. (previously NANC 348, Req 9)

3.10.7 Bulk Data Download Response Files

The following section describes Bulk Data Download Response files. Bulk Data Download Response Files are used by the NPAC SMS to clean up Failed SP Lists for Subscription Version and Number Pool Block information.

RR3-325 File Name Format for Service Provider BDD Response File

NPAC SMS shall require the file name format of the Service Provider BDD Response File to be the original BDD File Name with a dash and the SPID appended at the end. (Previously NANC 322 Req 7)

Example: Subscription Versions BDD File for SPID 4768

BDD File Name	NPANXX-NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS
Service Provider BDD Response File Name	NPANXX-NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS-4768

RR3-326 File Contents for Service Provider BDD Response File

NPAC SMS shall require the file contents of the Service Provider BDD Response File to contain a minimum format of SVID/PooledBlock ID and TN/PooledBlock, based on a response file for either Subscription Version data or Block data.

Note: A Service Provider can either send back the same file (with SPID value appended at the end of the file name), or a truncated version of the rest of the data, as long as the first two columns are in the response file. (Previously NANC 322 req 8)

Example of BDD Response File: Subscription Versions BDD Response File for SPID 4768 (Block Response Files would contain the parenthetical attributes)

SVID (or Block ID) <pipe> TN (or Block value) <CR>
123987|7032281234 <CR>	(end of first TN with “positive” response)
123988|7032281235<CR>	(end of second TN with “positive” response)
123989|7032281236 <CR>	(end of third TN with “positive” response)
123990|7032281237 <CR>	(end of fourth TN with “positive” response)
123991|7032281238 <CR>	(end of fifth TN with “positive” response)

Note: There will be separate files for Subscription Versions and Number Pool Blocks.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-66 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-327 Complete File Processing for Service Provider BDD Response File

NPAC SMS shall require the file contents of the Service Provider BDD Response File to contain a “positive” response for each “in-sync” record from the original BDD File, and the NPAC SMS shall successfully process each record in a Service Provider BDD Response File once. (Previously NANC 322 Req 9)

Note: Service Providers cannot provide more than one BDD Response File for any given BDD File. The definition of a “positive” record in the response file is one where the Service Provider and the NPAC are “in-sync” (whether the Service Provider updated their database or already had the record in their database). So a “positive” response is synchronization-based, not action-based, and the NPAC will use this “positive” response as an indication to remove the Service Provider from the failed list, if applicable.

RR3-328 Processing of the Service Provider BDD Response File for Subscription Versions

NPAC SMS shall process the Service Provider BDD Response File, containing “positive” response records for the original BDD file, received from a Service Provider’s ftp site as a result of the Service Provider receiving and processing a Bulk Data Download File or a Delta Bulk Data Download File for Subscription Versions. (Previously NANC 322 Req 1)

Note: For example in a situation where 1000 SVs are selected and placed in the BDD File, the NPAC will expect the Service Provider to provide a response file for those 1000 records, which would include up to 1000 “positive” responses. The definition of a “positive” record in the response file is one where the Service Provider and the NPAC are in sync (whether the Service Provider updated their database or already had the record in their database). So a “positive” response is synchronization-based, not action-based, and the NPAC will use this “positive” response as an indication to remove the Service Provider from the failed list, if applicable. So, a Service Provider receives a delta BDD that contains 1000 SVs, and they add 990 to their database, and confirm that 8 are already in their database and don’t need any changes. The BDD Response File would contain 998 “positive” responses that the NPAC would then process.

RR3-329 Removing a Service Provider from a Subscription Version Failed SP List

NPAC SMS shall remove a Service Provider from a Subscription Version Failed SP List based on the SVID contained in the Service Provider BDD Response File and the timestamp in the file name being greater than or equal to the broadcast timestamp. (Previously NANC 322 Req 3)

RR3-330 Processing of the Service Provider BDD Response File for Number Pooling Blocks

NPAC SMS shall process the Service Provider BDD Response File, containing “positive” response records for the original BDD file, received from a Service Provider’s ftp site as a result of the Service Provider receiving and processing a Bulk Data Download File or a Delta Bulk Data Download File for Number Pooling Blocks. (Previously NANC 322 Req 2)

Note: For example in a situation where 12 Blocks are selected and placed in the BDD File, the NPAC will expect the Service Provider to provide a response file for those 12 records, which would include up to 12 “positive” responses. The definition of a “positive” record in the response file is one where the Service Provider and the NPAC are in sync (whether the Service Provider updated their database or already had the record in their database). So a “positive” response is synchronization-based, not action-based, and the NPAC will use this “positive” response as an indication to remove the Service Provider from the failed list, if applicable. So, a Service Provider receives a delta BDD that contains 12 Blocks, and they add 10 to their database, and confirm that 1 is already in their database and doesn’t need any changes. The BDD Response File would contain 11 “positive” responses that the NPAC would then process.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-67 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-331 Removing a Service Provider from a Number Pooling Block Failed SP List

NPAC SMS shall remove a Service Provider from a Number Pooling Block Failed SP List based on the BlockID contained in the Service Provider BDD Response File and the timestamp in the file name being greater than or equal to the broadcast timestamp. (Previously NANC 322 Req 4)

RR3-332 Service Provider Not Found on the Failed SP List

NPAC SMS shall continue processing the Service Provider BDD Response File after finding that the SPID for one of the data items in the Service Provider BDD Response File does not match a SPID on the Failed SP List. (Previously NANC 322 Req 5)

RR3-333 Validation of SPID in the Service Provider BDD Response File Against SPID of the FTP Directory

NPAC SMS shall validate the SPID of the FTP directory against the SPID in the Service Provider BDD Response File it is retrieving. (Previously NANC 322 Req 6)

3.11 NPA-NXX-X Information

3.11.1 NPA-NXX-X Download Indicator Management

RR3-52 NPAC Customer SOA NPA-NXX-X Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving the NPA-NXX-X data, by downloading this data to their SOA via the SOA to NPAC SMS Interface, using the Number Pooling NPA-NXX-X Object. (Previously NC-1)

RR3-53 NPAC Customer SOA NPA-NXX-X Indicator – Default

NPAC SMS shall default the SOA NPA-NXX-X Indicator to FALSE. (Previously NC-3)

RR3-54 NPAC Customer SOA NPA-NXX-X Indicator – Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the SOA NPA-NXX-X Indicator on the NPAC Customer record. (Previously NC-5)

RR3-55 NPAC Customer LSMS NPA-NXX-X Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving the NPA-NXX-X data, by downloading this data to their Local SMS via the NPAC SMS to Local SMS Interface, using the Number Pooling NPA-NXX-X Object. (Previously NC-10)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-68 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-56 NPAC Customer LSMS NPA-NXX-X Indicator – Default

NPAC SMS shall default the LSMS NPA-NXX-X Indicator to FALSE. (Previously NC-20)

RR3-57 NPAC Customer LSMS NPA-NXX-X Indicator – Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the LSMS NPA-NXX-X Indicator on the NPAC Customer record. (Previously NC-30)

RR3-58 NPAC Customer LSMS EDR Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports Efficient Data Representation (EDR), by downloading this data to their Local SMS via the NPAC SMS to Local SMS Interface, using the Number Pooling Block Object. (Previously NC-50)

RR3-59 NPAC Customer LSMS EDR Indicator – Default

NPAC SMS shall default the EDR Indicator to FALSE. (Previously NC-60)

RR3-60 NPAC Customer LSMS EDR Indicator – Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the EDR Indicator on the NPAC Customer record. (Previously NC-70)

3.11.2 NPA-NXX-X Holder Information

RR3-61 Number Pool NPA-NXX-X Holder Information – NPAC Personnel OpGUI

NPAC SMS shall allow NPAC Personnel to add, modify, delete, and query NPA-NXX-X Holder information via the NPAC Administrative Interface. (Previously N-10)

RR3-62 Number Pool NPA-NXX-X Holder Information – Service Provider Request

NPAC SMS shall reject a request from a Service Provider SOA via the SOA to NPAC SMS Interface, Service Provider via the NPAC SOA Low-tech Interface, or Service Provider via the NPAC SMS to Local SMS Interface, to add, modify, or delete, NPA-NXX-X Holder information as stored in the NPAC SMS. (Previously N-20)

RR3-63 Number Pool NPA-NXX-X Holder Information – NPA-NXX Validation

NPAC SMS shall validate that the NPA-NXX specified in the addition of Number Pooling NPA-NXX-X Holder information is a valid NPA-NXX defined in the NPAC SMS. (Previously N-30)

RR3-64 Number Pool NPA-NXX-X Holder Information – NPA-NXX Effective Date

DELETED

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-69 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-65 Number Pool NPA-NXX-X Holder Information – Duplicate NPA-NXX-X Validation

NPAC SMS shall validate that the NPA-NXX-X specified in the addition of Number Pooling NPA-NXX-X Holder Information is not a duplicate for another entry in the Number Pooling NPA-NXX-X Holder Information. (Previously N-50)

RR3-68 Number Pool NPA-NXX-X Holder Information – Service Provider Local SMS NPA-NXX-X Indicator Download of NPA-NXX-X Object

NPAC SMS shall download Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, using the Number Pooling NPA-NXX-X Object, via the NPAC SMS to Local SMS Interface if the Service Provider’s Local SMS NPA-NXX-X indicator is TRUE. (Previously N-63)

RR3-69 Number Pool NPA-NXX-X Holder Information – Service Provider Local SMS NPA-NXX-X Indicator Suppression of Download of NPA-NXX-X Object

NPAC SMS shall suppress the download of Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, via the NPAC SMS to Local SMS Interface if the Service Provider’s Local SMS NPA-NXX-X indicator is FALSE. (Previously N-64)

RR3-70 Number Pool NPA-NXX-X Holder Information – Filters for NPA-NXX-X Download to the Local SMS

NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X downloads to the Local SMS(s). (Previously N-65)

RR3-71 Number Pool NPA-NXX-X Holder Information – Service Provider SOA NPA-NXX-X Indicator Download of NPA-NXX-X Object

NPAC SMS shall download Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, using the Number Pooling NPA-NXX-X Object, via the SOA to NPAC SMS Interface if the Service Provider’s SOA NPA-NXX-X indicator is TRUE. (Previously N-66)

RR3-72 Number Pool NPA-NXX-X Holder Information – Service Provider SOA NPA-NXX-X Indicator Suppression of Download of NPA-NXX-X Object

NPAC SMS shall suppress the download of Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, via the SOA to NPAC SMS Interface if the Service Provider’s SOA NPA-NXX-X indicator is FALSE. (Previously N-67)

RR3-73 Number Pool NPA-NXX-X Holder Information – Filters for NPA-NXX-X Download to the SOA

NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X downloads to the SOA(s). (Previously N-68)

RR3-74 Number Pool NPA-NXX-X Holder Information – Validation Error

NPAC SMS shall report an error to the NPAC Personnel and reject the addition or modification of Number Pooling NPA-NXX-X Holder information, or the addition of an NPA Split, if validation errors occur as defined in Requirements RR3-63, RR3-65, RR3-85, RR3-96, RR3-32, RR3-482 and RR3-483. (Previously N-70, updated with NANC 394)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-70 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.11.3 NPA-NXX-X Holder, NPAC Scheduling/Re-Scheduling of Block Creation

RR3-75.1 Number Pool NPA-NXX-X Holder Information –OpGUI Entry Field for NPAC or SOA Origination

NPAC SMS shall provide a mechanism for NPAC Personnel to select NPAC Origination or SOA Origination for the Block data, when creating NPA-NXX-X Holder information, via the NPAC Administrative Interface. (Previously N-71.1)

RR3-75.2 Number Pool NPA-NXX-X Holder Information –OpGUI Entry Mechanism for Immediate or Scheduled Block Creation

NPAC SMS shall provide a mechanism for NPAC Personnel to request NPAC Block Creation for either immediate execution, once the Effective Date has been reached, or at a future date/time, via the NPAC Administrative Interface. (Previously N-71.2)

RR3-75.3 Number Pool NPA-NXX-X Holder Information –OpGUI Entry Field for Scheduled Date/Time

NPAC SMS shall include the “Scheduled Date/Time for Block Activation” as an entry field in the format of MM/DD/YYYY and HH:MM, for the NPA-NXX-X Holder information via the NPAC Administrative Interface. (Previously N-71.3)

RR3-76.1 Number Pool NPA-NXX-X Holder Information –Default for Scheduled Date/Time Entry Field

NPAC SMS shall default the value in the “Scheduled Date/Time for Block Activation” field in the NPAC Administrative Interface, to the greater of, the Effective Date and 00:01 (HH:MM) Central Time, or, the current date and time. (Previously N-72.1)

RR3-76.2 Number Pool NPA-NXX-X Holder Information –Scheduled Date/Time Entry Field Validation

NPAC SMS shall validate that the “Scheduled Date/Time for Block Activation” field in the NPAC Administrative Interface, is a valid date and time, and is greater than or equal to the NPA-NXX-X Effective Date. (Previously N-72.2)

RR3-77 Number Pool NPA-NXX-X Holder Information –Use of Scheduled Date/Time and NPAC Origination Entry Fields

NPAC SMS shall use the value in the “Scheduled Date/Time for Block Activation” field as the date and time, in Central Time, that the Block Creation scheduled event will occur, when the NPAC Origination has been selected by NPAC Personnel while creating NPA-NXX-X Holder information, or when re-scheduling a Block Create Event. (Previously N-73)

RR3-78 Number Pool NPA-NXX-X Holder Information – Routing Data for NPAC Origination

NPAC SMS shall require NPAC Personnel to enter applicable Block routing data, via the NPAC Administrative Interface, when the NPAC Origination has been selected by NPAC Personnel while creating NPA-NXX-X Holder information, or when re-scheduling a Block Create Event. (Previously N-74)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-71 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-79.1 Number Pool NPA-NXX-X Holder Information – Routing Data Field Level Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, are valid according to the formats specified in the Block Data Model upon Block creation scheduling for a Number Pool, or when re-scheduling a Block Create Event: (Previously N-75.1, reference NANC 399)

NPA-NXX-X Holder SPID
NPA-NXX-X
LRN
Class DPC
Class SSN
LIDB DPC
LIDB SSN
CNAM DPC
CNAM SSN
ISVM DPC
ISVM SSN
WSMSC DPC (if supported by the Block Holder SOA)
WSMSC SSN (if supported by the Block Holder SOA)
Number Pool Block SV Type (if supported by the Block Holder SOA)
Alternative SPID (if supported by the Block Holder SOA)

RR3-79.2 Number Pool NPA-NXX-X Holder Information – Routing Data LRN Validation

NPAC SMS shall validate that the LRN specified in the scheduling/re-scheduling of Number Pooling Block Holder information is a valid LRN defined in the NPAC SMS for the Block Holder. (Previously N-75.2)

RR3-80.1 Number Pool NPA-NXX-X Holder Information – Modification of Block Create Event

NPAC SMS shall provide a mechanism for NPAC Personnel to modify a Block Create Event that has been previously entered, but not yet executed, via the NPAC Administrative Interface. (Previously N-76.1)

RR3-80.2 Number Pool NPA-NXX-X Holder Information – Modification of Scheduled Date/Time for Block Create Event

NPAC SMS shall allow NPAC Personnel to modify the scheduled date/time for an NPAC initiated Block Create Event, to a different date/time that is on or after the NPA-NXX-X effective date. (Previously N-76.2)

RR3-80.3 Number Pool NPA-NXX-X Holder Information – Modification of Routing Data for Block Create Event

NPAC SMS shall allow NPAC Personnel to modify the routing data for an NPAC initiated Block Create Event. (Previously N-76.3)

RR3-81.1 Number Pool NPA-NXX-X Holder Information – Re-schedule of NPAC Initiated Block Create

NPAC SMS shall provide a mechanism for NPAC Personnel to re-schedule a Block Create, for an existing NPA-NXX-X, via the NPAC Administrative Interface. (Previously N-77.1)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-72 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-81.2 Number Pool NPA-NXX-X Holder Information – Re-schedule of Block Create Scheduling Options

NPAC SMS shall provide a mechanism where the re-schedule of a Block Create, can be immediately executed or scheduled for a future date/time. (Previously N-77.2)

RR3-81.3 Number Pool NPA-NXX-X Holder Information – Re-schedule of Block Create Immediate Execution Edit Check

NPAC SMS shall reject the re-schedule of a Block Create for immediate execution, prior to the effective date of the NPA-NXX-X. (Previously N-77.3)

RR3-82.1 Number Pool NPA-NXX-X Holder Information – Reject Re-schedule Based on Status

NPAC SMS shall allow the re-schedule of a Block Create, if the Block does NOT exist in the NPAC SMS, or if the Block exists with a status of Old without a Failed SP List. (Previously N-78.1)

RR3-82.2 Number Pool NPA-NXX-X Holder Information – Reject Re-schedule Based on Existing Block Create Event

NPAC SMS shall only allow a single Block Create Event that has not been previously executed for this Block, to exist in the NPAC SMS. (Previously N-78.2)

RR3-82.3 Number Pool NPA-NXX-X Holder Information – Validation Error for Schedule/Re-Schedule of Block Create Event

NPAC SMS shall report an error to the NPAC Personnel and reject the addition or modification of a Number Pooling Block Create Event, if validation errors occur as defined in Requirements RR3-76.2, RR3-78, RR3-79.1, RR3-79.2, RR3-81.3, RR3-82.1, and RR3-82.2. (Previously N-78.3)

RR3-83.1 Number Pool NPA-NXX-X Holder Information – Error Message for Pending-Like No-Active SVs during Block Create

NPAC SMS shall provide an error dialog that displays the unique error message described in RR3-147, and provides an option for the NPAC Personnel to either, exit the Block Create request, or generate the Pending-Like No-Active Subscription Version(s) report, in the report format listed in RR9-11, RR9-12, RR9-13, and RR9-14, to the screen on the NPAC Administrative Interface, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.1)

RR3-83.2 Number Pool NPA-NXX-X Holder Information – Pending-Like No-Active SVs Report Output Destinations

NPAC SMS shall, after displaying the Pending-Like No-Active Subscription Version(s) report to the screen, allow the NPAC Personnel to choose an output destination for the report, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.2)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-73 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-83.3 Number Pool NPA-NXX-X Holder Information – Pending-Like No-Active SVs Report Output Destinations for Multiple Destinations

NPAC SMS shall, continue to display the Pending-Like No-Active Subscription Version(s) report, to the screen, and allow the NPAC Personnel to choose additional output destinations one at a time, for the report, until the NPAC Personnel requests the closure of the report window, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.3)

RR3-83.4 Number Pool NPA-NXX-X Holder Information – Output Destination for Pending-Like No-Active SVs

NPAC SMS shall provide output destination options for the Pending-Like No-Active Subscription Version(s) Report, based on the error message in RR3-83.1, that include print, fax, e-mail, stored to a file, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.4)

3.11.4 NPA-NXX-X Holder, Addition

RR3-84 Addition of Number Pooling NPA-NXX-X Holder Information – Required Fields

NPAC SMS shall require NPAC personnel to specify the NPA-NXX-X Holder SPID, the NPA-NXX-X, and the Effective Date, as defined in the Number Pooling NPA-NXX-X Holder Information data model. (Previously N-80)

RR3-85 Addition of Number Pooling NPA-NXX-X Holder Information – SPID Validation

NPAC SMS shall validate that the NPA-NXX-X Holder SPID is a valid Service Provider in the NPAC SMS. (Previously N-90)

RR3-86 Addition of Number Pooling NPA-NXX-X Holder Information – Check for Pending-Like No-Active SVs

NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Creation, if there are any TNs within the 1K Block of that NPA-NXX-X, or in a 1K Block of the corresponding old/new NPA-NXX-X belonging to an NPA-NXX scheduled for or currently in an NPA split, that contain an SV, with a status of pending/conflict/cancel-pending/failed, and where a currently active SV does NOT exist, for the given TN. (Previously N-100)

RR3-87 Addition of Number Pooling NPA-NXX-X Holder Information – Check for Pending-Like Port-To-Original SVs

NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Creation, if there are any TNs within the 1K Block, that contain an SV, with a status of pending/conflict/cancel-pending/failed, and where the SV is a Port-To-Original port, for the given TN. (Previously N-110)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-74 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-88.1 Addition of Number Pooling NPA-NXX-X Holder Information – Error Message for Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs

NPAC SMS shall provide an error dialog that displays the unique error message described in RR3-86 and RR3-87, and provides an option for the NPAC Personnel to either, exit the NPA-NXX-X Create request, or generate the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, in the report format listed in RR9-11, RR9-12, RR9-13, and RR9-14, to the screen on the NPAC Administrative Interface. (Previously N-130.1)

RR3-88.2 Addition of Number Pooling NPA-NXX-X Holder Information –Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs Report Selection of Output Destinations

NPAC SMS shall, after displaying the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, allow the NPAC Personnel to choose an output destination for the report. (Previously N-130.2)

RR3-88.3 Addition of Number Pooling NPA-NXX-X Holder Information –Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs Report Output Destinations for Multiple Destinations

NPAC SMS shall, continue to display the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, and allow the NPAC Personnel to choose additional output destinations one at a time, for the report, until the NPAC Personnel requests the closure of the report window. (Previously N-130.3)

RR3-89 Addition of Number Pooling NPA-NXX-X Holder Information – Output Destination for Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs

NPAC SMS shall provide output destination options, as listed in R9-2, for the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, based on the error condition in RR3-88.1. (Previously N-131)

RR3-90 Addition of Number Pooling NPA-NXX-X Holder Information Effective Date Window– Tunable Parameter

DELETED

RR3-91 Addition of Number Pooling NPA-NXX-X Holder Information Effective Date Window – Tunable Parameter Default

DELETED

RR3-92 Addition of Number Pooling NPA-NXX-X Holder Information Effective Date – Validation

DELETED

RR3-482 Number Pooling NPA-NXX-X Holder Information Effective Date – Validation upon Addition

NPAC SMS shall verify that the Effective Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and greater than or equal to the current date, when adding an NPA-NXX-X. (previously NANC 394, Req 4)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-75 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-470 Addition of Number Pooling NPA-NXX-X Holder Information Effective Date – Validation Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window

DELETED

RR3-93 Addition of Number Pooling NPA-NXX-X Holder Information Effective Date – OpGUI Default

NPAC SMS shall set the time portion of the Effective Date Timestamp to 00:00 Central Time, and not allow the NPAC Personnel to modify the Time portion of the Effective Date, on the NPAC Administrative Interface. (Previously N-170)

RR3-94 Addition of Number Pooling NPA-NXX-X Holder Information – Successful Validation

NPAC SMS shall, upon successful validation, store the NPA-NXX-X in the NPAC SMS, and broadcast the NPA-NXX-X to the Service Providers. (Previously N-180)

3.11.5 NPA-NXX-X Holder, Modification

RR3-95 Modification of Number Pool NPA-NXX-X Holder Information – Effective Date Modification from OpGUI

NPAC SMS shall allow NPAC personnel to modify the effective date for an NPA-NXX-X as stored in the NPAC SMS via the NPAC Administrative Interface. (Previously N-190)

RR3-96 Modification of Number Pool NPA-NXX-X Holder Information – Effective Date versus Current Date

NPAC SMS shall allow the NPAC personnel to modify the effective date for an NPA-NXX-X if the current date is less than the effective date for the NPA-NXX-X. (Previously N-200)

RR3-97 Modification of Number Pool NPA-NXX-X Holder Information – Effective Date Update to Scheduled Block Create

NPAC SMS shall, upon modifying the effective date for an NPA-NXX-X, and where the Block Creation was a scheduled event within the NPAC SMS, also modify the corresponding date for that Block Create scheduled event. (Previously N-210)

RR3-98 Modification of Number Pool NPA-NXX-X Holder Information Effective Date Window – Tunable Parameter Modification

DELETE

RR3-99 Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation for Current Date

DELETED

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-76 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-100 Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation for Tunable

DELETED

RR3-483 Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation

NPAC SMS shall verify that the Effective Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and greater than or equal to the current date, when modifying an NPA-NXX-X. (previously NANC 394, Req 5)

RR3-471 Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation Within the Tunable Parameter Number of Days

DELETED

RR3-101 Modification of Number Pooling NPA-NXX-X Holder Information – Successful Validation

NPAC SMS shall, upon successful validation, store the updates to the NPA-NXX-X in the NPAC SMS, and broadcast the updated NPA-NXX-X to the Service Providers. (Previously N-235)

3.11.6 NPA-NXX-X Holder, Deletion

RR3-102 Deletion of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X Data

NPAC SMS shall allow NPAC personnel to delete the NPA-NXX-X holder information for an NPA-NXX-X as stored in the NPAC SMS. (Previously N-240)

RR3-103 Deletion of Number Pool NPA-NXX-X Holder Information – Single NPA-NXX-X at a time from OpGUI

NPAC SMS shall allow NPAC personnel to delete the NPA-NXX-X holder information for a single NPA-NXX-X at a time, via the NPAC Administrative Interface. (Previously N-245)

RR3-104 Deletion of Number Pooling NPA-NXX-X Holder Information – Check for Pending-Like With Active POOL SVs

NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if there are any TNs within the 1K Block, that contain an SV with a status of pending/conflict/cancel-pending/failed where the Old SP is equal to the NPA-NXX-X Holder SPID, and the current active SV is LNP Type of POOL. (Previously N-250)

RR3-105 Deletion of Number Pooling NPA-NXX-X Holder Information – Check for Port-to-Original SVs

NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if there are any TNs within the 1K Block, that contain an SV, where the SV is a Port-To-Original port. (Previously N-260)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-77 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-106 Deletion of Number Pooling NPA-NXX-X Holder Information – Check for non-Active Block

NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if the associated Block, contains a status other than Active, or the Failed SP List contains any SPIDs. (Previously N-265)

RR3-107 Deletion of Number Pooling NPA-NXX-X Holder Information – Check for Sending SVs

NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if there are any Subscription Versions with a status of sending, as a result of a disconnect request for that given Subscription Version. (Previously N-270)

RR3-108.1 Deletion of Number Pooling NPA-NXX-X Holder Information – Error Message for Pending-Like With Active POOL SVs and Pending-Like Port-To-Original SVs

NPAC SMS shall provide an error dialog that displays the unique error message described in RR3-104 and RR3-105, and provides an option for the NPAC Personnel to either, exit the NPA-NXX-X Delete request, or generate the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, in the report format listed in RR9-15, RR9-16, RR9-17, and RR9-18, to the screen on the NPAC Administrative Interface. (Previously N-280.1)

RR3-108.2 Deletion of Number Pooling NPA-NXX-X Holder Information –Pending-Like With Active POOL SVs and Pending-Like Port-To-Original SVs Report Selection of Output Destinations

NPAC SMS shall, after displaying the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, allow the NPAC Personnel to choose an output destination for the report. (Previously N-280.2)

RR3-108.3 Deletion of Number Pooling NPA-NXX-X Holder Information –Pending-Like With Active POOL SVs and Pending-Like Port-To-Original SVs Report Output Destinations for Multiple Destinations

NPAC SMS shall, continue to display the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, and allow the NPAC Personnel to choose additional output destinations one at a time, for the report, until the NPAC Personnel requests the closure of the report window. (Previously N-280.3)

RR3-109 Deletion of Number Pooling NPA-NXX-X Holder Information – Output Destination for Pending-Like and Active POOL SVs and Pending-Like Port-To-Original SVs

NPAC SMS shall provide output destination options, as listed in R9-2, for the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, based on the error condition in RR3-108.1. (Previously N-281)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-78 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-110 Deletion of Number Pool NPA-NXX-X Holder Information – Block and Subscription Version Data Dependency

NPAC SMS shall delete the NPA-NXX-X Holder Information for a 1K Block, through a multi-step process that includes: (Previously N-290)

- Broadcasting the delete of SVs to non-EDR Local SMSs.
- - Broadcasting the delete of Blocks to the EDR Local SMSs.
- - Receiving a successful response from all EDR and non-EDR Local SMSs.
- - Updating all SVs and Blocks on the NPAC SMS.
- - Deleting the NPA-NXX-X Holder information from the NPAC SMS.
- - Broadcasting the delete of NPA-NXX-X to the NPA-NXX-X enabled SOAs and Local SMSs.

RR3-111 Deletion of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X Dependency

NPAC SMS shall only delete the NPA-NXX-X Holder Information after successfully updating all associated SVs and Blocks to a status of Old with NO Failed SP List. (Previously N-295)

RR3-112 Deletion of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X With an Associated Block Create Scheduled Event

NPAC SMS shall delete an associated Block Create Scheduled Event, that has not been executed, when deleting the NPA-NXX-X Holder Information. (Previously N-297)

3.11.7 NPA-NXX-X Holder, First Port Notification

RR3-228 Number Pool NPA-NXX-X Holder information notification of First Port

NPAC SMS shall notify all accepting Local SMSs and SOAs of the NPA-NXX, effective date, and owning Service Provider when no porting activity has occurred in the NPA-NXX, immediately after creation of a Number Pooling NPA-NXX-X, including those automatically created by NPA Split processing. (Previously N-330)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-79 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.11.8 NPA-NXX-X Holder, Query

RR3-113 Query of Number Pool NPA-NXX-X Holder Information – NPAC Personnel and Service Provider Personnel

NPAC SMS shall allow NPAC personnel, Service Provider SOA via the SOA to NPAC SMS Interface, Local SMS via the NPAC SMS to Local SMS Interface, or Service Provider SOA via the NPAC SOA Low-tech Interface, to query the NPA-NXX-X holder information for all data as listed in the NPA-NXX-X Holder Information Data Model, for an NPA-NXX-X as stored in the NPAC SMS. (Previously N-340)

RR3-114 Query of Number Pool NPA-NXX-X Holder Information – Return of Queried Data

NPAC SMS shall return to the NPAC Personnel or requesting Service Provider all NPA-NXX-Xs that match the query selection criteria, as listed in the NPA-NXX-X Holder Information Data Model, for an NPA-NXX-X as stored in the NPAC SMS. (Previously N-360)

RR3-115 Query of Number Pool NPA-NXX-X Holder Information – Return of Queried Data to NPAC Personnel Only

NPAC SMS shall provide to NPAC Personnel only, an indicator on the NPAC Administrative Interface, only after completing a query, if an associated Block Create Scheduled Event, that has not been executed, exists in the NPAC SMS. (Previously N-365)

3.11.9 NPA-NXX-X Holder, Bulk Data Download

This section has been MOVED to 3.12.3 NPA-NXX-X Holder, Bulk Data Download. Requirement numbers remain static.

RR3-116

MOVED to section 3.12.3 NPA-NXX-X Holder, Bulk Data Download.

RR3-117 MOVED to section 3.12.3 NPA-NXX-X Holder, Bulk Data Download.

RR3-118

MOVED to section 3.12.3 NPA-NXX-X Holder, Bulk Data Download.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-80 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.12 Block Information

3.12.1 Version Status

[Graphic Omitted: Pool Block Version Status Interaction Diagram]

In the following table, the reference to “Number Pool Block” data when broadcasting to an LSMS is based on that Service Provider’s EDR Indicator (i.e., Number Pool Block object or Subscription Versions with LNP Type of POOL).

Number Pool Block Version Status Interaction Descriptions

#	Interaction Name	Type	Description
1	Creation - Set to Sending	NPAC SMS Internal	NPAC SMS creates a Number Pool Block for the Block Holder Service Provider.
		NPAC Operations Interface — NPAC Personnel	User sends a Number Pool Block creation request for the Block Holder Service Provider.
		SOA to NPAC SMS Interface — Block Holder Service Provider	The Service Provider User sends a Number Pool Block creation request for itself (the Block Holder Service Provider).
2	Sending to Partial Failure	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from sending to partial failure after one or more, but not all, of the Local SMSs fail the Number Pool Block activation after the tunable retry period expires.
3	Partial Failure to Sending	NPAC Operations Interface — NPAC Personnel	User re-sends a partial failure Number Pool Block.
4	Sending to Failed	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from sending to failed after all Local SMSs fail Number Pool Block activation after the tunable retry period expires.
5	Failed to Sending	NPAC Operations Interface — NPAC Personnel	User re-sends a failed Number Pool Block.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-81 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

Number Pool Block Version Status Interaction Descriptions

#	Interaction Name	Type	Description
6	Sending to Active	NPAC SMS Internal		1.	NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block activation is successful in all of the Local SMSs.
				2.	NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block modification is broadcast to all of the Local SMSs and either all have responded or retries have been exhausted.
				3.	NPAC SMS automatically sets a sending Number Pool Block to active after a failure to all Local SMSs on a de-pool.
7	Active to Sending	NPAC Operations Interface — NPAC Personnel		1. 2. 3.	User de-pools an active Number Pool Block. User modifies an active Number Pool Block. User resends a failed de-pool or modify Number Pool Block.

SOA to NPAC SMS Interface — Block Holder Service Provider User modifies an active Number Pool Block.

8	Sending to Old	NPAC SMS Internal	1.	NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool to all Local SMSs successfully completes.
			2.	NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool that fails on one or more, but not all Local SMSs.

9	Old to Sending	NPA Operations Interface – NPAC Personnel	User re-sends a partial failure of a de-pool.
10	Partial Failure to Partial Failure	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-82 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

Number Pool Block Version Status Interaction Descriptions

#	Interaction Name	Type	Description
11	Partial Failure to Active	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from partial failure to active after all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
12	Old to Old	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from old to old after one or more previously failed Local SMSs successfully de-pools a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.

Table 3-14 Number Pool Block Version Status Interaction Descriptions

3.12.2 Block Holder, General

RR3-119 Number Pool Block Holder Information – NPAC Personnel OpGUI

NPAC SMS shall allow NPAC Personnel to add, modify, or query Block Holder information via the NPAC Administrative Interface. (Previously B-10)

RR3-120 Number Pool Block Holder Information – NPAC Customer EDR Indicator Download of Block Object

NPAC SMS shall download Number Pooling Block Information, for additions, modifications, deletions, re-sends, and resync using the Number Pooling Block Object, via the NPAC SMS to Local SMS Interface if the EDR indicator is TRUE, at the time a request is processed by the NPAC SMS. (Previously B-20)

RR3-121 Number Pool Block Holder Information – NPAC Customer EDR Indicator Download of SVs

NPAC SMS shall download Number Pooling Block Information, for additions, modifications, deletions, re-sends, and resyncs, using individual subscription versions with LNP Type of POOL, for the TNs within the range of the 1K Block, via the NPAC SMS to Local SMS Interface if the EDR indicator is FALSE, at the time a request is processed by the NPAC SMS. (Previously B-30)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-83 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-122 Number Pool Block Holder Information – NPAC Customer EDR Indicator For Requests But Not Retries

NPAC SMS shall use the EDR Indicator when processing a request for Number Pooling Block Information, but not during the retry functionality (“x by y” [where “x” is the number of attempts, and “y” is the interval in number of minutes in between attempts]). (Previously B-32)

RR3-123 Number Pool Block Holder Information – Data Integrity for Block and Pooled Subscription Versions

NPAC SMS shall maintain data integrity for LRN and GTT data, between a Number Pooling Block and the corresponding Subscription Versions with LNP Type of POOL in that 1K Block, in the NPAC SMS. (Previously B-34)

RR3-124 Number Pool Block Holder Information – Service Provider Validation

NPAC SMS shall verify the Block Holder SPID attribute of the Block object matches the SPID in the accessControl for SOA Block Activation. (Previously B-40)

RR3-125 Number Pool Block Holder Information – SPID Validation

NPAC SMS shall verify the SPID of the accessControl matches the owner of the association or one of its secondary providers. (Previously
B-50)

RR3-126 Number Pool Block Holder Information – NPA-NXX-X Data Validation

NPAC SMS shall, upon receiving a block activate request, validate that the SPID and the NPA-NXX-X attributes in the request are the same as the SPID and the NPA-NXX-X in a single entry in the NPA-NXX-X Holder Information. (Previously B-60)

RR3-127 Number Pool Block Holder Information – NPA-NXX-X Effective Date

NPAC SMS shall reject a request to create a Block if the current date is prior to the effective date of the Number Pooling NPA-NXX-X as defined in the NPAC SMS. (Previously B-70)

RR3-128 Number Pool Block Holder Information – LRN Validation

NPAC SMS shall validate that the LRN specified in the addition or modification of Number Pooling Block Holder information is a valid LRN defined in the NPAC SMS for the Block Holder. (Previously B-80)

RR3-334 Validation of LATA ID for Number Pool Block Creates

NPAC shall reject Number Pool Block Create Requests if the NPA-NXX of the NPA-NXX-X and the NPA-NXX of the LRN have different LATA IDs. (Previously NANC 319 Req 8)

RR3-335 Validation of LATA ID for Number Pool Block Modifies

NPAC shall reject Number Pool Block Modify Requests if the NPA-NXX of the NPA-NXX-X and the NPA-NXX of the LRN have different LATA IDs. (Previously NANC 319 Req 9)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-84 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-129 Number Pool Block Holder Information – Duplicate Block Validation

NPAC SMS shall validate that the NPA-NXX-X specified in the addition of Number Pooling Block Holder Information does not already exist in the Number Pooling Block Holder Information, except for a status of Old where the Block’s Failed SP List is empty. (Previously B-90)

RR3-130 Number Pool Block Holder Information – SOA Origination Values

NPAC SMS shall set the SOA Origination to TRUE for Blocks sent over the SOA to NPAC SMS Interface or for Blocks sent over the NPAC SOA Low-tech Interface, and to FALSE for Blocks that were created by NPAC personnel, except where the value will be maintained from the Old Block, as a result of an NPA Split. (Previously B-100)

RR3-131 Number Pool Block Holder Information – Validation Error

NPAC SMS shall report an error to the user and reject the addition or modification of Number Pooling Block Holder information if validation errors occur as defined in RR3-124, RR3-125, RR3-126, RR3-127, RR3-128, RR3-129, RR3-146, and RR3-149. (Previously B-110)

RR3-132 Number Pooling Block Holder Information –Update Notification

NPAC SMS shall send all SOA notifications to the current SP (the block holder) for updates on Blocks, when the Block SOA Origination is TRUE. (Previously B-120)

RR3-133 Number Pooling Block Holder Information –Update Notification Suppression

NPAC SMS shall suppress all SOA notifications to the current SP (the block holder) for updates on Blocks, when the Block SOA Origination is FALSE. (Previously B-130)

RR3-134 Number Pooling Block Holder Information – Failed SP List Update for Block for EDR Local SMS

NPAC SMS shall consider an EDR Local SMS to be discrepant and shall update the Block Failed SP List, based on an EDR Local SMS failing to process the Block Object, for an addition, modification, deletion, re-send, resync, or mass update. (Previously B-140)

RR3-135 Number Pooling Block Holder Information – Failed SP List Update for Subscription Versions for non-EDR Local SMS

NPAC SMS shall consider a non-EDR Local SMS to be discrepant and shall update the Block Failed SP List, based on a non-EDR Local SMS failing to process one or more Subscription Versions, with LNP Type of POOL, within the Block, for an addition, modification, deletion, re-send, resync, or mass update. (Previously B-150)

RR3-136 Number Pooling Block Holder Information – Failed SP List Sent to Block Holder

NPAC SMS shall send the Block Failed SP List, to the current SP (the block holder) via the SOA to NPAC SMS Interface, along with the SOA notification for status update of the Block, when the Block SOA Origination is TRUE, and the broadcast to one or more Local SMSs fail. (Previously B-160)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-85 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-137.1 Number Pooling Block Holder Information – Synchronization of Block Status and Subscription Version Status

NPAC SMS shall ensure that the status for Block broadcasts to EDR Local SMSs and Subscription Versions with LNP Type of POOL broadcasts to non-EDR Local SMSs, are synchronized, by performing the following: (Previously B-165.1)

• The status for the Block and Subscription Versions shall cross-reference one another and contain the results of the broadcast of the Block to the EDR Local SMSs, and the broadcast of the Subscription Versions to the non-EDR Local SMSs.

• The status for each Subscription Version shall only be set, once the broadcasts of the Block to all EDR and Subscription Versions to non-EDR Local SMSs has been completed, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted.

• The status for the Block shall only be set, once the broadcasts of the Block to all EDR and Subscription Versions to non-EDR Local SMSs has been completed, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted.

• The status for the Block shall reflect the information contained in Tables RR3-137.2, RR3-137.3, and RR3-137.4.

Key for Tables RR3-137.2, RR3-137.3, and RR3-137.4
Act = Active status
Act/Part = a mix of both Active status and Partial Failure status
Part = Partial Failure status
Part/Fail = a mix of both Partial Failure status and Failed status
Fail = Failed status
Old = Old status
Act/Old = a mix of both Active status and Old status

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-86 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-137.2 Number Pooling Block Holder Information — Synchronization of Block Status and Subscription Version Status for Block Creation

NPAC SMS shall set the status of a Block for Block Creation, based on the data contained in Table RR3-137.2. (Previously B-165.2)

Table RR3-137.2 - Block Creation

EDR Local SMS

Non-EDR Local SMS

some but not

all non-EDR

Local SMSs

all non-EDR

respond

Local SMSs

all non-EDR

successfully to

fail a given

some but not

none of the

some but not

none of the

Local SMSs

a given SV,

SV, but

all non-EDR

non-EDR

all EDR Local

all EDR Local

EDR Local

respond

but all respond

respond

Local SMSs

Local SMSs

All Pooled

SMSs respond

SMSs respond

SMSs respond

successfully to

successfully to

successfully to

fail all Pooled

respond

SVs in the

successfully

successfully

successfully

all SVs

another SV

another SV

SVs

successfully

Block

Block

1

4

4

Act

Act

2

4

4

Act/Part

Part

3

4

4

Part

Part

4

4

4

Part

Part

5

4

4

Part

Part

6

4

4

Part

Part

7

4

4

Part

Part

8

4

4

Part

Part

9

4

4

Part

Part

10

4

4

Part

Part

11

4

4

Part

Part

12

4

4

Part

Part

13

4

4

Part/Fail

Part

14

4

4

Part

Part

15

4

4

Fail

Fail

Requirement Table 3-1, RR3-137.2 — Block Creation

As a summary of the table, the Block’s status will be set on Creation to:

• Active, if ALL EDR and non-EDR Local SMSs respond successfully.

• Failed, if ALL EDR and non-EDR Local SMSs respond unsuccessfully, or retries are exhausted.

• Partial Failure, for all other cases.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-87 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-137.3 Number Pooling Block Holder Information — Synchronization of Block Status and Subscription Version Status for Block Modification

NPAC SMS shall set the status of a Block for Block Modification, based on the data contained in Table RR3-137.3. (Previously B-165.3)

Table RR3-137.2 - Block Creation

EDR Local SMS

Non-EDR Local SMS

some but not

all non-EDR

Local SMSs

all non-EDR

respond

Local SMSs

all non-EDR

successfully to

fail a given

some but not

none of the

some but not

none of the

Local SMSs

a given SV,

SV, but

all non-EDR

non-EDR

all EDR Local

all EDR Local

EDR Local

respond

but all respond

respond

Local SMSs

Local SMSs

All Pooled

SMSs respond

SMSs respond

SMSs respond

successfully to

successfully to

successfully to

fail all Pooled

respond

SVs in the

successfully

successfully

successfully

all SVs

another SV

another SV

SVs

successfully

Block

Block

1

4

4

Act

Act

2

4

4

Act

Act

3

4

4

Act

Act

4

4

4

Act

Act

5

4

4

Act

Act

6

4

4

Act

Act

7

4

4

Act

Act

8

4

4

Act

Act

9

4

4

Act

Act

10

4

4

Act

Act

11

4

4

Act

Act

12

4

4

Act

Act

13

4

4

Act

Act

14

4

4

Act

Act

15

4

4

Act

Act

Requirement Table 3-2, RR3-137.3 — Block Modification

As a summary of the table, the Block’s status will be set on Modification to:

• Active, for all cases.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-88 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-137.4 Number Pooling Block Holder Information — Synchronization of Block Status and Subscription Version Status for Block Deletion

     NPAC SMS shall set the status of a Block for Block Deletion, based on the data contained in Table RR3-137.4. (Previously B-165.4)

Table RR3-137.4 - Block Deletion

EDR Local SMS

Non-EDR Local SMS

some but not

all non-EDR

Local SMSs

all non-EDR

respond

Local SMSs

all non-EDR

successfully to

fail a given

some but not

none of the

some but not

none of the

Local SMSs

a given SV,

SV, but

all non-EDR

non-EDR

all EDR Local

all EDR Local

EDR Local

respond

but all respond

respond

Local SMSs

Local SMSs

All Pooled

SMSs respond

SMSs respond

SMSs respond

successfully to

successfully to

successfully to

fail all Pooled

respond

SVs in the

successfully

successfully

successfully

all SVs

another SV

another SV

SVs

successfully

Block

Block

1

4

4

Old

Old

2

4

4

Old

Old

3

4

4

Old

Old

4

4

4

Old

Old

5

4

4

Old

Old

6

4

4

Old

Old

7

4

4

Old

Old

8

4

4

Old

Old

9

4

4

Old

Old

10

4

4

Old

Old

11

4

4

Old

Old

12

4

4

Old

Old

13

4

4

Act/Old

Old

14

4

4

Old

Old

15

4

4

Act

Act

Requirement Table 3-3, RR3-137.4 — Block Deletion

As a summary of the table, the Block’s status will be set on Deletion to:

• Active, if ALL EDR and non-EDR Local SMSs respond unsuccessfully, or retries are exhausted.

• Old, for all other cases.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-89 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-138.1 Number Pooling Block Holder Information — Synchronization of Block Failed SP List and Subscription Version Failed SP List

NPAC SMS shall ensure that the Block Failed SP List and the Subscription Versions Failed SP Lists for Block broadcasts to EDR Local SMSs and Subscription Versions broadcasts to non-EDR Local SMSs, are synchronized, by performing the following: (Previously B-166.1)

• The Block Failed SP List for the Block and Subscription Versions Failed SP Lists for the Subscription Versions shall cross-reference one another and contain the results of the broadcast of the Block to the EDR Local SMSs, and the broadcast of the Subscription Versions to the non-EDR Local SMSs.

• The Subscription Versions Failed SP Lists for the Subscription Versions shall be set, based on the results of the Block broadcasts to all EDR Local SMSs and the Subscription Version broadcasts to all non-EDR Local SMSs, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted, for Activations, Modifications, and Deletions.

• The Block Failed SP List for the Block shall be set, based on the results of the Block broadcasts to all EDR Local SMSs and the Subscription Version broadcasts to all non-EDR Local SMSs, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted.

• The Block Failed SP List for the Block shall be based on the summary of all Subscription Versions with LNP Type of POOL within the 1K Block.

• The Block Failed SP List for the Block shall reflect the information contained in Table RR3-138.2.

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-90 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-138.2 Number Pooling Block Holder Information — Synchronization of Block Failed SP List and Subscription Version Failed SP List for Block Creation, Modification, or Deletion

NPAC SMS shall set the Block Failed SP List of a Block for updates, based on the data contained in Table RR3-138.2. (Previously B-166.2)

Table RR3-138.2

Failed SP List

EDR Local SMS

Non-EDR Local SMS

some but not

all non-EDR

Local SMSs

all non-EDR

respond

Local SMSs

all non-EDR

successfully to

fail a given

some but not

none of the

some but not

none of the

Local SMSs

a given SV,

SV, but

all non-EDR

non-EDR

all EDR Local

all EDR Local

EDR Local

respond

but all respond

respond

Local SMSs

Local SMSs

All Pooled

SMSs respond

SMSs respond

SMSs respond

successfully to

successfully to

successfully to

fail all Pooled

respond

SVs in the

successfully

successfully

successfully

all SVs

another SV

another SV

SVs

successfully

Block

Block

1

4

4

ZFSL

ZFSL

2

4

4

Z/S FSL

SFSL

3

4

4

SFSL

SFSL

4

4

4

SFSL

SFSL

5

4

4

SFSL

SFSL

6

4

4

SFSL

SFSL

7

4

4

SFSL

SFSL

8

4

4

SFSL

SFSL

9

4

4

SFSL

SFSL

10

4

4

SFSL

SFSL

11

4

4

SFSL

SFSL

12

4

4

SFSL

SFSL

13

4

4

S/A FSL

SFSL

14

4

4

SFSL

SFSL

15

4

4

AFSL

AFSL

Requirement Table 3-4, RR3-138.2 — Failed SP List

Key for Table RR3-138.2
ZFSL = Zero Failed SP List (no SPs in the list)
Z/S FSL = Zero/Some Failed SP List (mix of both Zero Failed SP List and Some Failed SP List)
SFSL = Some but not all Failed SP List (some but not all SPs in the list)
S/A FSL = Some/All Failed SP List (mix of both Some Failed SP List and All Failed SP List)
AFSL = All Failed SP List (all SPs in the list)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-91 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-139 Number Pooling Block Holder Information – Synchronization of Block Failed SP List and Subscription Version Failed SP List for the last failed Subscription Version in the 1K Block

NPAC SMS shall remove a non-EDR Service Provider from the Block Failed SP List when the Service Provider is no longer on the Subscription Version Failed SP List for ALL subscription versions in the 1K Block. (Previously B-167)

RR3-140 Number Pooling Block Holder Information – Synchronization of Block Failed SP List and Subscription Version Failed SP List for the Block

NPAC SMS shall remove an EDR Service Provider from ALL subscription versions’ Failed SP List when the Service Provider is no longer on the Block Failed SP List. (Previously B-168)

RR3-141.1 Number Pooling Block Holder Information – Unique Error Message for Partial Failure or Failed Status Update to a Block for Block Activation Requests Initiated by NPAC Personnel

NPAC SMS shall generate a unique alarmable error message when a Block’s status is initially set to either Partial Failure or Failed, for Block Activation requests initiated by NPAC Personnel. (Previously B-169.1.1)

RR3-141.3 Number Pooling Block Holder Information – Unique Error Message for Active Status With a Failed SP List Update to a Block

NPAC SMS shall generate a unique alarmable error message when a Block’s status is updated to Active with a Failed SP List, for each occurrence, for Block Modification requests initiated by NPAC Personnel. (Previously B-169.2)

RR3-141.4 Number Pooling Block Holder Information – Unique Error Message for Old Status With a Failed SP List Update to a Block

NPAC SMS shall generate a unique alarmable error message when a Block’s status is updated to Old with a Failed SP List, for Block Deletion requests that were initiated through the NPA-NXX-X deletion by NPAC Personnel. (Previously B-169.3)

RR3-142.1 Number Pooling Block Holder Information – Block Broadcast Monitoring Mechanism

NPAC SMS shall provide a mechanism to send a recurring page to NPAC Personnel, based on a configurable interval, when a unique alarmable error message is generated as defined in RR3-141.1, RR3-141.3, or RR3-141.4. (Previously B-169.6)

Note: The configurable interval will be set by M&P.

RR3-142.2 Number Pooling Block Holder Information – Block Broadcast Monitoring Mechanism Completion

NPAC SMS shall provide a mechanism to stop the recurring page to NPAC Personnel, whenever the Block’s status is set to Active AND the Block Failed SP List is empty, or, the Block’s status is set to Old AND the Block Failed SP List is empty. (Previously B-169.7)

RR3-143 Number Pool Block Holder Information – Filters for Blocks

NPAC SMS shall apply NPA-NXX Filters to Block broadcasts to the Local SMS(s). (Previously B-560)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-92 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

3.12.3 Block Holder, Addition

RR3-144 Addition of Number Pooling Block Holder Information

NPAC SMS shall allow NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to request the creation of a Number Pooling Block. (Previously B-170)

RR3-145 Addition of Number Pool Block Holder Information – Rejected from LSMS

NPAC SMS shall reject a request to create a Block by a Service Provider via the NPAC SMS to Local SMS Interface, and will return an error message to the LSMS. (Previously B-175)

RR3-146 Addition of Number Pooling Block Holder Information – Required Data

NPAC SMS shall require NPAC personnel or Service Provider via the SOA to NPAC SMS Interface to specify the Block Holder SPID, the NPA-NXX-X, and the initial routing information, as defined in the Number Pooling Block Holder Information. (Previously B-180)

RR3-147 Addition of Number Pooling Block Holder Information – Check for pending-like SVs for NPAC Personnel

NPAC SMS shall reject the request and issue a unique alarmable error message to the NPAC personnel at the time of Block Creation for an NPAC initiated request, from the NPAC Administrative Interface, if there are any TNs within the 1K Block, that contain an SV, with a status of pending/conflict/cancel-pending/failed, and where a currently active SV does NOT exist, for the given TN. (Previously B-190)

RR3-148 Addition of Number Pooling Block Holder Information – Error Message to SOA for pending-like SVs

NPAC SMS shall reject the request and issue an error message to the SOA at the time of Block Creation from the SOA via the SOA to NPAC SMS Interface, if there are any TNs within the 1K Block, that contain an SV, for a given TN in the 1K Block, with a status of pending/conflict/cancel-pending/failed, and where a currently active SV does NOT exist, for the given TN. (Previously B-210)

RR3-149 Addition of Number Pooling Block Holder Information – Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, is valid according to the formats specified in the Subscription Version Data Model upon Block creation for a Number Pool: (Previously B-250, reference NANC 399)

NPA-NXX-X Holder SPID
NPA-NXX-X
LRN
Class DPC
Class SSN
LIDB DPC
LIDB SSN
CNAM DPC
CNAM SSN
ISVM DPC

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-93 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

ISVM SSN
WSMSC DPC (if supported by the Block Holder SOA)
WSMSC SSN (if supported by the Block Holder SOA)
Number Pool Block SV Type (if supported by the Block Holder SOA)
Alternative SPID (if supported by the Block Holder SOA)

RR3-150 Addition of Number Pooling Block Holder Information – Broadcast of Block Data

NPAC SMS shall, upon successfully creating a Block, set the Block’s status to sending, and broadcast an addition of a Block, to EDR Local SMSs, via the NPAC SMS to Local SMS Interface. (Previously B-260)

RR3-151 Addition of Number Pooling Block Holder Information – Activation Broadcast Complete Timestamp Update

NPAC SMS shall update the Activation Broadcast Complete Timestamp of the Block upon completion of the broadcast, and the FIRST successful response, for either an EDR or non-EDR Local SMS. (Previously B-265)

RR3-152 Addition of Number Pooling Block Holder Information – Status Update

NPAC SMS shall update the status of the Block upon completion of the Activation broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.2. (Previously B-270)

RR3-153 Addition of Number Pooling Block Holder Information – Failed SP List Update

NPAC SMS shall update the Block Failed SP List upon completion of the Activation broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1, and RR3-138.2. (Previously B-275)

RR3-496 Activate Number Pool Block — Send Number Pool Block SV Type Data to Local SMSs

NPAC SMS shall, for a Service Provider that supports SV Type data, send the Number Pool Block SV Type attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 15)

RR3-497 Activate Number Pool Block — Send Alternative SPID to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alternative SPID, send the Alternative SPID attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 16)

3.12.4 Block Holder, Modification

NPAC SMS shall allow NPAC Personnel to modify the SOA Origination Indicator on the NPAC Block record, via the NPAC Administrative Interface. (Previously B-315)

Release 3.3: © 1997 — 2006 NeuStar, Inc. 3-94 North American Numbering Council (NANC)
Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC Data Administration

RR3-155 Block’s SOA Origination Indicator — Suppress Broadcast

NPAC SMS shall suppress the broadcast to a Local SMS, of a modification to a Block’s SOA Origination Indicator. (Previously B-317)

RR3-156 Block’s SOA Origination Indicator — Suppress Creation When False

NPAC SMS shall suppress the creation of a Block modification notification, when the Block’s SOA Origination Indicator is modified to FALSE. (Previously B-318)

RR3-157 Modification of Number Pooling Block Holder Information — Routing Data

NPAC SMS shall allow NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to modify the block holder default routing information (LRN, DPC(s), and SSN(s)), Number Pool Block SV Type (if supported by the Block Holder SOA), and, Alternative SPID (if supported by the Block Holder SOA), for a 1K Block as stored in the NPAC SMS. (Previously B-320, reference NANC 399)

RR3-158 Modification of Number Pool Block Holder Information — Rejected from LSMS

NPAC SMS shall reject a request to modify a Block by a Service Provider via the NPAC SMS to Local SMS Interface, and will return an error message to the LSMS. (Previously B-325)

RR3-159 Modification of Number Pooling Block Holder Information — SPID Validation

NPAC SMS shall allow a Service Provider via the SOA to NPAC SMS Interface or Service Provider via the NPAC SOA Low-tech Interface, to modify Block data for Blocks where the Block Holder SPID matches the Service Provider making the request. (Previously B-330)

RR3-160 Modification of Number Pooling Block Holder Information — Selection Criteria

NPAC SMS shall allow a Service Provider via the SOA to NPAC SMS Interface, to modify Block data by specifying either Block ID, or NPA-NXX-X value and status, in the request. (Previously B-332)

RR3-161 Modification of Number Pooling Block Holder Information — Current status and Failed SP List

NPAC SMS shall reject and issue an error message to NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, when modifying block holder data, for a 1K Block as stored in the NPAC SMS, and the Block’s current status is not active, or the Block has at least one Service Provider in the Failed SP List. (Previously B-335)

RR3-162 Modification of Number Pooling Block Holder Information — Sending Status Update

NPAC SMS shall, upon processing a valid request to modify a Block, update the status of the Block, at the start of the broadcast of a Block modification to the Local SMSs, from an active status to a sending status. (Previously B-340)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-95	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-163 Modification of Number Pooling Block Holder Information — Broadcast of Block Data

NPAC SMS shall, upon successfully modifying a Block and setting the Block’s status to sending, broadcast a modification of a Block to EDR Local SMSs, via the NPAC SMS to Local SMS Interface. (Previously B-350)

RR3-164 Modification of Number Pooling Block Holder Information — Modify Broadcast Complete Timestamp Update

NPAC SMS shall update the Modify Broadcast Complete Timestamp of the Block upon completion of the broadcast, and the FIRST successful response, for either an EDR or non-EDR Local SMS. (Previously B-355)

RR3-165 Modification of Number Pooling Block Holder Information —Status Update

NPAC SMS shall update the status of the Block upon completion of the Modification broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.3. (Previously B-360)

RR3-166 Modification of Number Pooling Block Holder Information — Failed SP List Update

NPAC SMS shall update the Block Failed SP List upon completion of the broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1, and 3-138.2. (Previously B-370)

RR3-167 Modification of Number Pooling Block Holder Information — Creation of Old Block

DELETED

RR3-168 Modification of Number Pooling Block Holder Information — Old Block No Broadcast

DELETED

3.12.5 Block Holder, Deletion

RR3-169 Deletion of Number Pool Block Holder Information — NPAC

NPAC SMS shall not allow NPAC Personnel to request a delete of a Block in the NPAC SMS.

Note: This is initiated at the NPA-NXX-X level, and is part of a multi-step “cascading delete” process. (Previously B-400)

RR3-170 Deletion of Number Pool Block Holder Information — SOA

NPAC SMS shall reject a request to delete a Block by a Service Provider via the SOA to NPAC SMS interface, and will return an error message to the SOA. (Previously B-410)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-96	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-171 Deletion of Number Pool Block Holder Information — Rejected from LSMS

NPAC SMS shall reject a request to delete a Block by a Service Provider via the NPAC SMS to Local SMS Interface, and will return an error message to the LSMS. (Previously B-412)

RR3-172 Deletion of Number Pool Block Holder Information — LTI

NPAC SMS shall not allow Service Provider Personnel to request a delete of a Block in the NPAC SMS via the NPAC SOA Low-tech Interface. (Previously B-415)

RR3-173 Deletion of Number Pooling NPA-NXX-X Holder Information — Sending Status Update to Block

NPAC SMS shall, upon processing a valid request to delete an NPA-NXX-X, update the status of the Block at the start of the broadcast to the Local SMSs, from an active status to a sending status. (Previously B-430)

RR3-174 Deletion of Number Pool NPA-NXX-X Holder Information — Broadcast of Block Data

NPAC SMS shall, upon setting the Block’s status to sending, broadcast a delete of a Block, to EDR LSMSs, via the NPAC SMS to Local SMS Interface. (Previously B-440)

RR3-175 Deletion of Number Pooling Block Holder Information — Disconnect Complete Timestamp Update

NPAC SMS shall update the Disconnect Complete Timestamp of the Block upon completion of the broadcast, and the FIRST successful response, for either an EDR or non-EDR Local SMS. (Previously B-445)

RR3-176 Deletion of Number Pooling NPA-NXX-X Holder Information — Status Update to Block

NPAC SMS shall update the status of the Block upon completion of the Deletion broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.4. (Previously B-450)

RR3-177 Deletion of Number Pooling NPA-NXX-X Holder Information — Failed SP List Update

NPAC SMS shall update the Block Failed SP List upon completion of the broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1, and RR3-138.2. (Previously B-480)

RR3-178 Deletion of Number Pooling NPA-NXX-X Holder Information — Creation of Old Block

DELETED

RR3-179 Deletion of Number Pooling NPA-NXX-X Holder Information — Old Block No Broadcast

DELETED

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-97	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

3.12.6 Block Holder, Query

RR3-180 Query of Number Pool Block Holder Information — NPAC Personnel

NPAC SMS shall allow NPAC Personnel to query the block holder information for all data as listed in the Block Holder Information Data Model, for a 1K Block as stored in the NPAC SMS. (Previously B-555)

RR3-181 Query of Number Pool Block Holder Information — Service Provider Personnel

NPAC SMS shall allow a Service Provider SOA via the SOA to NPAC SMS Interface, Service Provider Local SMS via the NPAC SMS to Local SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to query Block Holder Information, regardless of the value in the requesting Service Provider’s EDR Indicator. (Previously B-556)

RR3-182 Query of Number Pool Filtered Block Holder Information — Query Block

NPAC SMS shall return, to the NPAC Personnel or requesting Service Provider, all Block data supported by the requestor that match the query selection criteria. (Previously B-557)

3.12.7 Block Holder, Default Routing Restoration

RR3-183 Number Pool Block Holder Information Use of Number Pool Default Routing Information — Existing Block

The NPAC SMS shall use the default routing restoration information in the Number Pooling Block Holder Information as the block holder default routing, when a ported pooled number is disconnected or port to original port is activated, and returns the TN(s) to the block, once the Block exists, except for Old with or without a Failed SP List. (Previously B-570)

RR3-184 Number Pool Block Holder Information Use of Number Pool Notification of TN Re-assignment — During De-Pooling

The NPAC SMS shall send a notification to the Code Holder, and suppress the notification to the Block Holder, when a ported pooled number is disconnected, for TN(s) in the block, when the Block is being de-pooled, and the most recent block contains a status of Old, with a Failed SP List. (Previously B-571)

Note: The notifications characteristics for a disconnect of a ported pooled number, during de-pooling of a Block, with a Block that contains a status of Old with a Failed SP List, is additional functionality that defines Code Holder responsibility and notification messages. In essence, even though the de-pooled Block (i.e., contains a status of Old with a Failed SP List) is post-effective date, it has the behavior of a Block that has NOT been pooled and is in a pre-effective date stage. Also, the customer disconnect date notification is going to the Code Holder, but the TN cannot be re-assigned in their inventory.

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-98	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

3.12.8 Block Holder, Re-Send

RR3-185 Re-Send of Number Pool Block Holder Information — Filters for Blocks

NPAC SMS shall apply NPA-NXX Filters to Block re-sends to the Local SMS(s). (Previously B-574)

RR3-186.1 Re-Send of Number Pooling Block Holder Information — NPAC Personnel OpGUI Single Block

NPAC SMS shall allow NPAC Personnel to re-send Block Information, one Block at a time, via the NPAC Administrative Interface. (B-575.1)

RR3-186.2 Re-Send of Number Pooling Block Holder Information — NPAC Personnel OpGUI One or All Service Providers

NPAC SMS shall allow NPAC Personnel to re-send Block Information, to a single Service Provider or all Service Providers in the Block Failed SP List, via the NPAC Administrative Interface. (Previously B-575.2)

RR3-187 Re-Send of Number Pooling Block Holder Information — Use of EDR Indicator for Re-Send data

NPAC SMS shall use the value in the Service Provider’s EDR Indicator to determine the type of data to re-send to the Service Provider, when a re-send request is initiated. (Previously B-576)

RR3-188 Re-Send of Number Pooling Block Holder Information — Re-Send to EDR Local SMS

NPAC SMS shall re-send Block Information to an EDR Local SMS, by re-sending the previously failed Block Object, via the NPAC SMS to Local SMS Interface. (Previously B-577)

RR3-189 Re-Send of Number Pooling Block Holder Information — Re-Send to non-EDR Local SMS

NPAC SMS shall re-send Block Information to a non-EDR Local SMS, by re-sending the previously failed Subscription Version(s), via the NPAC SMS to Local SMS Interface. (Previously B-578)

RR3-190 Re-Send of Number Pooling Block Holder Information — Failed Block Status Set to Sending

NPAC SMS shall update the status of the failed Block, specified in the re-send request, at the start of the re-send to the Local SMSs, from a failed status to a sending status. (Previously B-580)

RR3-191 Re-Send of Number Pooling Block Holder Information — Partial Failure Block Status Set to Sending

NPAC SMS shall update the status of the partial failure Block, specified in the re-send request, at the start of the re-send to the Local SMSs, from a partial failure status to a sending status. (Previously B-590)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-99	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-192 Re-Send of Number Pooling Block Holder Information — Sending Status Update to Active Block

NPAC SMS shall update the status of the active Block, with a Failed SP List, specified in the re-send request, at the start of the re-send to the Local SMSs, from an active status to a sending status. (Previously B-600)

RR3-193 Re-Send of Number Pooling Block Holder Information — Sending Status Update to Old Block

NPAC SMS shall update the status of the old Block, with a Failed SP List, specified in the re-send request, at the start of the re-send to the Local SMSs, from an old status to a sending status. (Previously B-610)

RR3-194 Re-Send of Number Pool Block Holder Information — Broadcast of Block Data

NPAC SMS shall, upon setting the Block’s status to sending, broadcast a re-send of a Block, to EDR LSMSs, via the NPAC SMS to Local SMS Interface. (Previously B-620)

RR3-195 Re-Send of Number Pooling Block Holder Information — Update to Failed SP List

NPAC SMS shall update the Block Failed SP List of the Block and the Subscription Version Failed SP List of each Subscription Version with LNP Type of POOL, by removing the previously failed Local SMS, upon a successful re-send to a previously failed Local SMS. (Previously B-630)

RR3-196 Re-Send of Number Pooling Block Holder Information —Status Update to Block after Re-Send

NPAC SMS shall update the status of the Block, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS or if retries have been exhausted, from a sending status, as defined in RR3-137.1, RR3-137.2, RR3-137.3, and RR3-137.4. (Previously B-635)

RR3-197 Re-Send of Number Pooling Block Holder Information — Failed SP List Update

NPAC SMS shall update the Block Failed SP List, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS or if retries have been exhausted, as defined in RR3-138.1, and RR3-138.2. (Previously B-636)

RR3-472 Number Pool Block Failed SP List — Exclusion of a Service Provider from Resend

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to request that a Service Provider be excluded from the Number Pool Block Failed SP List when resending a number pool block and the associated subscription version(s) of LNP type POOL, and not broadcast to the Service Provider that is excluded. (previously NANC 300, Req 1)

RR3-473 Number Pool Block Failed SP List — Logging of an Excluded Service Provider

NPAC SMS shall log the following information when a Service Provider is excluded from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface: date, time, excluded SPID, Blockholder SPID, NPA-NXX-X, Number Pool Block ID. (previously NANC 300, Req 2)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-100	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

3.12.9 Block Holder, Bulk Data Downloads

This section has MOVED to section 3.12.5 Block Holder, Bulk Data Downloads. Requirement numbers remain static.

RR3-198	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-199	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-200.1	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-200.2	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-200.3	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-201.1	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-201.2	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-202	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-203	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-204)	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-205	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-206	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.
RR3-207	MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.

3.13 Linked Action Replies

The following section defines tunable parameters that enable Linked Action Replies to be sent to Service Provider systems that support this functionality, during recovery. The actual Linked Reply functionality is discussed specifically within the Recovery section of this document.

RR3-336 NPAC Customer SOA Linked Replies Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving Service Provider, Network and Notification Recovery Responses as Linked Replies to their SOA, via the SOA to NPAC SMS Interface. (Previously NANC 187 Req 1)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-101	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-337 NPAC Customer SOA Linked Replies Indicator — Default

NPAC SMS shall default the SOA Linked Replies Indicator to FALSE. (Previously NANC 187 Req 2)

RR3-338 NPAC Customer SOA Linked Replies Indicator — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the SOA Linked Replies Indicator on the NPAC Customer record. (Previously NANC 187 Req 3)

RR3-339 NPAC Customer Local SMS Linked Replies Indicator

NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving Service Provider, Network, Subscription, and Notification Recovery Responses as Linked Replies to their Local SMS, via the NPAC SMS to Local SMS Interface. (Previously NANC 187 Req 6)

RR3-340 NPAC Customer Local SMS Linked Replies Indicator — Default

NPAC SMS shall default the Local SMS Linked Replies Indicator to FALSE. (Previously NANC 187 Req 7)

RR3-341 NPAC Customer Local SMS Linked Replies Indicator — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Local SMS Linked Replies Indicator on the NPAC Customer record. (Previously NANC 187 Req 8)

RR3-342 Service Provider and Network Data Linked Replies Blocking Factor — Tunable Parameter

NPAC SMS shall provide a Service Provider and Network Data Linked Replies Blocking Factor tunable parameter which is defined as the number of objects in a single linked reply sent in response to a service provider or network data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 12)

RR3-343 Service Provider and Network Data Linked Replies Blocking Factor — Tunable Parameter Default

NPAC SMS shall default the Service Provider and Network Data Linked Replies Blocking Factor tunable parameter to fifty (50) objects. (Previously NANC 187 Req 13)

RR3-344 Service Provider and Network Data Linked Replies Blocking Factor — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider and Network Data Linked Replies Blocking Factor tunable parameter. (Previously NANC 187 Req 14)

RR3-345 Subscription Data Linked Replies Blocking Factor — Tunable Parameter

NPAC SMS shall provide a Subscription Data Linked Replies Blocking Factor tunable parameter which is defined as the number of objects in a single linked reply sent in response to a subscription data recovery request sent by a LSMS, when the LSMS supports Linked Replies. (Previously NANC 187 Req 17)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-102	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-346 Subscription Data Linked Replies Blocking Factor — Tunable Parameter Default

NPAC SMS shall default the Subscription Data Linked Replies Blocking Factor tunable parameter to fifty (50) objects. (Previously NANC 187 Req 18)

RR3-347 Subscription Data Linked Replies Blocking Factor — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Subscription Data Linked Replies Blocking Factor tunable parameter. (Previously NANC 187 Req 19)

RR3-348 Notification Data Linked Replies Blocking Factor — Tunable Parameter

NPAC SMS shall provide a Notification Data Linked Replies Blocking Factor tunable parameter which is defined as the number of notifications in a single linked reply sent in response to a notification data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 21)

RR3-349 Notification Data Linked Replies Blocking Factor — Tunable Parameter Default

NPAC SMS shall default the Notification Data Linked Replies Blocking Factor tunable parameter to fifty (50) notifications. (Previously NANC 187 Req 22)

RR3-350 Notification Data Linked Replies Blocking Factor — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Notification Data Linked Replies Blocking Factor tunable parameter. (Previously NANC 187 Req 23)

RR3-430 Number Pool Block Data Linked Replies Blocking Factor — Tunable Parameter

NPAC SMS shall provide a Number Pool Block Data Linked Replies Blocking Factor tunable parameter which is defined as the number of objects in a single linked reply sent in response to a number pool block data recovery request sent by a LSMS, when the LSMS supports Linked Replies. (Previously related to NANC 187)

RR3-431 Number Pool Block Data Linked Replies Blocking Factor — Tunable Parameter Default

NPAC SMS shall default the Number Pool Block Data Linked Replies Blocking Factor tunable parameter to fifty (50) objects. (Previously related to NANC 187)

RR3-432 Number Pool Block Data Linked Replies Blocking Factor — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Number Pool Block Data Linked Replies Blocking Factor tunable parameter. (Previously related to NANC 187).

RR3-351 Service Provider and Network Data Maximum Linked Recovered Objects — Tunable Parameter

NPAC SMS shall provide a Service Provider and Network Data Maximum Linked Recovered Objects tunable parameter which is defined as the maximum number of objects sent in response to service provider or network data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 26)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-103	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-352 Service Provider and Network Data Maximum Linked Recovered Objects — Tunable Parameter Default

NPAC SMS shall default the Service Provider and Network Data Maximum Linked Recovered Objects tunable parameter to ten thousand (10,000) objects. (Previously NANC 187 Req 27)

RR3-353 Service Provider and Network Data Maximum Linked Recovered Objects — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider and Network Data Maximum Linked Recovered Objects tunable parameter. (Previously NANC 187 Req 28)

RR3-354 Subscription Data Maximum Linked Recovered Objects — Tunable Parameter

NPAC SMS shall provide a Subscription Data Maximum Linked Recovered Objects tunable parameter which is defined as the maximum number of objects sent in response to a subscription data recovery request sent by an LSMS, when the LSMS supports Linked Replies. (Previously NANC 187 Req 31)

RR3-355 Subscription Data Maximum Linked Recovered Objects — Tunable Parameter Default

NPAC SMS shall default the Subscription Data Maximum Linked Recovered Objects tunable parameter to ten thousand (10,000) objects. (Previously NANC 187 Req 32)

RR3-356 Subscription Data Maximum Linked Recovered Objects — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Subscription Data Maximum Linked Recovered Objects tunable parameter. (Previously NANC 187 Req 33)

RR3-357 Notification Data Maximum Linked Recovered Notifications — Tunable Parameter

NPAC SMS shall provide a Notification Data Maximum Linked Recovered Notifications tunable parameter which is defined as the maximum number of notifications sent in response to a notification data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 35)

RR3-358 Notification Data Maximum Linked Recovered Notifications — Tunable Parameter Default

NPAC SMS shall default the Notification Data Maximum Linked Recovered Notifications tunable parameter to two thousand (2,000) notifications. (Previously NANC 187 Req 36)

RR3-359 Notification Data Maximum Linked Recovered Notifications — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Notification Data Maximum Linked Recovered Notifications tunable parameter. (Previously NANC 187 Req 37)

RR3-433 Number Pool Block Data Maximum Linked Recovered Objects — Tunable Parameter

NPAC SMS shall provide a Number Pool Block Data Maximum Linked Recovered Objects tunable parameter which is defined as the maximum number of objects sent in response to a number pool block recovery request sent by an LSMS, when the LSMS supports Linked Replies. (Previously related to NANC 187)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-104	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-434 Number Pool Block Data Maximum Linked Recovered Objects — Tunable Parameter Default

NPAC SMS shall default the Number Pool Block Data Maximum Linked Recovered Objects tunable parameter to ten thousand (10,000) objects. (Previously related to NANC 187).

RR3-435 Number Pool Block Data Maximum Linked Recovered Objects — Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Number Pool Block Data Maximum Linked Recovered Objects tunable parameter. (Previously related to NANC 187)

3.14 GTT Validation Processing by the NPAC SMS

This section describes how the NPAC SMS performs a variety of GTT validation for Subscription Versions and Number Pool Blocks in an effort to support SS7 signaling guidelines for Local Number Portability. Some GTT validation occurs based on regional tunables that reflect inter-Service Provider service level agreements, while other validations occur globally regardless of any tunable setting.

3.14.1 Sub System Number (SSN) Edit Flag Indicator

The following section defines tunable parameters that allow the NPAC SMS to impose edits and prevent Subscription Version and Number Pool Block processing that contain GTT data that cannot be processed by certain Service Providers based on regional agreements. These indicators are set and applied regionally. This section also identifies how the NPAC SMS applies GTT validation to Subscription Version and Number Pool Block processing based on the indicator settings.

RR3-360 DPC/SSN Edits — CLASS SSN Edit Flag Indicator

NPAC SMS shall provide a CLASS SSN Edit Flag Indicator, which is defined as an indicator on whether or not CLASS DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 1)

RR3-361 DPC/SSN Edits — LIDB SSN Edit Flag Indicator

NPAC SMS shall provide a LIDB SSN Edit Flag Indicator, which is defined as an indicator on whether or not LIDB DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 2)

RR3-362 DPC/SSN Edits — CNAM SSN Edit Flag Indicator

NPAC SMS shall provide a CNAM SSN Edit Flag Indicator, which is defined as an indicator on whether or not CNAM DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 3)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-105	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-363 DPC/SSN Edits — ISVM SSN Edit Flag Indicator

NPAC SMS shall provide a ISVM SSN Edit Flag Indicator, which is defined as an indicator on whether or not ISVM DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 4)

RR3-364 DPC/SSN Edits — WSMSC SSN Edit Flag Indicator

NPAC SMS shall provide a WSMSC SSN Edit Flag Indicator, which is defined as an indicator on whether or not WSMSC DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 5)

RR3-365 DPC/SSN Edits — CLASS SSN Edit Flag Indicator — OpGUI Modification

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the CLASS SSN Edit Flag Indicator. (Previously NANC 291 Req 11)

RR3-366 DPC/SSN Edits — LIDB SSN Edit Flag Indicator — OpGUI Modification

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the LIDB SSN Edit Flag Indicator. (Previously NANC 291 Req 12)

RR3-367 DPC/SSN Edits — CNAM SSN Edit Flag Indicator — OpGUI Modification

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the CNAM SSN Edit Flag Indicator. (Previously NANC 291 Req 13)

RR3-368 DPC/SSN Edits — ISVM SSN Edit Flag Indicator — OpGUI Modification

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the ISVM SSN Edit Flag Indicator. (Previously NANC 291 Req 14)

RR3-369 DPC/SSN Edits — WSMSC SSN Edit Flag Indicator — OpGUI Modification

NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the WSMSC SSN Edit Flag Indicator. (Previously NANC 291 Req 15)

RR3-370 DPC/SSN Edits — CLASS SSN Edit Flag Indicator Default

NPAC SMS shall default the CLASS SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 16)

RR3-371 DPC/SSN Edits — LIDB SSN Edit Flag Indicator Default

NPAC SMS shall default the LIDB SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 17)

RR3-372 DPC/SSN Edits — CNAM SSN Edit Flag Indicator Default

NPAC SMS shall default the CNAM SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 18)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-106	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-373 DPC/SSN Edits — ISVM SSN Edit Flag Indicator Default

NPAC SMS shall default the ISVM SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 19)

RR3-374 DPC/SSN Edits — WSMSC SSN Edit Flag Indicator Default

NPAC SMS shall default the WSMSC SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 20)

RR3-375 DPC/SSN Edits — CLASS SSN Rejection for Non-Zero Value

NPAC SMS shall, based on the CLASS SSN Edit Flag Indicator for CLASS service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the CLASS Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding CLASS Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 6)

RR3-376 DPC/SSN Edits — LIDB SSN Rejection for Non-Zero Value

NPAC SMS shall, based on the LIDB SSN Edit Flag Indicator for LIDB service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the LIDB Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding LIDB Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 7)

RR3-377 DPC/SSN Edits — CNAM SSN Rejection for Non-Zero Value

NPAC SMS shall, based on the CNAM SSN Edit Flag Indicator for CNAM service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the CNAM Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding CNAM Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 8)

RR3-378 DPC/SSN Edits — ISVM SSN Rejection for Non-Zero Value

NPAC SMS shall, based on the ISVM SSN Edit Flag Indicator for ISVM service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the ISVM Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding ISVM Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 9)

RR3-379 DPC/SSN Edits — WSMSC SSN Rejection for Non-Zero Value

NPAC SMS shall, based on the WSMSC SSN Edit Flag Indicator for WSMSC service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the WSMSC Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding WSMSC Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 10)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-107	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

3.14.2 Global GTT Validations

The following section describes how the NPAC SMS validates GTT contained within Subscription Version and Number Pooling requests. These validations occur outside of any tunable setting on the NPAC SMS.

RR3-380 Subscription Version — Verify CLASS SSN when CLASS DPC is populated

NPAC SMS shall verify the CLASS Sub-System Number (SSN) contains a value between 000-255 when the corresponding CLASS Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 1)

RR3-381 Subscription Version — Verify LIDB SSN when LIDB DPC is populated

NPAC SMS shall verify the LIDB Sub-System Number (SSN) contains a value between 000-255 when the corresponding LIDB Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 2)

RR3-382 Subscription Version — Verify CNAM SSN when CNAM DPC is populated

NPAC SMS shall verify the CNAM Sub-System Number (SSN) contains a value between 000-255 when the corresponding CNAM Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 3)

RR3-383 Subscription Version — Verify ISVM SSN when ISVM DPC is populated

NPAC SMS shall verify the ISVM Sub-System Number (SSN) contains a value between 000-255 when the corresponding ISVM Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 4)

RR3-384 Subscription Version — Verify WSMSC SSN when WSMSC DPC is populated

NPAC SMS shall verify the WSMSC Sub-System Number (SSN) contains a value between 000-255 when the corresponding WSMSC Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 5)

RR3-385 Subscription Version — Verify CLASS DPC when CLASS SSN is populated

NPAC SMS shall verify the CLASS Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CLASS Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 6)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-108	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-386 Subscription Version — Verify LIDB DPC when LIDB SSN is populated

NPAC SMS shall verify the LIDB Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding LIDB Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 7)

RR3-387 Subscription Version — Verify CNAM DPC when CNAM SSN is populated

NPAC SMS shall verify the CNAM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CNAM Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 8)

RR3-388 Subscription Version — Verify ISVM DPC when ISVM SSN is populated

NPAC SMS shall verify the ISVM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding ISVM Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 9)

RR3-389 Subscription Version — Verify WSMSC DPC when WSMSC SSN is populated

NPAC SMS shall verify the WSMSC Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding WSMSC Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 10)

RR3-390 Number Pool Block — Verify CLASS SSN when CLASS DPC is populated

NPAC SMS shall verify the CLASS Sub-System Number (SSN) contains a value (000-255) when the corresponding CLASS Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 11)

RR3-391 Number Pool Block — Verify LIDB SSN when LIDB DPC is populated

NPAC SMS shall verify the LIDB Sub-System Number (SSN) contains a value (000-255) when the corresponding LIDB Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 12)

RR3-392 Number Pool Block — Verify CNAM SSN when CNAM DPC is populated

NPAC SMS shall verify the CNAM Sub-System Number (SSN) contains a value (000-255) when the corresponding CNAM Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 13)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-109	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-393 Number Pool Block — Verify ISVM SSN when ISVM DPC is populated

NPAC SMS shall verify the ISVM Sub-System Number (SSN) contains a value (000-255) when the corresponding ISVM Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 14)

RR3-394 Number Pool Block — Verify WSMSC SSN when WSMSC DPC is populated

NPAC SMS shall verify the WSMSC Sub-System Number (SSN) contains a value (000-255) when the corresponding WSMSC Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 15)

RR3-395 Number Pool Block — Verify CLASS DPC when CLASS SSN is populated

NPAC SMS shall verify the CLASS Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CLASS Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 16)

RR3-396 Number Pool Block — Verify LIDB DPC when LIDB SSN is populated

NPAC SMS shall verify the LIDB Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding LIDB Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 17)

RR3-397 Number Pool Block — Verify CNAM DPC when CNAM SSN is populated

NPAC SMS shall verify the CNAM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CNAM Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 18)

RR3-398 Number Pool Block — Verify ISVM DPC when ISVM SSN is populated

NPAC SMS shall verify the ISVM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding ISVM Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 19)

RR3-399 Number Pool Block — Verify WSMSC DPC when WSMSC SSN is populated

NPAC SMS shall verify the WSMSC Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding WSMSC Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 20)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-110	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-400 DPC/SSN Edits — CLASS validation failure

NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for CLASS fails validation. (Previously NANC 191 Req 21)

RR3-401 DPC/SSN Edits — LIDB validation failure

NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for LIDB fails validation. (Previously NANC 191 Req 22)

RR3-402 DPC/SSN Edits — CNAM validation failure

NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for CNAM fails validation. (Previously NANC 191 Req 23)

RR3-403 DPC/SSN Edits — ISVM validation failure

NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for ISVM fails validation. (Previously NANC 191 Req 24)

RR3-404 DPC/SSN Edits — WSMSC validation failure

NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for WSMSC fails validation. (Previously NANC 191 Req 25)

RR3-405 DPC/SSN Edits — CLASS DPC and SSN Required Data for Modification

NPAC SMS shall require values from the requesting Service Provider for both CLASS DPC and CLASS SSN to be sent to the NPAC SMS when modifying CLASS service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 26)

RR3-406 DPC/SSN Edits — LIDB DPC and SSN Required Data for Modification

NPAC SMS shall require values from the requesting Service Provider for both LIDB DPC and LIDB SSN to be sent to the NPAC SMS when modifying LIDB service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 27)

RR3-407 DPC/SSN Edits — CNAM DPC and SSN Required Data for Modification

NPAC SMS shall require values from the requesting Service Provider for both CNAM DPC and CNAM SSN to be sent to the NPAC SMS when modifying CNAM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 28)

RR3-408 DPC/SSN Edits — ISVM DPC and SSN Required Data for Modification

NPAC SMS shall require values from the requesting Service Provider for both ISVM DPC and ISVM SSN to be sent to the NPAC SMS when modifying ISVM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 29)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-111	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-409 DPC/SSN Edits — WSMSC DPC and SSN Required Data for Modification

NPAC SMS shall require values from the requesting Service Provider for both WSMSC DPC and WSMSC SSN to be sent to the NPAC SMS when modifying WSMSC service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 30)

RR3-410 DPC/SSN Edits — CLASS DPC and SSN Required Data for Mass Update

NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both CLASS DPC and CLASS SSN to be provided when mass updating CLASS service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 31)

RR3-411 DPC/SSN Edits — LIDB DPC and SSN Required Data for Mass Update

NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both LIDB DPC and LIDB SSN to be provided when mass updating LIDB service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 32)

RR3-412 DPC/SSN Edits — CNAM DPC and SSN Required Data for Mass Update

NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both CNAM DPC and CNAM SSN to be provided when mass updating CNAM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 33)

RR3-413 DPC/SSN Edits — ISVM DPC and SSN Required Data for Mass Update

NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both ISVM DPC and ISVM SSN to be provided when mass updating ISVM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 34)

RR3-414 DPC/SSN Edits — WSMSC DPC and SSN Required Data for Mass Update

NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both WSMSC DPC and WSMSC SSN to be provided when mass updating WSMSC service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 35)

RR3-415 Subscription Version — Verify All Routing Data When Modifying Non-GTT Data

NPAC SMS shall when modifying non-GTT data, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 36)

RR3-416 Subscription Version — Verify All Routing Data When Modifying CLASS Data

NPAC SMS shall when modifying CLASS DPC or CLASS SSN, reject the modify request for any DPC/SSN value edit inconsistencies for LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 37)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-112	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-417 Subscription Version — Verify All Routing Data When Modifying LIDB Data

NPAC SMS shall when modifying LIDB DPC or LIDB SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 38)

RR3-418 Subscription Version — Verify All Routing Data When Modifying CNAM Data

NPAC SMS shall when modifying CNAM DPC or CNAM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 39)

RR3-419 Subscription Version — Verify All Routing Data When Modifying ISVM Data

NPAC SMS shall when modifying ISVM DPC or ISVM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 40)

RR3-420 Subscription Version — Verify All Routing Data When Modifying WSMSC Data

NPAC SMS shall when modifying WSMSC DPC or WSMSC SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or ISVM, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 41)

RR3-421 Number Pool Block — Verify All Routing Data When Modifying Non-GTT Data

NPAC SMS shall when modifying non-GTT data, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 42)

RR3-422 Number Pool Block — Verify All Routing Data When Modifying CLASS Data

NPAC SMS shall when modifying CLASS DPC or CLASS SSN, reject the modify request for any DPC/SSN value edit inconsistencies for LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 43)

RR3-423 Number Pool Block — Verify All Routing Data When Modifying LIDB Data

NPAC SMS shall when modifying LIDB DPC or LIDB SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 44)

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-113	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC Data Administration

RR3-424 Number Pool Block — Verify All Routing Data When Modifying CNAM Data

NPAC SMS shall when modifying CNAM DPC or CNAM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 45)

RR3-425 Number Pool Block — Verify All Routing Data When Modifying ISVM Data

NPAC SMS shall when modifying ISVM DPC or ISVM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 46)

RR3-426 Number Pool Block — Verify All Routing Data When Modifying WSMSC Data

NPAC SMS shall when modifying WSMSC DPC or WSMSC SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or ISVM, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 47)

RR3-427 Subscription Version — Verify All Routing Data When Activating a Subscription Version

NPAC SMS shall when activating a Subscription Version, reject the activate request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new Service Provider in an activation for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 48)

RR3-428 Number Pool Block — Verify All Routing Data When Activating a Number Pool Block

NPAC SMS shall when scheduling a Block Create Event or activating a Number Pool Block, reject the scheduling or activate request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new Service Provider in scheduling or activation for a Number Pool Block. (Previously NANC 191 Req 49)

RR3-429 DPC/SSN Edits — Errors on DPC and SSN Required Data for Mass Update

NPAC SMS shall log an entry to be used for the mass update exception report when any of the required DPC/SSN data edits are violated when mass updating a Subscription Version or Number Pool Block, and continue processing the mass update request. (Previously NANC 191 Req 50)

Note: For example in a case where 2000 SVs are being mass updated and 100 encountered DPC/SSN edit errors, the NPAC will perform the mass update by updating the 1900 SVs that are valid, and logging the remaining 100 SVs to be picked up the mass update exception report.

Release 3.3: Ó 1997 — 2006 NeuStar, Inc.	3-114	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

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 the LNP Service Providers 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 Service Provider ID

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.

R4-4 View of Service Provider Data

NPAC SMS shall allow NPAC personnel to view Service Provider data.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

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 SOA Low-tech Interface.

RX4-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.1 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 and/or SOA to NPAC 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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

R4-8 Service Provider Data Elements

NPAC SMS shall require the following data if there is no existing Service Provider data: (reference NANC 399)

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 SOA to NPAC SMS interface.
6.	Service Provider Security Contact. Contact data is security data when Contact Type is “SE.”
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
11.	NPAC New Functionality Support
12.	Port In Timer Type
13.	Port Out Timer Type
14.	Business Hour/Days
15.	NPAC Customer SOA NPA-NXX-X Indicator
16.	NPAC Customer LSMS NPA-NXX-X Indicator
17.	LSMS EDR Indicator
18.	SOA Notification Priority for each SOA notification. Separate values may be set for Status Attribute Value Change notifications based on whether the Service Provider is acting as the Old Service Provider or as the New Service Provider for the port as indicated in Appendix C, Table C-7 – SOA Notification Priority Tunables.
19.	TN Range Notification Indicator
20.	No New SP Concurrence Notification Indicator
21.	Service Provider Type
22.	Service Provider Type SOA Indicator

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

23.	Service Provider Type LSMS Indicator
24.	Service Provider SOA SWIM Recovery Indicator
25.	Service Provider LSMS SWIM Recovery Indicator
26.	NPAC SMS-to-SOA Application Level Heartbeat Indicator
27.	NPAC SMS-to-LSMS Application Level Heartbeat Indicator
28.	SOA Action Application Level Errors Indicator
29.	LSMS Action Application Level Errors Indicator
30.	SOA Non-Action Application Level Errors Indicator
31.	LSMS Non-Action Application Level Errors Indicator
32.	SOA Notification Channel Service Provider Tunable
33.	Subscription Version TN Attribute Flag Indicator
34.	Number Pool Block NPA-NXX-X Attribute Flag Indicator
35.	Cancel-Pending-to-Conflict Cause Code Indicator
36.	Service Provider SOA SV Query Indicator
37.	Service Provider LSMS SV Query Indicator
38.	NPAC Customer SOA SV Type Indicator
39.	NPAC Customer SOA Alternative SPID Indicator
40.	NPAC Customer LSMS SV Type Indicator
41.	NPAC Customer LSMS Alternative SPID Indicator

The following data is optional:

• Service Provider Contact Type: SOA Contact, Local SMS, Web, Network Communications, Conflict Resolution, Operations, and User Administration Contact Address Information.

• NPAC Customer Associated Service Provider 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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

R4-11 Failure notification of Service Provider creation

NPAC SMS shall issue an appropriate error message upon unsuccessful creation of the new Service Provider.

RR4-9 Service Provider Type SOA Indicator

NPAC SMS shall provide a Service Provider Type SOA Indicator tunable parameter, which defines whether a SOA supports the Service Provider Type attribute. (previously NANC 357, Req 1)

RR4-10 Service Provider Type SOA Indicator Default

NPAC SMS shall default the Service Provider Type SOA Indicator tunable parameter to FALSE. (previously NANC 357, Req 2)

RR4-11 Service Provider Type SOA Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Type SOA Indicator tunable parameter. (previously NANC 357, Req 3)

RR4-12 Service Provider Type LSMS Indicator

NPAC SMS shall provide a Service Provider Type LSMS Indicator tunable parameter which defines whether an LSMS supports the Service Provider Type attribute. (previously NANC 357, Req 4

RR4-13 Service Provider Type LSMS Indicator Default

NPAC SMS shall default the Service Provider Type LSMS Indicator tunable parameter to FALSE. (previously NANC 357, Req 5)

RR4-14 Service Provider Type LSMS Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Type LSMS Indicator tunable parameter. (previously NANC 357, Req 6)

RR4-15 Service Provider Type Attribute Modification Restriction

NPAC SMS shall only allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Type attribute. (previously NANC 357, Req 7)

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

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-2 NPAC Customer Data Model.

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-2 NPAC Customer Data Model, with the exception of the NPAC Customer ID.

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.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

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.

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-24.1 | Display of Service Provider ID and related subscription data
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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

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-2, 3-3, 3-4, and 3-5, 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.

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.

RR4-16 Service Provider Data Information Service Provider Query — Support for Service Provider Type Data

NPAC SMS shall apply the Service Provider Type tunable support of the requesting Service Provider, in a query of Service Provider data. (previously NANC 357, Req 9)

4.2 Additional Requirements

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Service Provider Data Administration

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.

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.1 Removal of NPA-NXX — Subscription Version Check

NPAC SMS shall allow removal of an NPA-NXX by NPAC personnel only if no Subscription Versions, except for Old without a Failed SP List or Canceled Subscription Versions, exist for the NPA-NXX.

RR4-3.2 Removal of NPA-NXX — NPA-NXX-X Check

NPAC SMS shall allow the removal of an NPA-NXX by NPAC personnel only if Number Pooling NPA-NXX-X Information, does not exist for the NPA-NXX.

RR4-4.2.1 Removal of LRN — Subscription Version Check

NPAC SMS shall allow the removal of an LRN by NPAC personnel only if no Subscription Versions, except for Old without a Failed SP List or Canceled Subscription Versions, exist and use the LRN.

RR4-4.2.2 Removal of LRN — Block Check

NPAC SMS shall allow the removal of an LRN by NPAC personnel only if Number Pooling Block Information, except for Old with NO Failed SP List, do not exist and do not use the LRN.

RR4-5 Duplicate NPA-NXX Validation

NPAC SMS shall validate upon request to add an NPA-NXX for a service provider, that the NPA-NXX does not exist for any service provider in the region.

RR4-6 Duplicate NPA-NXX Validation — Error Processing

NPAC SMS shall upon finding that an NPA-NXX already exists for a service provider in a region, reject a request to add an NPA-NXX for a service provider and report an error to the user.

RR4-7 Duplicate LRN Validation

NPAC SMS shall validate upon request to add an LRN for a service provider, that the LRN does not exist for any service provider in the region.

RR4-8 Duplicate LRN Validation — Error Processing

NPAC SMS shall upon finding that an LRN already exists for a service provider in a region, reject a request to add an LRN for a service provider and report an error to the user.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	4-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

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, cancel pending, conflict, 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.

RR5-113 TN Range Notification Information — Service Provider TN Range Notification Indicator Sending of TN Range Notifications

NPAC SMS shall send TN Range Notifications, via the SOA to NPAC SMS Interface, if the Service Provider’s TN Range Notification Indicator is TRUE. (Formerly NANC 179 Req 4)

RR5-114 TN Range Notification Information — Service Provider TN Range Notification Indicator Suppression of TN Range Notifications

NPAC SMS shall suppress TN Range Notifications and send individual TN Notifications, via the SOA to NPAC SMS Interface, if the Service Provider’s TN Range Notification Indicator is FALSE. (Formerly NANC 179 Req 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

AR5-3 Changing of TN Range Notification Indicator while Notifications are Queued

In the event that the TN Range Notification Indicator is changed from TRUE to FALSE any notifications for multiple TNs that were already created and are in queue will be sent in the range format and in the event that the TN Range Notification Indicator is changed from FALSE to TRUE any notifications for multiple TNs that were already created and are in queue will be sent in the single format.

RR5-115 TN Range Notification Information — Single TN Range Notifications

NPAC SMS shall send a single TN Range Notification when the same feature data applies to all TNs in the range. (Formerly NANC 179 Req 6)

RR5-116 TN Range Notification Information — Breakup of TN Range Notifications

NPAC SMS shall send more than one TN Range Notification when the same feature data does NOT apply to all TNs in the range, by breaking up the TN Range and sending TN Range Notifications such that the same feature data applies to all TNs in the smaller broken up TN Ranges. (Formerly NANC 179 Req 7)

RR5-173 TN Range Notification Information — Breakup of TN Range Notifications

NPAC SMS shall send more than one TN Range Notification when a subsequent request is received for a TN range that was different than the original create TN range by breaking up the TN Range and sending single TN Range Notifications.

Note: An example of a different subsequent request is an original create range of 5 TNs, followed by an activate of a single TN. This leads to the NPAC breaking up the range into singles upon receipt of the first request that doesn’t match the original creat range request.

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 Interaction Diagram]

Figure 1 — Subscription Version Status Interaction Diagram

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
1	Conflict to Cancel	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 calendar days.
		SOA to NPAC SMS Interface or NPAC SOA Low-tech or Administrative Interface	The old Service Provider User (or NPAC personnel acting on behalf of the Service Provider) sends a cancellation request for a Subscription Version created by that Service Provider with a status of conflict that has not been concurred by the other new Service Provider.
2	Conflict to Cancel Pending	NPAC SOA Low-tech or Administrative Interface	User cancels a Subscription Version in conflict or cancels a Subscription Version that was created by or concurred to by both Service Providers.
		SOA to NPAC SMS Interface	User sends a cancellation request for a Subscription Version that was created by or concurred to by both Service Providers.
3	Cancel Pending to Conflict	NPAC SOA Low-tech or Administrative Interface	User sets a Subscription Version with a status of cancel pending to conflict.
		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 new Service Provider within a tunable timeframe.
4	Conflict to Pending	NPAC Administrative Interface – NPAC Personnel and SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface – Old Service Provider	User removes a Subscription Version from conflict.
		SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface — New Service Provider	New Service Provider User removes a Subscription Version from conflict. This action can only occur if a tunable number of hours have elapsed since the Subscription Version was placed in conflict.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
5	Pending to Conflict	NPAC Administrative Interface – NPAC Personnel	1.    User sets a Subscription Version with a status of pending to 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.
		SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface – Old Service Provider	Old Service Provider sends a Subscription Version creation or modification request for a Subscription Version with a status of pending, which revokes the old Service Provider’s authorization for transfer of service. This action can only be taken once, and must be taken a tunable number of hours prior to the new Service Provider due date.
6	Pending to Cancel	NPAC Administrative Interface – NPAC Personnel	User cancels a Subscription Version with a status of pending that has not been concurred by both service providers.
		SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface	Service Provider User sends a cancellation request for a Subscription Version created by that Service Provider with a status of pending that has not been concurred by the other Service Provider.
		NPAC SMS Internal	1.    NPAC SMS automatically sets a pending Subscription Version to cancel 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 if an activation request is not received a tunable amount of time after new Service Provider due date.
7	Pending to Cancel Pending	NPAC Administrative Interface — NPAC Personnel	User cancels a Subscription Version with a status of pending that has been created/concurred by both Service Providers.
		SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface	Service Provider User sends a cancellation request for a Subscription Version with a status of pending that has been concurred by the other Service Provider.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
8	Cancel Pending to Cancel	NPAC SMS Internal	NPAC SMS automatically sets a cancel pending Subscription Version to canceled after receiving cancel pending acknowledgment from the concurring Service Provider, or the final cancellation concurrence window has expired without cancel concurrence from the old Service Provider.
9	Creation - Set to Conflict	NPAC Administrative Interface – NPAC Personnel	User creates a Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.
		SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface – Old Service Provider	User sends an old Service Provider Subscription Version creation request and does not provide authorization for the transfer of service.
10	Creation - Set to Pending	NPAC Administrative Interface – 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 # 9, Creation — Set to Conflict, NPAC SOA Low-tech Interface.
		SOA to NPAC SMS Interface and NPAC SOA Low-tech 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 # 9, Creation — Set to Conflict, SOA to NPAC SMS LOW-TECH INTERFACE.
11	Disconnect Pending to Sending	NPAC SMS Internal	NPAC SMS automatically sets a deferred disconnect pending Subscription Version to sending after the effective release date is reached.
12	Cancel Pending to Pending	SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface	Service Provider User sends an un-do cancel-pending request for a Subscription Version with a status of cancel-pending for which the same Service Provider previously issued a cancel request.
13	Pending to Sending	NPAC Administrative Interface — NPAC Personnel	User activates a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
		SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface — New Service Provider	New Service Provider User sends an activation message for a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.
14	Sending to Failed	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from sending to failed after all Local SMSs fail Subscription Version activation after the tunable retry period expires.
15	Failed to Sending	NPAC Administrative Interface – NPAC Personnel	User re-sends a failed Subscription Version.
16	Partially Failed to Sending	NPAC Administrative Interface – NPAC Personnel	User re-sends a partial failure Subscription Version.
17	Sending to Partially Failed	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 after the tunable retry period expires.
18	Sending to Old	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. Disconnects that fail on one or more, but not all, Local SMSs will also be set to old.
19	Sending to Active	NPAC SMS Internal	1.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version activation is successful in all of the Local SMSs.
			2.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version modification is successfully broadcast to any of the Local SMSs after all have responded.
			3.    NPAC SMS automatically sets a sending Subscription Version to active after a failure to all Local SMSs on a disconnect.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
20	Active to Sending	NPAC Administrative Interface – NPAC Personnel	User disconnects an active Subscription Version and does not supply an effective release date, User modifies an active Subscription Version or resends a failed disconnect or modify.
		SOA to NPAC SMS Interface to NPAC SOA Low-tech Interface — Current Service Provider	User sends a disconnect request for an active Subscription Version and does not supply an effective release date, or User modifies an active Subscription Version.
21	Active to Old	NPAC SMS Internal	NPAC SMS automatically sets the currently active Subscription Version to old once a currently active subscription version is superseded by a pending subscription version, due to the fact that the current version is set to old when an activate occurs. The new pending version is set to sending and then to active, partially failed, or old. On a disconnect the sending state occurs before the old.
22	Disconnect Pending to Active	NPAC Administrative Interface – NPAC Personnel	User cancels a Subscription Version with a disconnect pending status.
		SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface – New Service Provider	User sends a cancellation request for a disconnect pending Subscription Version.
23	Active to Disconnect Pending	NPAC Administrative Interface — NPAC Personnel	User disconnects an active Subscription Version and supplies a future effective release date.
		SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface- Current Service Provider	User sends a disconnect request for an active Subscription Version and supplies a future effective release date.
24	Old to Sending	NPA Operations Interface – NPAC Personnel	User re-sends a partial failure of a disconnect or partial failure or failure of a port-to-original Subscription Version.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
25	Old to Old	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from old to old after one or more previously failed Local SMSs successfully disconnect a Subscription Version, as a result of an audit or LSMS resync. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
26	Partially Failed to Active	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from partial failure to active after all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS resync. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
27	Partially Failed to Partially Failed	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS resync. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.

Table 5-1 Subscription Version Status Interaction Descriptions

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 or conflict version was canceled prior to activation in the network.

• Cancel Pending — Version is awaiting cancellation acknowledgment from the concurring 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.

• 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 in ALL of the Local SMSs in the network.

• Old — Version was previously active in the network and either was superseded by another active version or was disconnected.

• Partial Failure — Version failed activation in one or more, but not all, Local SMSs in the network.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

R5-2.3 Old Subscription Retention — Tunable Parameter Default

NPAC SMS shall default the Old Subscription Retention tunable parameter to 18 calendar 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 calendar 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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-3.6 Cancel-Conflict Subscription Retention — Tunable Parameter Default

NPAC SMS shall default the Cancel-Conflict Subscription Retention tunable parameter to 30 calendar 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 calendar days.

RR5-1.4 Pending Subscription Retention — Tunable Parameter Expiration

NPAC SMS shall cancel a Subscription Version by setting the subscription version to cancel after a pending Subscription Version has existed in the system for a Pending Subscription Retention number of calendar days subsequent to new Service Provider Due Date, or old Service Provider Due Date if the new Service Provider Due Date has not been received by the NPAC SMS.

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 (if applicable)

• User ID and/or Login

• Local Number Portability Type

• Date

• Time

• Ported Telephone Number

• Status Flag — successful or failed

• Subscription Version ID (when assigned)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

RR5-55 Create Pending Provider Port — NPAC Personnel or Service Provider After Block Activation

NPAC SMS shall allow NPAC personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to create inter-service provider ports or intra-service provider ports for a TN within the 1K Block, when the currently active Subscription Version(s) is LNP Type POOL, and the Block’s status is active, with an empty Failed SP List. (Previously SV-195)

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-9 Activating a Subscription version

NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to activate a Subscription Version.

R5-10.1 Setting a Subscription Version to Conflict

NPAC SMS shall allow NPAC personnel to set a Subscription Version to conflict.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

RR5-3 Create Subscription Version — Notify NPA-NXX First Usage

NPAC SMS shall notify all accepting Local SMSs and SOAs of the NPA-NXX, effective date, and owning Service Provider when an NPA-NXX is being ported for the first time immediately after creation validation of a Subscription Version.

RR5-53 Create Subscription Version — Notify NPA-NXX First Usage of a New NPA-NXX involved in an NPA Split

NPAC SMS shall notify all accepting Local SMSs and SOAs of the NPA-NXX, effective date, and owning Service Provider when a new NPA-NXX involved in an NPA Split, is being ported for the first time, after the start of permissive dialing, immediately after creation validation of a Subscription Version, only in cases where no SV or NPA-NXX-X activity had previously taken place in the Old NPA-NXX.

RR5-120 Validation of LATA ID for Subscription Version Creates

NPAC shall reject Subscription Version Create Requests if the NPA-NXX of the TN and the NPA-NXX of the LRN have different LATA IDs. (Previously NANC 319 Req 6)

RR5-130 Create “Porting to Original” Subscription Version — New Service Provider ID and Code Holder Match

NPAC SMS shall validate that the new Service Provider Id is the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block) in a “Port to Original” subscription version request for both Inter- and Intra-Service Provider ports.

RR5-162 Addition of Subscription Version Due Date — Validation

NPAC SMS shall verify that the Due Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and equal to or greater than the current date, when adding a Subscription Version. (previously NANC 394, Req 6)

Note: For an Inter-Service Provider port, the due date may be a past date when it is the 2^nd create for the subscription version (see requirement RR5-119).

5.1.2.2.1.1 Subscription Version Creation — Inter-Service Provider Ports

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

This section provides the Subscription Version Creation requirements for performing an Inter-Service Provider port of a TN. There are two types of Inter-Service Provider ports: A port of a TN to a new Service Provider from the Old, or a “porting to original” port. 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 Inter-Service Provider 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 of Inter-Service Provider ports require authorization for the transfer of service from the new Service Provider.

R5-14 Create Subscription Version — Old Service Provider Input Data

NPAC SMS shall accept the following data from the NPAC personnel or old Service Provider upon Subscription Version creation for an Inter-Service Provider 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.

• Status Change Cause Code — indication of reason for denial of authorized by the Old 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 when NOT “porting to original”: (reference NANC 399)

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

• 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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• CNAM DPC

• CNAM SSN

• ISVM DPC

• ISVM SSN

• WSMSC DPC (if supported by the Service Provider SOA)

• WSMSC SSN (if supported by the Service Provider SOA)

• Porting to Original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “FALSE” for this type of Inter-Service Provider port.

• SV Type (if supported by the Service Provider SOA)

R5-15.2 Create “Inter-Service Provider 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 an Inter-Service Provider “porting to original” port:

• Local Number Portability Type — Port Type. This field must be set to “LSPP” for “Inter-Service Provider 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, also the NPA-NXX code holder or Block Holder if this TN is part of a Number Pool Block.

• 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 “Inter-Service Provider porting to original” ports, and set to “FALSE” for other Inter-Service Provider ports.

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: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• Alternative SPID (if supported by the Service Provider SOA)

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-6 upon Subscription Version creation for an Inter-Service Provider port: (reference NANC 399)

• LNP Type

• Ported TN(s)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• 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

• Status Change Cause Code

• LRN

• Class DPC

• Class SSN

• LIDB DPC

• LIDB SSN

• CNAM DPC

• CNAM SSN

• ISVM DPC

• ISVM SSN

• WSMSC DPC

• WSMSC SSN

• Porting to Original

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

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 initial Subscription Version creation for an Inter-Service Provider port.

R5-18.3 Create Subscription Version — Due Date Validation

DELETED

RR5-131 Create “Inter-Service Provider Port” Subscription Version — Due Date Validation For First Port

DELETED

RR5-132 Create “Inter-Service Provider Port” Subscription Version — Due Date Validation For Subsequent Port Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window

DELETED

R5-18.4 Create Subscription Version — Ported TN NPA-NXX Validation

NPAC SMS shall verify that the NPA-NXX to be ported exists as an NPA-NXX in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider port.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-44 Create Subscription Version — Due Date Validation for NPA-NXX effective date

DELETED

RR5-119 Subscription Version — Due Date Validation for Second/Concurrence Create Message for a Subscription Version Inter-Service Provider Port

NPAC SMS shall allow the due date to be a past date upon Subscription Version concurrence (2^nd create for this Subscription Version) for an Inter-Service Provider port. (Formerly NANC 294 Req 1)

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

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

R5-18.10 Create Subscription Version — Status Change Cause Code Validation

NPAC SMS shall require and only allow the Status Change Cause Code to be set when the Old Service Provider authorization is set to false.

R5-19.1 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 port.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-19.2 Create Subscription Version — Old Service Provider ID Validation — No Active Subscription Version

NPAC SMS shall validate that the old Service Provider in the create message is the Service Provider to which the TN’s NPA-NXX is assigned (as stored in the NPAC SMS service provider data tables) if there is currently no active Subscription Version for the TN in the NPAC SMS.

R5-19.3 Create Subscription Version — Timer Type Selection

NPAC SMS shall if the old and new service provider timer types match set the subscription version timer type to that timer type.

R5-19.4 Create Subscription Version — Timer Type Selection — Mismatch

NPAC SMS shall if the old and new service provider timer types do not match set the subscription version timer type to the longer timer type of the port out type for the old service provider and the port in type of the new service provider.

R5-19.5 Create Subscription Version — Business Hours and Days Selection

NPAC SMS shall if the old and new service provider business hours and days match set the subscription version business type to the business type for the business hours and days supported.

R5-19.6 Create Subscription Version — Business Hours and Days Selection — Mismatch

NPAC SMS shall if the old and new service provider business hours and days do not match set the subscription version business type to the shorter business hours and days.

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

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

R5-21.1 Initial Concurrence Window — Tunable Parameter

NPAC SMS shall provide long and short Initial Concurrence Window tunable parameters which are defined as the number of business hours subsequent to the time the Subscription Version was initially created by which both Service Providers can authorize transfer of service if this is an Inter-Service Provider port.

R5-21.2 Initial Concurrence Window — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Initial Concurrence Window tunable parameters.

R5-21.3 Long Initial Concurrence Window — Tunable Parameter Default

NPAC SMS shall default the long Initial Concurrence Window tunable parameter to 9 business hours.

R5-21.4 Short Initial Concurrence Window — Tunable Parameter Default

NPAC SMS shall default the short Initial Concurrence Window tunable parameter to 1 business hour.

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

RR5-2.1 Create Subscription Version — Set to Conflict

NPAC SMS shall set a Subscription Version directly to conflict and set the cause code, 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 port and specified a cause code.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

RR5-2.4 Cause Code in Conflict Notification — Creation

NPAC SMS shall include the cause code in the conflict notification to the Old and New Service Provider when the Old Service Provider did not authorize transfer of service for an Inter-Service Provider port on creation.

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 long and short Final Concurrence Window tunable parameters which are defined as the number of business hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers can authorize transfer of subscription service for an Inter-Service Provider port.

R5-23.2 Final Concurrence Window Tunable — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Final Concurrence Window tunable parameters.

R5-23.3 Long Final Concurrence Window Tunable — Tunable Parameter Default

NPAC SMS shall default the long Final Concurrence Window tunable parameter to 9 business hours.

RR5-52 Short Final Concurrence Window Tunable — Tunable Parameter Default

NPAC SMS shall default the short Final Concurrence Window tunable parameter to 1 business hour.

R5-23.4

DELETED

RR5-117 New Service Provider Final Create Window Expiration Notification

NPAC SMS shall upon expiration of the Final Concurrence Window, where a new Service Provider has not sent authorization for the transfer of service, send a notification to both the old Service Provider that supports the Final Create Window Expiration Notification and the new Service Provider that supports the Final Create Window Expiration Notification via the SOA to NPAC SMS Interface, to inform them of the timer expiration. (Formerly NANC 240 Req 1)

RR5-118 New Service Provider Final Create Window Expiration Notification — Sending of Cause Code

NPAC SMS shall only send the Subscription Version Status Change Cause Code in the Final Create Window Expiration Notification when the old Service Provider authorization is FALSE. (Formerly NANC 240 Req 2)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-56 Create Inter-Service Provider Port-to-Original Port — NPAC and SOA After NPA-NXX-X Creation

NPAC SMS shall reject an inter-service provider Subscription Version Create message, where there is no active subscription version for the requested TN in the NPAC SMS, or an inter-service provider Port-to-Original Subscription Version Create message, for a TN within the 1K Block, from NPAC Personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, after the Creation of the NPA-NXX-X, and prior to the existence of the Block in the NPAC SMS. (Previously SV-180)

RR5-121 Create Intra-Service Provider Port-to-Original Port — NPAC and SOA After NPA-NXX-X Creation

NPAC SMS shall reject an intra-service provider Port-to-Original Subscription Version Create message for a TN within the 1K Block, from NPAC Personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, after the Creation of the NPA-NXX-X, and prior to the existence of the Block in the NPAC SMS. (Previously NANC 230 Req 2)

RR5-57 Create Intra- or Inter-Service Provider Port-to-Original Subscription Version — After Block Activation

NPAC SMS shall validate that the New Service Provider is the Block Holder, in an intra-service provider port-to-original subscription version create message or inter-service provider port-to-original port for a TN within the 1K Block, once the Block exists in the NPAC SMS. (Previously SV-190)

R5-23.5 Activation without Old Service Provider Authorization

NPAC SMS shall allow a pending Subscription Version to be activated without an old Service Provider authorization for transfer of service.

R5-23.6 Activation without Old Service Provider Authorization — Time restriction

NPAC SMS shall allow activation without Old Service Provider concurrence only after the final concurrence window timer has expired.

RR5-23.3 Old Service Provider Final Concurrence Timer Expiration Notification

NPAC SMS shall upon expiration of the Final Concurrence Timer send a notification to the old service provider via the SOA to NPAC SMS interface to inform them of the timer expiration.

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). A “port to original” for an Intra-Service Provider port should be handled by submission of an Intra-Service Provider “port to original” subscription version request to the NPAC SMS.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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 when NOT porting to original:

• 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

• WSMSC DPC (if supported by the Service Provider SOA)

• WSMSC SSN (if supported by the Service Provider SOA)

• Porting to Original — flag indicating whether or not this is a ‘porting-to-original” port. This flag must be set to “FALSE” for this type of Intra-Service Provider port.

• SV Type (if supported by the Service Provider SOA)

RR5-122 Create “Intra-Service Provider porting to original 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 Intra-Service Provider “porting to original” port:

• Local Number Portability Type — Port Type. This field must be set to “LISP” for “Intra-Service Provider 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 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.

• Porting to original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “TRUE” for “Intra-Service Provider porting to original” ports, and set to “FALSE” for other Intra-Service Provider ports.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• Old Facilities-based Service Provider ID – current Service Provider within which the Intra-Service Provider port will occur.

• Porting to original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “TRUE” for “Intra-Service Provider porting to original” ports, and set to “FALSE” for other Intra-Service Provider ports.

(Previously NANC 230 Req 1)

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: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• Alternative SPID (if supported by the Service Provider SOA)

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-6 upon Subscription Version creation for an Intra-Service Provider port: (reference NANC 399)

• 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

• WSMSC DPC (if supported by the Service Provider SOA)

• WSMSC SSN (if supported by the Service Provider SOA)

• Porting to Original

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

RR5-6.3 Create “Intra-Service Provider Port” Subscription Version — Due Date Validation

DELETED

RR5-133 Create “Intra-Service Provider Port” Subscription Version — Due Date Validation For First Port

DELETED

RR5-134 Create “Intra-Service Provider Port” Subscription Version — Due Date Validation For Subsequent Port Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window

DELETED

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 an NPA-NXX in the NPAC SMS system upon Subscription Version creation for an Intra-Service Provider port.

RR5-45 Create “Intra-Service Provider Port” Subscription Version – Due Date Validation for NPA-NXX effective date

DELETED

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-6.8 Create “Intra-Service Provider Port” Subscription Version — No Active Version

NPAC SMS shall allow an Intra-Service Provider port to occur for a telephone number not associated with a current active version.

RR5-6.9 Create “Intra-Service Provider Port” Subscription Version — Old Service Provider ID Validation — No Active Subscription Version

NPAC SMS shall validate that the old Service Provider in the create message is the Service Provider to which the TN’s NPA-NXX is assigned (as stored in the NPAC SMS service provider data tables) if there is currently no active Subscription Version for the TN in the NPAC SMS.

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.

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.

RR5-58 Create Intra-Service Provider Port – NPAC Personnel After NPA-NXX-X Creation

NPAC SMS shall allow NPAC personnel to create intra-service provider ports for a TN within the 1K Block, after the Creation of the NPA-NXX-X and up to the NPA-NXX-X’s Effective Date, only where the new/old Service Provider is the Code Holder SPID, and a previously active SV does NOT exist in the NPAC SMS. (Previously SV-160)

RR5-59 Create Intra-Service Provider Port – SOA After NPA-NXX-X Creation

NPAC SMS shall reject an intra-service provider Subscription Version Create message for a TN within the 1K Block, from a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, after the Creation of the NPA-NXX-X Information, and a previously active SV does NOT exist in the NPAC SMS. (Previously SV-170)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

RR5-123 Validation of LATA ID for Subscription Version Modifies

NPAC shall reject Subscription Version Modify Requests if the NPA-NXX of the TN and the NPA-NXX of the LRN have different LATA IDs.(Previously NANC 319 Req 7)

R5-25 Modify Subscription Version — Invalid Version Status Notification

NPAC SMS shall return an error to the originating NPAC personnel or NPAC SOA Low-tech Interface users, or SOA to NPAC SMS interface user if the version status is sending, failed, partial failure, canceled, active with a Failed SP List or old upon Subscription Version modification.

5.1.2.2.2.1 Modification of a Pending or Conflict Subscription Version

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 or conflict Subscription Version to be modified:

Ported Telephone Number (or a specified range of numbers) 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 or conflict Subscription Version for an Inter-Service Provider or Intra-Service Provider port by the new/current Service Provider or NPAC personnel: (reference NANC 399)

• 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

• WSMSC DPC (if supported by the Service Provider SOA)

• WSMSC SSN (if supported by the Service Provider SOA)

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-25	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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, or conflict Subscription Version for a “porting to original” port by the new Service Provider or NPAC personnel:

• 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 or conflict Subscription Version for an Inter-Service Provider 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

• Status Change Cause Code

R5-27.4 Old Service Provider authorization Flag Modification to False

NPAC SMS shall allow the old Service Provider to modify the old Service Provider authorization flag to false and set the cause code. As a result the NPAC SMS will set the Subscription Version status to conflict provided the version has not previously been set into conflict by the Old Service Provider for reasons other than cancellation.

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 or conflict Subscription version: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• Alternative SPID (if supported by the Service Provider SOA)

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-6 upon Subscription Version modification. (reference NANC 399)

• LNP Type

• Ported TN(s)

• Old Service Provider Due Date

• New Service Provider Due Date

• Old Service Provider Authorization

• Status Change Cause Code

• Old Service Provider ID

• New Service Provider ID

• LRN

• Class DPC

• Class SSN

• LIDB DPC

• LIDB SSN

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-26	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• CNAM DPC

• CNAM SSN

• ISVM DPC

• ISVM SSN

• WSMSC DPC

• WSMSC SSN

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

R5-29.2 Modify Subscription Version — Due Date Validation

DELETED

RR5-135 Modify Subscription Version — Due Date Validation For Port Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window

DELETED

RR5-163 Modification of Subscription Version Due Date – Validation

NPAC SMS shall verify that the Due Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and equal to or greater than the current date, when modifying a Subscription Version. (previously NANC 394, Req 7)

RR5-54 Modify Subscription Version — Due Date Validation for NPA-NXX Effective Date

DELETED

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-29.5 Modify Subscription Version — Status Change Cause Code Validation

NPAC SMS shall require and only allow the Status Change Cause Code to be set when the Old Service Provider authorization is set to false.

R5-30.1 Modify Subscription Version — Validation Failure Notification

NPAC SMS shall send an error message to the originating user if the modified pending or conflict Subscription Version fails validations.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-27	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-30.2 Modify Subscription Version — Validation Error Processing

NPAC SMS shall leave the original version intact upon validation failure of a modified pending or conflict Subscription Version.

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.

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

RR5-10.3 Modify Subscription Version — Cause Code in Notification

NPAC SMS shall include the cause code for conflict in the conflict notification to the Old and New Service Provider when a Subscription Version is set to conflict upon Subscription Version modification.

5.1.2.2.2.2 Modification of an Active/Disconnect Pending Subscription Version

RR5-136 Modify Active Subscription Version with a Failed-SP List – Invalid Request Notification

NPAC SMS shall send an appropriate error message to the originating user if the Failed-SP list contains any entries upon a request to modify an “active” subscription version.

RR5-11 Modify Active/Disconnect-Pending Subscription Version — Service Provider Owned

NPAC SMS shall allow only NPAC personnel and the current Service Provider to modify their own active/disconnect-pending Subscription Versions.

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 (or a specified range of numbers) and status of Active
or
Subscription Version ID

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-28	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-36 Modify Active Subscription Version — Input Data

NPAC SMS shall allow the following data to be modified for an active Subscription Version: (reference NANC 399)

• 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

• WSMSC DPC (if supported by the Service Provider SOA)

• WSMSC SSN (if supported by the Service Provider SOA)

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

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

• Alternative SPID (if supported by the Service Provider SOA)

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-6 upon Subscription Version modification of an active version: (reference NANC 399)

• LRN

• Class DPC

• Class SSN

• LIDB DPC

• LIDB SSN

• CNAM DPC

• CNAM SSN

• ISVM DPC

• ISVM SSN

• WSMSC DPC (if supported by the Service Provider SOA)

• WSMSC SSN (if supported by the Service Provider SOA)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-29	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

RR5-124 Modify Disconnect Pending Subscription Version — Input Data

NPAC SMS shall allow the following data to be modified for a disconnect pending Subscription Version:

• Customer Disconnect Date

• Effective Release Date

(Previously NANC 249 Req 1)

RR5-125 Modify Disconnect Pending 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-6 upon Subscription Version modification of a disconnect pending version:

• Customer Disconnect Date

• Effective Release Date

(Previously NANC 249 Req 2)

RR5-126 Modify Disconnect Pending Subscription Version – Valid Dates for CDD and ERD

NPAC SMS shall allow a Subscription Version Modify Disconnect Pending Request, to contain date/time values in the past for the Customer Disconnect Date and Effective Release Date. (Previously NANC 249 Req 6)

RR5-127 Modify Disconnect Pending Subscription Version — Version Identification

NPAC SMS shall require the following data from NPAC personnel ,NPAC SOA Low-tech Interface users,or SOA to NPAC SMS interface users to identify the disconnect pending Subscription Version to be modified:

• Ported Telephone Numbers (or a specified range of numbers) and status of Disconnect Pending
         or

• Subscription Version ID

(Previously NANC 249 Req 3)

RR5-128 Modify Disconnect Pending Subscription Version – Rejection for Empty CDD

NPAC SMS shall reject a Subscription Version Modify Disconnect Pending Request, if the new value for the Customer Disconnect Date is not populated. (Previously NANC 249 Req 5)

Note: If changing the Customer Disconnect Date, the date must be populated in the message that is sent to the NPAC. If the SOA is not changing the date, the date must still be sent to the NPAC in the Modify Disconnect Pending Request with the same/current value.

Note: In the case where a SOA is modifying a range of disconnect-pending Subscription Versions that have different CDD or ERD values, all of the Subscription Versions in that range will be updated to the same CDD or ERD value, even though they previously had different values.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-30	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-39.1 Modify Active/Disconnect Pending Subscription Version — Validation Failure Notification

NPAC SMS shall send an appropriate error message to the originating user if the modified active/disconnect pending Subscription Version fails validations.

R5-39.2 Modify Active/Disconnect Pending Subscription Version — Validation Error Processing

NPAC SMS shall leave the original version intact upon validation failure of a modified active/disconnect pending Subscription Version.

RR5-46 Modify Active Subscription Version- Creation of Old Subscription Version

DELETED

RR5-47 Modify Active Subscription Version- Old Subscription Version No Broadcast

DELETED

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 initiation of broadcasting of the modified active Subscription Version.

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.

R5-40.4 Modify Active Subscription Version — Broadcast complete Time Stamp

NPAC SMS shall record the current date and time as the Broadcast Complete Date and Time Stamp, after one Local SMS has successfully acknowledged modifying the new Subscription Version.

R5-41 Activation Of A Modified Subscription Version

NPAC SMS shall proceed with the broadcast modified active subscription process upon successful modification of an active Subscription Version.

RR5-129 Activation Of A Modified Disconnect Pending Subscription Version when ERD is Modified to Current Date

NPAC SMS shall proceed with the broadcast immediate disconnect subscription process upon successful modification of a disconnect pending Subscription Version, only in cases where the Effective Release Date has been modified to the current date/time or previous date/time, in the NPAC SMS. (Previously NANC 249 Req 4)

Note: If the ERD is set to a future date/time, the NPAC SMS will not broadcast any updates at the time of modification. The disconnect broadcast will occur once the future date/time has been reached in the NPAC SMS.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-31	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-41.1 Broadcast Modified Active Subscription — Local SMS Identification

NPAC SMS shall determine which Local SMSs to send the Subscription Version to by identifying all Local SMSs that are accepting Subscription version data downloads for the given NPA-NXX.

RR5-41.2 Broadcast Modified Active Subscription — Send to Local SMSs

NPAC SMS shall send the modified Subscription version via the NPAC SMS to Local SMS Interface to the Local SMSs

RR5-41.3 Broadcast Modified Active Subscription — Set to Sending

NPAC SMS shall set the Subscription Version status to sending upon sending the Subscription version to the Local SMSs.

RR5-41.4 Modify Active Subscription Version — Return Status

NPAC SMS shall upon completion of the broadcast (failed or successful) return the status of the modified active subscription to its previous state.

RR5-41.5 Modify Active Subscription Activation Retry Attempts — Tunable Parameter

NPAC SMS shall use the Subscription Modification 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 modify request.

RR5-41.6 Modify Active Subscription Activation Retry Interval — Tunable Parameter

NPAC SMS shall use the Subscription Modification Retry Interval tunable parameter, which defines the delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the modify request.

RR5-41.7 Modify Active Subscription Version Failure Retry

NPAC SMS shall resend the modified Subscription Version a Subscription Modification Retry Attempts tunable parameter number of times to a Local SMS that has not acknowledged the receipt of the modification request once the Subscription Activation Retry Interval tunable parameter expires.

RR5-41.8 Modify Active Subscription Version Failure — Status Sending

NPAC SMS shall retain the status for the Subscription Version being modified as sending until the earlier of the Subscription Version retry period has expired for all Local SMSs, or until all Local SMSs have acknowledged the modification.

RR5-41.9 Modify Active Subscription Version Failure — Local SMS Identification

NPAC SMS shall notify the NPAC SMS Administrator of all Local SMSs where a modify has failed, once each Local SMS has successfully responded or failed to respond during the modification retry period.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-32	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-41.10 Subscription Version Activation — Resend to Failed Local SMSs

NPAC SMS shall provide NPAC SMS personnel with the functionality to re-send modify active Subscription Version requests to all failed Local SMSs.

RR5-41.11 Modify Active Subscription Version — Failed Local SMS Notification Current Service Provider

NPAC SMS shall send a list to the Current Service Provider of all Local SMSs that failed modification when a Subscription Version modify active fails.

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.

NOTE: An old Service Provider can place a subscription version in conflict by setting the authorization flag to “False”, as noted in        requirement R5-27.4

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 or Old Service Provider to identify the Subscription Version to be placed in conflict:

Ported Telephone Number (or a specified range of numbers)
or
Subscription Version ID

R5-43.1 Conflict Subscription Version — Invalid Status Notification

NPAC SMS shall send an error message to the NPAC personnel or old Service Provider if the version status is not pending or cancel pending upon attempting to set the Subscription Version to conflict.

R5-43.2 Conflict Subscription Version — No Cause Code Notification

NPAC SMS shall send an error message to the SOA if the cause code is not specified upon setting the Subscription Version to conflict.

RR5-42.1 Conflict Subscription Version — Old Service Provider Number Restriction

NPAC SMS shall only allow a subscription version to be placed into conflict by the Old Service provider one time, which includes the changing of the cause code on a subscription version.

RR5-42.2 Conflict Subscription Version — Conflict Restriction Window

NPAC SMS shall provide a Conflict Restriction Tunable which is defined as the time on the business day prior to the New Service Provider due date that a pending Subscription Version can no longer be placed into conflict state by the old Service Provider.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-33	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-50 Conflict Subscription Version — Conflict Restriction Window- Old Service Provider

NPAC SMS shall provide a Conflict Restriction Window that restricts an Old Service Provider from putting a Subscription Version into Conflict.

RR5-51 Conflict Subscription Version – Conflict Restriction Rules for Old Service Provider

NPAC SMS shall restrict a Subscription Version from being placed into Conflict by the Old Service Provider, when the Conflict Restriction Window Tunable Time is reached AND the Final Concurrence Timer (T2) has expired.

AR5-2 Conflict Restriction Window Tunable due date value

The date used for the Conflict Restriction Window Tunable calculation relies on the date value specified in the New Service Provider due date.

RR5-42.3 Conflict Subscription Version — Conflict Restriction Window Tunable

NPAC SMS shall allow the NPAC SMS Administrator to modify the Conflict Restriction Window Tunable parameter.

RR5-42.4 Conflict Subscription Version — Conflict Restriction Window Tunable Default

NPAC SMS shall default the Conflict Restriction Window Tunable parameter to 17:00/18:00 UTC, adjusted for Standard/Daylight time changes.

RR5-42.5 Conflict Subscription Version – Short Timer Usage

NPAC SMS shall not apply the Conflict Restriction Window Tunable to subscription versions being ported using short timers.

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.

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 calendar days a Subscription Version will remain in conflict prior to cancellation.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-34	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-45.2 Conflict Expiration Window — Tunable Parameter Default

NPAC SMS shall default the Conflict Expiration Window tunable parameter to 30 calendar 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 calendar 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

R5-46 Conflict Resolution Subscription Version — Version Identification

NPAC SMS shall require the following data from the NPAC personnel user, new, or old Service Provider to identify the Subscription Version to be set from conflict to pending:

Ported Telephone Number, (or a specified range of numbers)
or
Subscription Version ID

R5-47 Conflict Resolution 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 pending.

R5-50.1 Conflict Resolution Subscription Version — Set Status

NPAC SMS shall set the version status to pending if the Subscription Version is in conflict upon a request from NPAC personnel, new, or old service providers to set a Subscription Version to pending.

R5-50.2 Conflict Resolution 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 pending.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-35	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-12.1 Conflict Resolution Subscription Version — Inform Both Service Providers of Pending Status

NPAC SMS shall inform both Service Providers when the status of a Subscription Version is set to pending for an Inter-Service Provider port.

RR5-12.3 Conflict Resolution New Service Provider Restriction Tunable Parameter

NPAC SMS shall provide long and short Conflict Resolution New Service Provider Restriction tunable parameters which are defined as a number of business hours after the subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the New Service Provider.

RR5-12.4 Long Conflict Resolution New Service Provider Restriction — Tunable Parameter Default

NPAC SMS shall default the long Conflict Resolution New Service Provider Restriction tunable parameter to 6 business hours.

RR5-12.5 Conflict Resolution New Service Provider Restriction Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administration to modify the long and short Conflict Resolution New Service Provider Restriction tunable parameters.

RR5-12.6 Short Conflict Resolution New Service Provider Restriction — Tunable Parameter Default

NPAC SMS shall default the short Conflict Resolution New Service Provider Restriction tunable parameter to 6 business hours.

RR5-14 Conflict Resolution Acknowledgment — Update Conflict Resolution Date and Time Stamp

NPAC SMS shall update the conflict resolution date and time stamp with the current date and time and set the old Service Provider Authorization flag to true when conflict is resolved.

RR5-137 Conflict Resolution Subscription Version – Restriction for Cause Code Values

NPAC SMS shall restrict the resolution of a Subscription Version with a status of conflict and a cause code value of 50 or 51, to only allow resolution by the Old Service Provider. (previously NANC 375, Req 1)

RR5-138 Conflict Resolution Subscription Version –Conflict Resolution New Service Provider Restriction Tunable Application

NPAC SMS shall apply the Conflict Resolution New Service Provider Restriction Tunable only for a Subscription Version with a status of conflict and a cause code value NOT EQUAL TO 50 or 51. (previously NANC 375, Req 2)

RR5-139 Conflict Resolution Subscription Version – Restricted Cause Code Notification

NPAC SMS shall send an error message to the New Service Provider if the Subscription Version status is conflict AND the cause code value is 50 or 51, upon attempting to set the Subscription Version to pending. (previously NANC 375, Req 3)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-36	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-168 Regional Prevent Conflict Resolution 50/51 Tunable

NPAC SMS shall provide a Regional Prevent Conflict Resolution 50/51 tunable parameter, which is defined as an indicator on whether or not the prevention of conflict resolution for cause codes 50 or 51 by the New Service Provider is supported by the NPAC SMS for a particular NPAC Region. (previously NANC 375, Req 10)

RR5-169 Regional Prevent Conflict Resolution 50/51 Tunable Default

NPAC SMS shall default the Regional Prevent Conflict Resolution 50/51 tunable parameter to TRUE. (previously NANC 375, Req 11)

RR5-170 Regional Prevent Conflict Resolution 50/51 Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Regional Prevent Conflict Resolution 50/51 tunable parameter. (previously NANC 375, Req 12)

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. Requirements related to activation are contained in requirement R5-23.

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 a specified range of numbers)
or
Subscription Version ID

R5-51.2 Activate Subscription Version — Broadcast Complete Date and Time Stamp

NPAC SMS shall record the current date and time as the Activation Broadcast Complete Date and Time Stamp, as soon as one Local SMS has successfully acknowledged activating the new Subscription Version.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-37	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-53.1 Activate Subscription Version — Validation

NPAC SMS shall verify that a Subscription Version is in a valid pending state by checking that a new Service Provider time stamp exists and that the effective date of the NPA-NXX has been reached.

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.

R5-53.3 Activate Subscription Version — Validate Due Date

NPAC SMS shall verify that a pending Subscription Version is eligible for activation by ensuring that the new Service Provider due date is less than or equal to the current date.

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 for the given NPA-NXX.

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 initiating 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 calendar days Local SMS activation responses will remain in the log.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-38	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-39	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

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 resulting from an subscription version activation request 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 — Set Status to Failure

NPAC SMS shall set the status of the Subscription Version to failed if the Subscription Version fails activation resulting from an subscription version activation request 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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-40	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

RR5-60 Activate Intra-Service Provider Port – After NPA-NXX-X Creation and Prior to the Existence of the Block

NPAC SMS shall allow NPAC personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to activate intra-service provider ports for a TN within the 1K Block, where there is no active Subscription Version in the NPAC SMS. (Previously SV-200)

RR5-61 Activate Port-to-Original Subscription Version – Broadcast of Subscription Data Creation

The NPAC SMS shall broadcast a new Subscription Version Create to a non-EDR Local SMS, upon activating a port-to-original Subscription Version, where the TN is within the range of a 1K Block, once the Block exists in the NPAC SMS. (Previously SV-210)

RR5-62 Activate Port-to-Original Subscription Version – Broadcast of Subscription Data Deletion

The NPAC SMS shall broadcast a Subscription Version Delete to an EDR Local SMS, upon activating a port-to-original Subscription Version, where the TN is within the range of a 1K Block, once the Block exists in the NPAC SMS. (Previously SV-220)

RR5-171 Activate Subscription Version — Send SV Type Data to Local SMSs

NPAC SMS shall, for a Service Provider that supports SV Type, send the SV Type attribute for an activated Inter or Intra-Service Provider Subscription Version port via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 13)

RR5-172 Activate Subscription Version — Send Alternative SPID to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alternative SPID, send the Alternative SPID attribute for an activated Inter or Intra-Service Provider Subscription Version port via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 14)

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-41	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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 a specified range of 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.

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 if a version of that subscription version with a status other than canceled or old exists.

RR5-48 Disconnect Pending Subscription Version- Creation of Old Subscription Version

DELETED

RR5-49 Disconnect Pending Subscription Version- Old Subscription Version No Broadcast

DELETED

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-42	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.4 Disconnect Subscription Version — Broadcast Interface Message to Local SMSs

NPAC SMS shall broadcast the disconnect Subscription Version message to the Local SMSs that are accepting Subscription Version data downloads for the given NPA-NXX 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.

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.2 Disconnect Subscription Version Complete — Set Disconnect Complete Date

NPAC SMS shall update the Disconnect Complete timestamp of the previously active Subscription Version upon completion of the broadcast, and the FIRST successful response from a Local SMS.

R5-66.3 Disconnect Subscription Version Complete — Set Disconnect to Old

NPAC SMS shall set the disconnect Subscription Version to old if a successful response from at least one Local SMS is returned.

R5-66.4 Disconnect Subscription Version Complete – Status Update of SV

NPAC SMS shall update the status of the disconnect Subscription Version upon completion of the Deletion broadcast, and a response from ALL Local SMSs, or retries are exhausted.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-43	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-67.1 Disconnect Subscription Version — Set Status to Active

NPAC SMS shall set the status of the disconnect Subscription Version to active 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 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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-44	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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.

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 Old

NPAC SMS shall set the disconnect Subscription Version status to old 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.

RR5-63 Disconnect Subscription Version or Port-To-Original – Pooled Number Block Default Routing Restoration

The NPAC SMS shall reinstate the Block default routing, block holder Service Provider Id and the LNP Type to POOL for a subscription version upon a disconnect for a ported TN, or an activate for a Port-To-Original TN, belonging to the 1K Block, once the Block exists in the NPAC SMS, except for a status of Old, with or without a Block Failed SP List. (Previously SV-390)

RR5-64 Disconnect Subscription Version — Customer Disconnect Date Notification for Pooled Number

NPAC SMS shall notify the Block Holder of the Subscription Version Customer Disconnect Date and Effective Release Date, for a ported pooled Subscription Version that is being disconnected, prior to reinstating the default routing. (Previously SV-400)

RR5-65 Disconnect Subscription Version – Broadcast of Subscription Data Creation

The NPAC SMS shall broadcast a new Subscription Version Create to a non-EDR Local SMS, upon a disconnect of a ported pooled Subscription Version, where the TN is within the 1K Block. (Previously SV-410)

RR5-66 Disconnect Subscription Version – Broadcast of Subscription Data Deletion

The NPAC SMS shall broadcast a Subscription Version Delete to an EDR Local SMS, upon a disconnect of a ported pooled Subscription Version, where the TN is within the 1K Block. (Previously SV-420)

RR5-67.1 Disconnect Subscription Version – Updates to the Status for Disconnect

NPAC SMS shall update the Status of the individual subscription version(s) broadcast to the EDR Local SMSs, and the individual subscription version(s) broadcast to the non-EDR Local SMSs, upon completion of the disconnect broadcast to ALL EDR and non-EDR Local SMSs. (Previously SV-422.1)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-45	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-67.2 Disconnect Subscription Version – Setting of the Status for Disconnected SV

NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being disconnected to: (Previously SV-422.2)

• Active, if ALL EDR and non-EDR Local SMSs, fail the broadcast.

• Old, for all other cases.

RR5-67.3 Disconnect Subscription Version – Setting of the Status for Newly Created SV

NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being created to reinstate default routing to: (Previously SV-422.3)

• Active, if all EDR and non-EDR Local SMSs, respond successfully to the broadcast.

• Failed, if all EDR and non-EDR Local SMSs, fail the broadcast, or retries are exhausted.

• Partial Failure, for all other cases.

RR5-68.1 Disconnect Subscription Version – Updates to the Status for Port-to-Original

NPAC SMS shall update the Status of the individual subscription version(s) broadcast to the EDR Local SMSs, the individual subscription version(s) broadcast to the non-EDR Local SMSs, and the individual subscription version(s) representing the port-to-original request, upon completion of the Port-To-Original broadcast to ALL EDR and non-EDR Local SMSs. (Previously SV-423.1)

RR5-68.2 Disconnect Subscription Version – Setting of the Status for Port-to-Original SV

NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being ported-to-original to: (Previously SV-423.2)

• Old, if ALL EDR and non-EDR Local SMSs, respond successfully to the broadcast.

• Failed, if ALL EDR and non-EDR Local SMSs, fail the broadcast, or retries are exhausted.

• Partial Failure, for all other cases.

RR5-68.3 Disconnect Subscription Version – Setting of the Status for Port-to-Original SV that was active prior to the PTO activation request

NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the previously active Subscription Version being disconnected due to the port-to-original request to: (Previously SV-423.3)

• Active, if ALL EDR and non-EDR Local SMSs, fail the broadcast.

• Old, for all other cases.

RR5-68.4 Disconnect Subscription Version – Setting of the Status for Port-to-Original for Newly Created SV

NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being created to reinstate default routing for the port-to-original request to: (Previously SV-423.4)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-46	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• Active, if all EDR and non-EDR Local SMSs, respond successfully to the broadcast.

• Failed, if all EDR and non-EDR Local SMSs, fail the broadcast, or retries are exhausted.

• Partial Failure, for all other cases.

RR5-69 Disconnect Subscription Version – Updates to the Failed SP List for Disconnect

NPAC SMS shall update the Subscription Version Failed SP List of the individual subscription version(s) that were broadcast to the EDR Local SMSs with the discrepant Local SMS(s) , upon completion of the broadcast of the delete of the Subscription Version(s) to EDR Local SMSs, and the create of the Subscription Version(s) to non-EDR Local SMSs. (Previously SV-425)

Note: The NPAC SMS will roll up the Subscription Version Failed SP List so that the SV that was active prior to the disconnect request (SV1) contains the Failed SP List for both SV1 and SV2, as defined in the IIS Flows for Disconnect of a Ported Pooled Number.

RR5-70 Disconnect Subscription Version – Updates to the Failed SP List for Port-To-Original

NPAC SMS shall update the Subscription Version Failed SP List of the individual subscription version(s) that were sent up in the Port-to-Original Activate request by the SOA with the discrepant Local SMS(s), upon completion of the broadcast of the delete of the Subscription Version(s) to EDR Local SMSs, and the create of the Subscription Version(s) to non-EDR Local SMSs. (Previously SV-426)

Note: The NPAC SMS will roll up the Subscription Version Failed SP List so that the SV that was active prior to the port-to-original activate request (SV2) contains the Failed SP List for both SV1 and SV3, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number.

5.1.2.2.6 Subscription Version Cancellation

This section provides the requirements for the Subscription Version Cancellation functionality (including “un-do” of a ‘cancel-pending’ Subscription Version), 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 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 a specified range of numbers)
or
Subscription Version ID

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-47	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

R5-71.3 Cancel Subscription Version- Set to Cancel Old Service Provider only

NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the old Service Provider if the New Service Provider has not sent a subscription version create.

R5-71.4 Cancel Subscription Version- Set to Cancel New Service Provider only

NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the New Service Provider if the Old Service Provider has not sent an subscription version create.

R5-71.5 Cancel Subscription version- Error on Cancellation

NPAC SMS shall return an error if a Service Provider sends a cancellation for a subscription version that has not been created by that Service Provider.

R5-71.6 Cancel Subscription Version- Set Pending subscription version to Cancel Pending Status Inter-Service Provider port

NPAC SMS shall set the subscription version status to Cancel Pending upon receiving a cancellation from either the Old or New Service Provider for a subscription version with a pending status (both Service Providers have done a create) for an Inter-Service Provider or Port to original port.

R5-71.8 Cancel Subscription Version- Set Conflict Subscription to Cancel New Service Provider only

NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the new Service Provider on a subscription in conflict that was previously in cancel pending and for which only the old service provider has sent a cancellation acknowledgment.

R5-71.9 Cancel Subscription Version — Rejection of Old Service Provider Conflict Cancellation

NPAC SMS shall return an error to the Old Service Provider if they attempt to cancel a Subscription Version that is in conflict due to lack of New Service Provider cancellation concurrence on a subscription version that was previously in cancel pending state.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-48	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

R5-71.10 Cancel Subscription Version- Set Disconnect Pending subscription version to Active

NPAC SMS shall set the subscription version status to Active upon receiving a cancellation for a subscription version with a status of disconnect pending.

R5-71.11 Cancel Subscription Version- Set to Cancel Status — Intra-Service Provider port

NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the current Service Provider for an Intra-Service Provider port.

RR5-28.1 Cancel Subscription Version — Set to Cancel After Service Provider Acknowledge

NPAC SMS shall set the Subscription Version status to cancel upon receiving cancellation pending acknowledgment from the Service Provider that did not initiate the cancellation for an Inter-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 port.

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 long and short Cancellation-Initial Concurrence Window tunable parameters, which are defined as the number of business hours after the version is set to Cancel Pending by which the non-originating Service Provider is 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 long and short Cancellation-Initial Concurrence Window tunable parameters.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-49	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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

NPAC SMS shall default the long Cancellation-Initial Concurrence Window tunable parameter to 9 business hours.

RR5-32.4 Short Cancellation-Initial Concurrence Window — Tunable Parameter Default

NPAC SMS shall default the short Cancellation-Initial Concurrence Window tunable parameter to 9 business hours.

RR5-33.1 Cancellation-Final Concurrence Window — Tunable Parameter

NPAC SMS shall provide long and short Cancellation-Final Concurrence Window tunable parameters which are defined as the number of business hours after the second cancel pending notification is sent by which both Service Providers are expected to acknowledge the pending cancellation.

RR5-33.2 Cancellation-Final Concurrence Window Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Cancellation-Final Concurrence Window tunable parameters.

RR5-33.3 Long Cancellation-Final Concurrence Window — Tunable Parameter Default

NPAC SMS shall default the long Cancellation-Final Concurrence Window tunable parameter to 9 business hours.

RR5-33.4 Short Cancellation-Final Concurrence Window — Tunable Parameter Default

NPAC SMS shall default the short Cancellation-Final Concurrence Window tunable parameter to 9 business hours.

RR5-34 Cancellation-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 cancel pending status when the Cancellation-Initial Concurrence Window tunable parameter expires.

RR5-35.1 Cancellation-Final Concurrence Window — Tunable Parameter Expiration New Service Provider

NPAC SMS shall set the Subscription Version status to conflict when the NPAC SMS has not received the cancellation acknowledgment from the new Service Provider and the Cancellation-Final Concurrence Window tunable parameter has expired.

RR5-35.2 Cancellation-Final Concurrence Window — Tunable Parameter Expiration Old Service Provider

NPAC SMS shall set the Subscription Version status to cancel and set the cause code to “NPAC SMS automatic cancellation” when the NPAC SMS has not received the cancellation acknowledgment from the Old Service Provider and the Cancellation-Final Concurrence Window tunable parameter has expired.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-50	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-36.1 Cancel Subscription Version – Cause Code for New SP Timer Expiration

NPAC SMS shall set the cause code to “NPAC SMS Automatic Conflict from Cancellation” after setting the Subscription Version status to conflict from cancel-pending when the new Service Provider has not acknowledged the cancellation and after the Cancellation-Final Concurrence Window has expired. (previously NANC 138, Req 1)

RR5-36.2 Cancel Subscription Version — Inform Service Providers of Conflict Status

NPAC SMS shall notify the old and new Service Providers upon setting a cancel-pending Subscription Version to conflict after the expiration of the Initial and Final Cancellation Concurrence Window tunables.

Note: If the cause code value is set to “NPAC SMS Automatic Conflict from Cancellation”, and the Service Provider does NOT support this cause code, the existing message will be unchanged.

RR5-140 Cancel-Pending-to-Conflict Cause Code Indicator

NPAC SMS shall provide a Cancel-Pending-to-Conflict Cause Code Indicator tunable parameter which defines whether a SOA supports a Conflict message that uses the Cancel-Pending-to-Conflict Cause Code. (previously NANC 138, Req 1.5)

RR5-141 Cancel-Pending-to-Conflict Cause Code Indicator Default

NPAC SMS shall default the Service Provider SOA Cancel-Pending-to-Conflict Cause Code Indicator tunable parameter to FALSE. (previously NANC 138, Req 2)

RR5-142 Cancel-Pending-to-Conflict Cause Code Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Cancel-Pending-to-Conflict Cause Code Indicator tunable parameter. (previously NANC 138, Req 3)

RR5-165 Regional Automatic Conflict Cause Code Tunable

NPAC SMS shall provide a Regional Automatic Conflict tunable parameter, which is defined as an indicator on whether or not the automatic conflict cause code functionality is supported by the NPAC SMS for a particular NPAC Region. (previously NANC 138, Req 4)

RR5-166 Regional Automatic Conflict Cause Code Tunable Default

NPAC SMS shall default the Regional Automatic Conflict Cause Code tunable parameter to TRUE. (previously NANC 138, Req 5)

RR5-167 Regional Automatic Conflict Cause Code Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Regional Automatic Conflict Cause Code tunable parameter. (previously NANC 138, Req 6)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-51	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

5.1.2.2.6.1 Un-do a “Cancel-Pending” Subscription

RR5-143 Un-Do a Cancel-Pending Subscription Version – Notification

NPAC SMS shall inform both Old and New Service Providers when the status of a Subscription Version is set from cancel-pending back to pending for an Inter-Service Provider port. (previously NANC 388, Req 1)

RR5-144 Un-Do a Cancel-Pending Subscription Version – Request Data

NPAC SMS shall receive the following data from the Old or New Service Provider to identify a Subscription Version to have a cancel request retracted:

o Ported TN (or a specified range of numbers)

o Subscription Version ID

o Version Status (if TN or TN range is specified, should be cancel-pending)

o New Version Status (can be only pending)

(previously NANC 388, Req 2)

RR5-164 Un-Do a Cancel-Pending Subscription Version – New Status Specified Error

NPAC SMS shall send an appropriate error message to the originating user that requests a cancellation retraction for a subscription version, if the new version status specified in the request is not pending. (previously NANC 388, Req 2.5)

RR5-145 Un-Do a Cancel-Pending Subscription Version – Version Status Error

NPAC SMS shall send an appropriate error message to the originating user that requests a cancellation retraction for a subscription version, if the current version status is not cancel-pending. (previously NANC 388, Req 3)

RR5-146 Un-Do a Cancel-Pending Subscription Version – SP Error

DELETED

RR5-147 Un-Do a Cancel-Pending Subscription Version – Timestamp

NPAC SMS shall set the Subscription Version modification date and time to current upon setting the Subscription Version status back to pending. (previously NANC 388, Req 5)

RR5-148 Un-Do a Cancel-Pending Subscription Version – Missing Create Error

DELETED

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-52	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-149 Un-Do a Cancel-Pending Subscription Version – Missing Cancel Error

NPAC SMS shall return an error if a Service Provider sends a cancellation retraction for a subscription version that has not been cancelled by that Service Provider. (previously NANC 388, Req 7)

RR5-150 Un-Do a Cancel-Pending Subscription Version – Status Change

NPAC SMS shall set the subscription version status to Pending upon receiving a cancellation retraction from either the Old or New Service Provider for a subscription version with a cancel-pending status (both Service Providers have done a create) for an Inter-Service Provider or Port to original port. (previously NANC 388, Req 8)

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.1 Resend Subscription Version — Identify Subscription Version

NPAC SMS shall receive the following data from NPAC personnel to identify a subscription version that contains a Failed SP List with one or more SPIDS, to be resent:

Ported Telephone Number
or
Subscription Version ID

RR5-38.1.2 Resend Subscription Version – Identify Multiple Subscription Versions

NPAC SMS shall require NPAC personnel to specify a TN Range (NPA-NXX-xxxx through yyyy, where yyyy is greater than xxxx) to identify multiple subscription versions that contain a Failed SP List with one or more SPIDS, to be resent.

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 upon Subscription Version resend if the version does not have a list of failed LSMSs associated with the subscription’s last operation.

RR5-38.4 Resend Subscription Version — Activation Request

NPAC SMS shall resend a Subscription Version activation request, if the Subscription Version previously failed activation, to the designated list of failed Local SMSs via the NPAC SMS to Local SMS Interface upon a Subscription Version resend request.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-53	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-38.5 Resend Subscription Version — Disconnect Request

NPAC SMS shall resend a Subscription Version disconnect request, if the Subscription Version previously failed disconnect, to the designated list of failed Local SMSs via the NPAC SMS to Local SMS Interface 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 via the NPAC SMS to Local SMS Interface.

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

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

RR5-38.9 Resend Subscription Version – Modify Active Request

NPAC SMS shall resend a Subscription Version modify active request, if 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.10 Resend Subscription Version — Standard Modify Active Processing

NPAC SMS shall proceed with the standard modify active processing subsequent to resending a Subscription Version modify request to the Local SMSs via the NPAC SMS to Local SMS Interface.

RR5-71 Re-Send of Number Pooling Subscription Version Information – NPAC Personnel OpGUI

NPAC SMS shall prevent NPAC Personnel from re-sending a Subscription Version with LNP Type of POOL, via the NPAC Administrative Interface. (Previously SV-451)

Note: The re-send of SVs with LNP Type of POOL to non-EDR Local SMSs shall be initiated from the Block Re-send on the NPAC Administrative GUI.

RR5-72 Re-Send of Number Pooling Subscription Version Information – Subscription Versions sent to discrepant non-EDR Local SMS

NPAC SMS shall re-send Subscription Versions to a discrepant non-EDR Local SMS via the NPAC SMS to Local SMS Interface, when a re-send request is initiated to a Block. (Previously SV-452)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-54	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-73 Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Failed Subscription Versions for Block Activation

NPAC SMS shall update the status of the failed Subscription Versions with LNP Type of POOL in the 1K Block, at the start of the re-send to the Local SMSs, from a failed status to a sending status. (Previously SV-460)

RR5-74 Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Partial failure Subscription Versions for Block Activation

NPAC SMS shall update the status of the partial failure Subscription Versions with LNP Type of POOL in the 1K Block, at the start of the re-send to the Local SMSs, from a partial failure status to a sending status. (Previously SV-470)

RR5-75 Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Active Subscription Version for Block Modification or Deletion

NPAC SMS shall update the status of the active Subscription Version with LNP Type of POOL in the 1K Block, with a Failed SP List, at the start of the re-send to the Local SMSs, from an active status to a sending status. (Previously SV-480)

RR5-76 Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Old Subscription Version for Block Deletion

NPAC SMS shall update the status of the old Subscription Version with LNP Type of POOL in the 1K Block, with a Failed SP List, at the start of the re-send to the Local SMSs, from an old status to a sending status. (Previously SV-490)

RR5-77 Re-Send of Number Pooling Subscription Version Information – Update to Failed SP List

NPAC SMS shall update the Subscription Version Failed SP List of the Subscription Version(s) with LNP Type of POOL in the 1K Block, by removing the previously failed Local SMS, upon a successful re-send to a previously failed Local SMS. (Previously SV-510)

RR5-78 Re-Send of Number Pooling Subscription Version Information –Status Update to Subscription Version after Re-Send

NPAC SMS shall update the status of the Subscription Version(s) and the Block, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS or if retries have been exhausted, from a sending status, as defined in RR3-137.1, RR3-137.2 RR3-137.3, and RR3-137.4. (Previously SV-515)

RR5-79 Re-Send of Number Pooling Subscription Version Information –Failed SP List Update to Subscription Version after Re-Send

NPAC SMS shall update the Subscription Version Failed SP List of the Subscription Version(s) with LNP Type of POOL in the 1K Block, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS, or if retries have been exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-516)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-55	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-80 Re-Send of Subscription Version Information – Disconnect or Port-To-Original of a TN within a Pooled 1K Block

NPAC SMS shall examine a Service Provider’s EDR Indicator, at the time of re-send, to determine the message to re-send, for a disconnect or a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block. (Previously SV-518)

RR5-81.1 Re-Send of Subscription Version Information – Disconnect TN within a Pooled 1K Block to EDR Local SMS

NPAC SMS shall, for a re-send of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Delete request of the Subscription Version that was active prior to the disconnect broadcast to a discrepant EDR Local SMS. (Previously SV-519.1)

Note: The NPAC SMS will re-send an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the disconnect request (SV2), as defined in the IIS Flows for Disconnect of a Ported Pooled Number.

RR5-81.2 Re-Send of Subscription Version Information – Disconnect TN within a Pooled 1K Block to non-EDR Local SMS

NPAC SMS shall, for a re-send of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Create request of the Subscription Version that was created to restore default routing to a discrepant non-EDR Local SMS. (Previously SV-519.2)

Note: The NPAC SMS will re-send an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV2) that was created to restore default routing (SV1), although the Failed SP List resides on SV1, as defined in the IIS Flows for Disconnect of a Ported Pooled Number.

RR5-82.1 Re-Send of Subscription Version Information –Port-To-Original TN within a Pooled 1K Block to EDR Local SMS

NPAC SMS shall, for a re-send of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast to a discrepant EDR Local SMS. (Previously SV-520.1)

Note: The NPAC SMS will re-send an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number.

RR5-82.2 Re-Send of Subscription Version Information –Port-To-Original TN within a Pooled 1K Block to non-EDR Local SMS

NPAC SMS shall, for a re-send of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Create request of the Subscription Version that was created to restore default routing, and shall NOT re-broadcast the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast to a discrepant non-EDR Local SMS. (Previously SV-520.2)

Note: The NPAC SMS will re-send an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV3) that was created to restore default routing, and will NOT re-send an M-DELETE of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-56	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-151 Subscription Version Failed SP List – Exclusion of a Service Provider from Resend

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to request that a Service Provider be excluded from the Subscription Version Failed SP List when resending an Inter-Service Provider port or Intra-Service Provider port Version, and not broadcast to the Service Provider that is excluded. (previously NANC 227/254 Req 1)

RR5-152 Subscription Version Failed SP List – Logging of an Excluded Service Provider

NPAC SMS shall log the following information when a Service Provider is excluded from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface: date, time, excluded SPID, current SPID, TN, SV-ID. (previously NANC 227/254 Req 2)

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-57	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

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 — SOA

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: (reference NANC 399)

• 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

• Status Change Cause Code

• Location Routing Number (LRN)

• Class DPC

• Class SSN

• LIDB DPC

• LIDB SSN

• CNAM DPC

• CNAM SSN

• ISVM DPC

• ISVM SSN

• WSMSC DPC (for SOAs that support WSMSC data)

• WSMSC SSN (for SOAs that support WSMSC data)

• Billing Service Provider ID

• End-User Location Value

• End User Location Type

• Customer Disconnect Date

• Effective Release Date

• Disconnect Complete Time Stamp

• Conflict Time Stamp

• Broadcast Time Stamp

• Activation Time Stamp

• Cancellation Time Stamp (Status Modified to Canceled 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 (Status Modified to Old Time Stamp)

• New Service Provider Conflict Resolution Time Stamp

• Old Service Provider Conflict Resolution Time Stamp

• Create Time Stamp

• Modified Time Stamp

• Porting to Original

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-58	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• Download Reason

• Timer Type (for SOAs that support Timer Type)

• Business Hours Type (for SOAs that support Business Hours)

• List of all Local SMSs that failed activation, modification, or disconnect.

• SV Type (if supported by the Service Provider SOA)

• Alternative SPID (if supported by the Service Provider SOA)

R5-74.4 Query Subscription Version — Output Data — LSMS

NPAC SMS shall return the following output data for a Subscription Version query request initiated over the NPAC SMS to Local SMS interface: (reference NANC 399)

• 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

• Status Change Cause Code

• 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

• WSMSC DPC (for Local SMSs that support WSMSC data)

• WSMSC SSN (for Local SMSs that support WSMSC data)

• Billing Service Provider ID

• End-User Location Value

• End-User Location Type

• Customer Disconnect Date

• Effective Release Date

• Disconnect Complete Time Stamp

• Conflict Time Stamp

• Broadcast Time Stamp

• Activation Time Stamp

• Cancellation Time Stamp (Status Modified to Canceled 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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-59	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• Old Time Stamp (Status Modified to Old Time Stamp)

• New Service Provider Conflict Resolution Time Stamp

• Old Service Provider Conflict Resolution Time Stamp

• Create Time Stamp

• Modified Time Stamp

• Porting To Original

• Billing Service Provider ID

• Local Number Portability Type

• Download Reason

• Timer Type (for SOAs that support Timer Type)

• Business Hours Type (for SOAs that support Business Hours)

• List of all Local SMSs that failed activation, modification, or disconnect.

• SV Type (if supported by the Service Provider LSMS)

• Alternative SPID (if supported by the Service Provider LSMS)

RR5-153 Subscription Version Query – Sort Order

NPAC SMS shall return Subscription Versions as a result of a Subscription Version query, sorted in TN (primary, ascending) and SV-ID (secondary, ascending) order. (previously NANC 285, Req 3)

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, Partial Failure, Disconnect Pending, Canceled 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, partial-failure, disconnect-pending, canceled or old.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-60	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-174 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 SOA Low-tech Interface. (previously R4-30.2)

RR5-175 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. (previously R4-30.1)

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.

RR5-83 Query Subscription Version – LNP Type of POOL

NPAC SMS shall return Subscription Versions with LNP Type of POOL that match the query selection criteria, on query requests by NPAC personnel, SOA via the SOA to NPAC SMS Interface, Local SMS via the NPAC SMS to Local SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, regardless of the value in the requesting Service Provider’s EDR Indicator. (Previously SV-440)

RR5-154 Subscription Version Query – Maximum Subscription Version Query by the SOA

NPAC SMS shall return the Maximum Subscription Query tunable value of Subscription Versions to a SOA, via the SOA to NPAC SMS Interface, when the user requests a Subscription Version query and the number of Subscription Version records that meet the query criteria exceed the Maximum Subscription Query tunable value and the service provider’s SOA SV Query Indicator is set to True. (previously NANC 285, Req 1)

RR5-155 Subscription Version Query – Maximum Subscription Version Query by the LSMS

NPAC SMS shall return the Maximum Subscription Query tunable value of Subscription Versions to a Local SMS, via the NPAC SMS to Local SMS Interface, when the user requests a Subscription Version query and the number of Subscription Version records that meet the query criteria exceed the Maximum Subscription Query tunable value and the service provider’s LSMS SV Query Indicator is set to True. (previously NANC 285, Req 2)

RR5-176 Count of subscription information during a query

NPAC SMS shall return a “complexity limitation” error and the count of subscription records returned by a query, if more than a tunable parameter number of Subscription Versions are found, and the service provider’s SOA SV Query Indicator or LSMS Query Indicator is set to False (respective to the SOA or LSMS interface over which they are originating the subscription version query request). (previously R4-30.6)

RR5-177 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 Table 3-6 Subscription Version Data Model: (previously R4-29)

• Subscription Version ID

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-61	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

• 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

• 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

• WSMSC DPC

• WSMSC SSN

• Billing Service Provider ID

• End User Location Value

• End User Location Type

• Customer Disconnect Date

• Effective Release Date

• Disconnect Complete Time Stamp

• Conflict Time Stamp

• Activation Time Stamp

• Cancellation Time Stamp (Status Modified to Cancel 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 (Status Modified to Old Time Stamp)

• New Service Provider Conflict Resolution Time Stamp

• Create Time Stamp

• Modify Time Stamp

• Porting To Original

• Status Change Cause Code

• Timer Type

• Business Hour Type

RR5-178 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. (previously R4-30.8)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-62	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-156 Service Provider SOA SV Query Indicator

NPAC SMS shall provide a Service Provider SOA SV Query Indicator tunable parameter which defines whether a SOA supports enhanced SV Query functionality over the SOA-to-NPAC SMS Interface. (previously NANC 285, Req 7)

Note: For Service Providers that do NOT support enhanced SOA SV Query functionality, the NPAC will continue to send a complexityLimitation error message, when the number of SVs in a response exceed the Maximum Subscription Query tunable value.

RR5-157 Service Provider SOA SV Query Indicator Default

NPAC SMS shall default the Service Provider SOA SV Query Indicator tunable parameter to FALSE. (previously NANC 285, Req 8)

RR5-158 Service Provider SOA SV Query Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SV Query Indicator tunable parameter. (previously NANC 285, Req 9)

RR5-159 Service Provider LSMS SV Query Indicator

NPAC SMS shall provide a Service Provider LSMS SV Query Indicator tunable parameter which defines whether a LSMS supports enhanced SV Query functionality over the NPAC SMS-to-Local SMS Interface. (NANC 285, Req 10)

Note: For Service Providers that do NOT support enhanced LSMS SV Query functionality, the NPAC will continue to send a complexityLimitation error message, when the number of SVs in a response exceed the Maximum Subscription Query tunable value.

RR5-160 Service Provider LSMS SV Query Indicator Default

NPAC SMS shall default the Service Provider LSMS SV Query Indicator tunable parameter to FALSE. (NANC 285, Req 11)

RR5-161 Service Provider LSMS SV Query Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SV Query Indicator tunable parameter. (NANC 285, Req 12)

5.1.4 Subscription Version Processing for National Number Pooling

This section details the functional requirements for user interaction (either NPAC Personnel or Service Provider Personnel via their SOA and/or LSMS to NPAC SMS interface) with the NPAC SMS to appropriately operate in the National Number Pooling Environment.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-63	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

5.1.4.1 Subscription Version, General

The following requirements outline the basic NPAC SMS processing requirements for subscription versions in a National Number Pooling environment.

RR5-84 Number Pooling Subscription Version Information – Reject Messages

NPAC SMS shall reject a message from NPAC personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, a Service Provider LSMS via the NPAC SMS to Local SMS Interface, or a Service Provider via the NPAC SOA Low-tech Interface, to Create, Modify, Cancel, Set to Conflict, Activate, or Disconnect, a Subscription Version with an LNP Type of POOL. (Previously SV-1)

RR5-85 Number Pooling Subscription Version Information – Suppression of Notifications

NPAC SMS shall suppress status change and attribute value change notifications to the old and new/current service provider SOA systems for Subscription Versions with LNP Type of POOL. (Previously SV-2)

Note: This includes creation, modification, deletion, re-send, resync, audits, and mass update.

RR5-85.5 Number Pooling Subscription Version Information – Disconnect Notifications to Donor Service Provider

NPAC SMS shall send donor disconnect notifications to the Donor Service Provider (Code Holder) when a Number Pool Block De-pool occurs.

RR5-86 Number Pooling Subscription Version Information – Filters for “Pooled Number” Subscription Versions

NPAC SMS shall apply NPA-NXX Filters to subscription version broadcasts to the Local SMSs, for Subscription Versions with LNP Type of POOL. (Previously SV-3)

RR5-87 Number Pooling Subscription Version Information – Broadcast of Subscription Data

NPAC SMS shall broadcast an addition, modification, or deletion of Subscription Versions, with LNP Type of POOL, to non-EDR LSMSs, via the NPAC SMS to Local SMS Interface, upon successful update of the 1K Block in the NPAC SMS, for Subscription Versions. (Previously SV-4)

RR5-88 Number Pooling Subscription Version Information – Failed SP List Update for Block

NPAC SMS shall consider an EDR Local SMS to be discrepant and shall update the Subscription Version Failed SP List for all Subscription Versions with LNP Type of POOL in the 1K Block, based on an EDR Local SMS failing to process the Block Object, for an addition, modification, deletion, re-send, or mass update. (Previously SV-5)

RR5-89 Number Pooling Subscription Version Information – Data Integrity for Pooled Subscription Versions and Block

NPAC SMS shall maintain data integrity for SPID, LRN and DPC/SSN data, between Subscription Versions with LNP Type of POOL in a 1K Block, and the corresponding Number Pooling Block, in the NPAC SMS. (Previously SV-6)

Release 3.3:© 1997 — 2006 NeuStar, Inc.	5-64	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

5.1.4.2 Subscription Version, Addition for Number Pooling

The following section outlines the NPAC SMS functional requirements for processing pooled subscription version additions. Subscription versions with LNP Type set to POOL are created when a Number Pool Block is activated.

RR5-90 Addition of Number Pooling Subscription Version Information – Subscription Data

NPAC SMS shall create individual subscription versions, with LNP Type of POOL, for each TN within the 1K Block, that does not already exist with a status of active/partial failure/disconnect pending/old with a Failed SP List/sending, immediately after successfully creating Number Pooling Block Holder Information in the NPAC SMS. (Previously SV-10)

RR5-91 Addition of Number Pooling Subscription Version Information – Create “Pooled Number” Subscription Version

NPAC SMS shall automatically populate the following data upon Subscription Version creation for a Pooled Number port: (Previously SV-20, reference NANC 399)

Version ID — Automatically generated by NPAC SMS.
LRN — Value set to same field in Block.
Old Service Provider ID — Value set to owner of NPA-NXX.
New Service Provider ID — Value set to NPA-NXX-X Holder SPID field in Block.
TN — Telephone Number associated with this Subscription Version.
LNP Type — Value set to “POOL”.
Status — Value initially set to “Sending”.
CLASS DPC — Value set to same field in Block.
CLASS SSN — Value set to same field in Block.
LIDB DPC — Value set to same field in Block.
LIDB SSN — Value set to same field in Block.
CNAM DPC — Value set to same field in Block.
CNAM SSN — Value set to same field in Block.
ISVM DPC — Value set to same field in Block.
ISVM SSN — Value set to same field in Block.
WSMSC DPC — Value set to same field in Block.
WSMSC SSN — Value set to same field in Block.
New Service Provider Due Date — Value set to current date.
Old Service Provider Due Date — Value set to current date.
Old Service Provider Authorization — Value set to “TRUE”.
New Service Provider Create Time Stamp — Value set to current date/time.
Old Service Provider Authorization Time Stamp — Value set to current date/time.
Activation Request Time Stamp — Value set to current date/time.
Activation Broadcast Date — Value set to current date.
Activation Broadcast Complete Time Stamp — Value set to current date/time, once the broadcast is complete (Local SMS has responded).
Disconnect Request Time Stamp — Value set to all zeros.
Disconnect Broadcast Time Stamp — Value set to all zeros.
Disconnect Broadcast Time Stamp — Value set to all zeros.
Disconnect Complete Time Stamp — Value set to all zeros.
Effective Release Date — Value set to all zeros.
Customer Disconnect Date — Value set to all zeros.
Pre-Cancellation Status — Value set to NULL.
Old Service Provider Cancellation Time Stamp — Value set to all zeros.
New Service Provider Cancellation Time Stamp — Value set to all zeros.
Cancellation Time Stamp — Value set to all zeros.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	5-65	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

Old Time Stamp — Value set to all zeros.
Conflict Time Stamp — Value set to all zeros.
Conflict Resolution Time Stamp — Value set to all zeros.
Create Time Stamp — Value set to current date/time.
Modified Time Stamp — Value set to current date/time.
Porting to Original — Value set to “FALSE”.
End User Location Value — Value set to “no value”.
End User Location Value Type — Value set to “no value”.
Modify Request Time Stamp — Value set to all zeros.
Modify Broadcast Time Stamp — Value set to all zeros.
Modify Broadcast Complete Time Stamp — Value set to all zeros.
Billing ID — Value set to “no value”.
Status Change Cause Code — Value set to “no value”.
SV Type (Value set to same field as Block)
Alternative SPID (Value set to same field as Block)

RR5-92 Addition of Number Pooling Subscription Version Information Create “Pooled Number” Subscription Version – Bypass of Existing Subscription Versions

NPAC SMS shall upon finding an existing subscription version with an active, partial failure, disconnect pending, old with a failed SP list, or sending status for any TNs within the 1K Block, will bypass and not alter that TN/subscription version, log an information message, and continue processing. (Previously SV-30)

RR5-93 Addition of Number Pooling Subscription Version Information Create “Pooled Number” Subscription Version — Set to Sending

NPAC SMS shall set a Subscription Version of LNP Type POOL in the 1K Block, to sending upon successful subscription creation. (Previously SV-70)

RR5-94 Addition of Number Pooling Subscription Version Information – Status Update

NPAC SMS shall update the status of each Subscription Version with LNP Type of POOL for each TN in the 1K Block, upon completion of the broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted/timers have expired, as defined in RR3-137.1 and RR3-137.2. (Previously SV-90)

RR5-95 Addition of Number Pooling Subscription Version Information – Failed SP List

NPAC SMS shall update the Subscription Version Failed SP List with the discrepant Local SMS of the individual subscription version(s) with LNP Type of POOL, upon completion of the activation broadcast to All EDR and non-EDR Local SMSs, an unsuccessful response from at least one Local SMS, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted/timers have expired, as defined in RR3-138.1 and RR3-138.2. (Previously SV-121)

5.1.4.3 Subscription Version, Block Create Validation of Subscription Versions

The following requirements define validation processing on behalf of the NPAC SMS once a Number Pool Block has been activated.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-66	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-96 Block Create Validation of Subscription Versions – Subscription Version Completion Check

NPAC SMS shall, upon successful completion of a Block Create request, where the Block status is active, verify that 1000 individual TNs exist for the Block, with an LNP Type of either: (Previously SV-131)

• POOL, where the status is active, or

• LSPP/LISP, where the status is active/partial failure/disconnect pending.

Note: NPAC shall perform this Block Create Validation Process until all 1000 TNs have been accounted for in the 1K Block.

Note: NPAC shall NOT perform this Block Create Validation Process once all 1000 TNs have been accounted for in the 1K Block.

RR5-97 Block Create Validation of Subscription Versions – First Time Execution of Subscription Version Completion Check

NPAC SMS shall run the Block Create Validation Process within 24 hours of Block Creation where the Block status is active. (Previously SV-132)

RR5-98 Block Create Validation of Subscription Versions – Subscription Version Create for Missing TNs

NPAC SMS shall, upon finding any missing TNs with a status of Old without a Failed SP List, in the 1K Block, upon performing the Subscription Version Completion Check defined in RR5-96, log an information message, create a Subscription Version with LNP Type of POOL in the NPAC SMS using the routing data in the Block, and set the status to sending for the Subscription Version. (Previously SV-133)

RR5-99 Block Create Validation of Subscription Versions – Subscription Version Broadcast to non-EDR Local SMS

NPAC SMS shall, for any missing TNs in the 1K Block defined in RR5-98, broadcast the Subscription Version(s) with LNP Type of POOL, to all non-EDR Local SMSs, via the NPAC SMS to Local SMS Interface. (Previously SV-135)

RR5-100 Block Create Validation of Subscription Versions – Block Status Update

NPAC SMS shall update the status of the Block based on the results of the broadcast of the Subscription Versions to all non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1, RR3-137.2, RR3-137.3, and RR3-137.4. (Previously SV-137)

RR5-101 Block Create Validation of Subscription Versions – Block Failed SP List Update

NPAC SMS shall update the Block Failed SP List of the Block based on the results of the broadcast of the Subscription Versions to all non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-139)

RR5-102 Block Create Validation of Subscription Versions – Subscription Version Logging

NPAC SMS shall upon finding any missing TNs within the 1K Block during the Block Create Validation Process, log an information message, and continue processing. (Previously SV-140)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-67	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

5.1.4.4 Subscription Version, Modification for Number Pooling

RR5-103 Modification of Number Pooling Subscription Version Information – Subscription Data

NPAC SMS shall automatically apply the updates to the attributes of the individual subscription versions with LNP Type of POOL, with a status of active, for each TN within the 1K Block after successfully modifying a Number Pooling Block in the NPAC SMS. (Previously SV-230)

RR5-104 Modification of Number Pooling Subscription Version Information – Status Update to Sending

NPAC SMS shall update the status of the individual subscription versions with LNP Type of POOL, with a status of active, for each TN within the 1K Block, upon the start of the broadcast of a Block Modification to the Local SMSs, from an active status to a sending status, after successfully modifying a Number Pooling Block in the NPAC SMS. (Previously SV-240)

RR5-105 Modification of Number Pooling Subscription Version Information – Status Update

NPAC SMS shall update the status of each Subscription Version with LNP Type of POOL, with a status of active, for each TN in the 1K Block, upon completion of the broadcast, and a response from All EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.3. (Previously SV-270)

RR5-106 Modification of Number Pooling Subscription Version Information – Failed SP List

NPAC SMS shall update the Subscription Version Failed SP List with the discrepant Local SMS of the individual subscription version(s) with LNP Type of POOL, with a status of active, upon completion of the modification broadcast to All EDR and non-EDR Local SMSs, an unsuccessful response from at least one Local SMS, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-280)

5.1.4.5 Subscription Version, Deletion for Number Pooling

RR5-107 Deletion of Number Pooling Subscription Version Information – Sending Status Update to Subscription Versions

NPAC SMS shall, upon processing a valid request to delete an NPA-NXX-X, update the status of the Subscription Versions with LNP Type of POOL in the 1K Block, at the start of the broadcast to all EDR and non-EDR Local SMSs, from an active status to a sending status. (Previously SV-330)

RR5-108 Deletion of Number Pooling Subscription Version Information – Broadcast of Subscription Version Data

NPAC SMS shall, upon setting the Subscription Versions with LNP Type of POOL in the 1K Block status to sending, broadcast a delete of Subscription Versions with LNP Type of POOL in the 1K Block, to non-EDR LSMSs, via the NPAC SMS to Local SMS Interface. (Previously SV-335)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-68	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Subscription Management

RR5-109 Deletion of Number Pooling Subscription Version Information – Status Update to Subscription Versions

NPAC SMS shall update the status of a particular Subscription Version with LNP Type of POOL for each TN in the 1K Block, upon completion of the broadcast, a response for the Block to all EDR Local SMSs and that particular Subscription Version to non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.4. (Previously SV-350)

RR5-110 Deletion of Number Pooling Subscription Version Information – Failed SP List

NPAC SMS shall update the Subscription Version Failed SP List with the discrepant Local SMS of the individual subscription version(s) with LNP Type of POOL, upon completion of the deletion broadcast to All EDR and non-EDR Local SMSs, an unsuccessful response from at least one Local SMS, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-365)

5.1.4.6 Subscription Version, Block Delete Validation of Subscription Versions

RR5-111 Block Delete Validation of Subscription Versions – Ensure no Subscription Versions with LNP Type POOL

NPAC SMS shall ensure that upon completion of an NPA-NXX-X delete (de-pool), there are no Subscription Versions of LNP Type POOL, remaining in the 1K Block. (Previously SV-429)

This section MOVED to section 3.12.4 Subscription Version, Bulk Data Downloads. The requirement number changed to reflect the new chapter.

RR5-112 Moved to section 3.12.4 Subscription Version, Bulk Data Downloads. This requirement number changed to RR3-324

Release 3.3: © 1997 — 2006 NeuStar, Inc.	5-69	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

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 Provider’s 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.

6.1 SOA to NPAC SMS Interface

6.2 NPAC SMS to Local SMS Interface

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

• Event Report

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

R6-23 Open interfaces

The SOA to NPAC SMS Interface and the NPAC SMS to Local SMS Interface shall be open, non-proprietary interfaces and will not become the property of any entity.

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:

INTERFACE 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 Interface Protocol Stack

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

AR6-1 Range Activations

DELETED

AR6-2 Percent of Range Activations

DELETED

R6-28.1 SOA to NPAC SMS interface transaction rates — sustained

A transaction rate of 4.0 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 10.0 CMIP operations per second (peak for a five minute period, within any 60 minute window) over a single SOA to NPAC SMS interface association.

R6-29.1 NPAC SMS to Local SMS interface transaction rates

DELETED

R6-29.2 NPAC SMS to Local SMS interface transaction rates — peak

NPAC SMS shall, support a rate of 5.2 CMIP operations per second (peak for a five minute period, within any 60 minute window) over each NPAC SMS to Local SMS interface association.

RR6-107 SOA to NPAC SMS interface transaction rates – total bandwidth

NPAC SMS shall support a total bandwidth of 40.0 SOA CMIP transactions per second (sustained) for a single NPAC SMS region. (previously NANC 393, NewReq 1)

RR6-108 NPAC SMS to Local SMS interface transaction rates – sustained

NPAC SMS shall support a rate of 4.0 CMIP transactions per second (sustained) over each NPAC SMS to Local SMS interface association. (previously NANC 393, NewReq 2)

RR6-109 NPAC SMS to Local SMS interface transaction rates – total bandwidth

NPAC SMS shall support a total bandwidth of 156 Local SMS CMIP transactions per second (sustained) for a single NPAC SMS region. (previously NANC 393, NewReq 3)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

6.4.3 Interface Specification Requirements

R6-30.1 Interface specification

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, “Guideline for the Definition of Managed Objects (GDMO)”.

R6-30.2 Interface specification identification

The interface specification shall be referred to as the “NPAC SMS Interoperable Interface Specification” (NPAC SMS IIS).

R6-35 NPAC SMS Interoperable Interface Specification extensibility

The interface specified shall be capable of extension to account for evolution of the interface requirements.

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.

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.

6.4.4 Request Restraints

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

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

RR6-14 Subscription Version Resynchronization Filter Usage

NPAC SMS shall, for a Subscription Version Resynchronization request, over the NPAC SMS to Local SMS Interface, only send subscription version that are not filtered on the Local SMS.

6.4.5 Application Level Errors

RR6-110 NPAC SMS Application Level Errors

NPAC SMS shall provide application level errors in the CMIP messaging in the SOA to NPAC SMS Interface and NPAC SMS to Local SMS Interface for those Service Providers that support this functionality. (previously ILL 130, Req 1)

RR6-111 NPAC SMS Application Level Error Details

NPAC SMS shall use the application level errors defined in the IIS, PartII, Appendix A. (previously ILL 130, Req 2)

RR6-112 NPAC SMS Application Level Error Details in soft format

NPAC SMS shall provide application level error code-to-text details in a pipe-delimited, soft format, at the FTP sub-directory for each Service Provider. (previously ILL 130, Req 3)

Note: This code-to-text mapping is designed to allow a SOA/LSMS to decode an error code received from the NPAC, into its corresponding text description.

RR6-113 SOA Action Application Level Errors Indicator

NPAC SMS shall provide SOA Action Application Level Errors Indicator tunable parameter, which defines whether a Service Provider supports Application Level Errors across the SOA Interface for M-ACTIONs. (previously ILL 130, Req 4)

Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-114 SOA Action Application Level Error Indicator Default

NPAC SMS shall default the Service Provider SOA Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130, Req 5)

RR6-115 SOA Action Application Level Errors Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 6)

RR6-116 LSMS Action Application Level Errors Indicator

NPAC SMS shall provide an LSMS Action Application Level Errors Indicator tunable parameter which defines whether a Service Provider LSMS supports Application Level Errors across the LSMS Interface for M-ACTIONs. (previously ILL 130, Req 7)

Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.

RR6-117 LSMS Action Application Level Errors Indicator Default

NPAC SMS shall default the Service Provider LSMS Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130, Req 8)

RR6-118 LSMS Action Application Level Errors Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 9)

RR6-119 LSMS Application Level Errors Indicator

DELETED

RR6-120 LSMS Application Level Error Indicator Default

DELETED

RR6-121 LSMS Application Level Errors Indicator Modification

DELETED

RR6-193 SOA Non-Action Application Level Errors Indicator

NPAC SMS shall provide a SOA Non-Action Application Level Errors Indicator tunable parameter, which defines whether a Service Provider supports Application Level Errors across the SOA Interface for all non-M-ACTIONs. (previously ILL 130, Req 10)

Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-194 SOA Non-Action Application Level Errors Indicator Default

NPAC SMS shall default the Service Provider SOA Non-Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130, Req 11)

RR6-195 SOA Non-Action Application Level Errors Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Non-Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 12)

RR6-196 LSMS Non-Action Application Level Errors Indicator

NPAC SMS shall provide an LSMS Non-Action Application Level Errors Indicator tunable parameter, which defines whether a Service Provider supports Application Level Errors across the LSMS Interface for all non-M-ACTIONs. (previously ILL 130, Req 13)

Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.

RR6-197 LSMS Non-Action Application Level Errors Indicator Default

NPAC SMS shall default the Service Provider LSMS Non-Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130 , Req 14)

RR6-198 LSMS Non-Action Application Level Errors Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Non-Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 15)

6.5 NPAC SOA Low-tech Interface

The NPAC SOA Low-tech Interface supports the request functionality of the SOA to NPAC SMS interface.

RX6-2.1 NPAC SOA Low-tech Interface

NPAC SMS shall provide an NPAC SOA Low-tech Interface.

RX6-2.2 SOA to NPAC SMS Create Subscription Versions administration requests via an NPAC SOA Low-tech Interface

NPAC SMS shall support Create Subscription Version requests via a secure, NPAC SOA Low-tech Interface.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RX6-2.3 SOA to NPAC SMS Cancel Subscription Versions administration requests via an NPAC SOA Low-tech Interface

NPAC SMS shall support Cancel Subscription Version requests via a secure, NPAC SOA Low-tech Interface.

RX6-2.4 SOA to NPAC SMS Modify Subscription Versions administration requests via an NPAC SOA Low-tech Interface

NPAC SMS shall support Modify Subscription Version requests via a secure, NPAC SOA Low-tech Interface.

RX6-2.5 SOA to NPAC SMS Query Subscription Versions administration requests via an NPAC SOA Low-tech Interface

NPAC SMS shall support query of Subscription Versions via a secure, NPAC SOA Low-tech Interface.

RX6-2.6 SOA to NPAC SMS Activate Subscription Versions administration requests via an NPAC SOA Low-tech Interface

NPAC SMS shall support Activation of Subscription Versions via a secure, NPAC SOA Low-tech Interface.

RX6-2.7 SOA to NPAC SMS Disconnect Subscription Versions administration requests via an NPAC SOA Low-tech 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 SOA Low-tech Interface.

RR6-189 SOA to NPAC SMS Un-Do Cancel-Pending Subscription Version administration requests via an NPAC SOA Low-tech Interface

NPAC SMS shall support the ability to submit an un-do Cancel-Pending Subscription Version request via a secure, NPAC SOA Low-tech Interface. (previously NANC 388)

RX6-3 SOA to NPAC SMS audit requests

NPAC SMS shall support SOA to NPAC SMS audit requests for all, part or one Service Provider via the NPAC SOA Low-tech Interface.

RR6-35 SOA to NPAC SMS Number Pool Block Create Request via the SOA Low-tech Interface

NPAC SMS shall allow NPAC Personnel and users of the SOA to NPAC SMS interface to request creation of a Number Pool Block via a secure, NPAC SOA Low-tech Interface.

RR6-36 SOA to NPAC SMS Number Pool Block Modify Request via the SOA Low-tech Interface

NPAC SMS shall allow NPAC Personnel and users of the SOA to NPAC SMS interface to request modification of a Number Pool Block via a secure, NPAC SOA Low-tech Interface.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RX6- 4 NPAC SMS Notification Handling

NPAC SMS shall support, via a secure NPAC SOA Low-tech Interface, a method to view and locally capture notifications that have occurred for the service provider upon request.

6.6 CMIP Request Retry Requirements

RR6-15 SOA Retry Attempts — Tunable Parameter

NPAC SMS shall provide a SOA Retry Attempts tunable parameter which defines the number of times a message will be sent to a SOA which has not acknowledged receipt of the message.

RR6-16 SOA Retry Interval — Tunable Parameter

NPAC SMS shall provide a SOA Retry Interval tunable parameter, which defines the delay between sending a message to a SOA that has not acknowledged receipt of the message.

RR6-17 SOA Retry Attempts — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the SOA Retry Attempts tunable parameter.

RR6-18 SOA Retry Interval — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the SOA Retry Interval tunable parameter.

RR6-19 SOA Retry Attempts — Tunable Parameter Default

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

RR6-20 SOA Retry Interval — Tunable Parameter Default

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

RR6-21 SOA Activation Failure Retry

NPAC SMS shall resend the message a SOA Retry Attempts tunable parameter number of times to a SOA that has not acknowledged the receipt of the message once the SOA Retry Interval tunable parameter expires.

RR6-22 LSMS Retry Attempts — Tunable Parameter

NPAC SMS shall provide an LSMS Retry Attempts tunable parameter which defines the number of times a message will be sent to a Local SMS which has not acknowledged receipt of the message.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-23 LSMS Retry Interval — Tunable Parameter

NPAC SMS shall provide an LSMS Retry Interval tunable parameter, which defines the delay between sending a message to a Local SMS that has not acknowledged receipt of the message.

RR6-24 LSMS Retry Attempts — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the LSMS Retry Attempts tunable parameter.

RR6-25 LSMS Retry Interval — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the LSMS Retry Interval tunable parameter.

RR6-26 LSMS Retry Attempts — Tunable Parameter Default

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

RR6-27 LSMS Retry Interval — Tunable Parameter Default

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

RR6-28 LSMS Activation Failure Retry

NPAC SMS shall resend the message an LSMS Retry Attempts tunable parameter number of times to a Local SMS that has not acknowledged the receipt of the message once the LSMS Retry Interval tunable parameter expires.

6.7 Recovery –

The following section defines Recovery functionality supported by the NPAC SMS to SOA interface and NPAC SMS to LSMS interface.

RR6-84 Linked Replies Information – Sending Linked Replies During Recovery

NPAC SMS shall be capable of sending linked action replies, via the SOA to NPAC SMS Interface, and NPAC SMS to Local SMS Interface in response to a recovery request. (Previously NANC 187 Req 11)

RR6-85 Linked Replies Information – Service Provider SOA Linked Replies Indicator Sending of Linked Replies

NPAC SMS shall send Network and Notification Recovery Responses as Linked Replies, via the SOA to NPAC SMS Interface, if the Service Provider’s SOA Linked Replies indicator is TRUE, and the amount of data is greater than the associated Blocking Factor tunable parameter. (Previously NANC 187 Req 4)

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-86 Linked Replies Information – Service Provider SOA Linked Replies Indicator Sending of Non-Linked Replies

NPAC SMS shall send Network and Notification Recovery Responses as Non-Linked Replies, via the SOA to NPAC SMS Interface, if the Service Provider’s SOA Linked Replies indicator is FALSE. (Previously NANC 187 Req 5)

RR6-87 Linked Replies Information – Service Provider Local SMS Linked Replies Indicator Sending of Linked Replies

NPAC SMS shall send Network, Subscription, Number Pool Block and Notification Recovery Responses as Linked Replies, via the NPAC SMS to Local SMS Interface, if the Service Provider’s Local SMS Linked Replies indicator is TRUE, and the amount of data is greater than the associated Blocking Factor tunable parameter. (Previously NANC 187 Req 9)

RR6-88 Linked Replies Information – Service Provider Local SMS Linked Replies Indicator Sending of Non-Linked Replies

NPAC SMS shall send Network, Subscription, Number Pool Block and Notification Recovery Responses as Non-Linked Replies, via the NPAC SMS to Local SMS Interface, if the Service Provider’s Local SMS Linked Replies indicator is FALSE. (Previously NANC 187 Req 10)

RR6-122 SWIM Recovery Tracking

NPAC SMS shall provide functionality that tracks messages not sent to, and acknowledged by, a Service Provider SOA/LSMS for SWIM Recovery purposes. (previously NANC 351, Req 1)

RR6-123 Service Provider SOA SWIM Recovery Indicator

NPAC SMS shall provide a Service Provider SOA SWIM Recovery Indicator tunable parameter which defines whether a SOA supports SWIM recovery. (previously NANC 351, Req 2)

RR6-124 Service Provider SOA SWIM Recovery Indicator Default

NPAC SMS shall default the Service Provider SOA SWIM Recovery Indicator tunable parameter to FALSE. (previously NANC 351, Req 3)

RR6-125 Service Provider SOA SWIM Recovery Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SWIM Recovery Indicator tunable parameter. (previously NANC 351, Req 4)

RR6-126 SOA SWIM Maximum Tunable

NPAC SMS shall provide a SOA SWIM Maximum tunable parameter, which is defined as the maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery. (previously NANC 351, Req 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-127 SOA SWIM Maximum Tunable Default

NPAC SMS shall default the SOA SWIM Maximum tunable parameter to 50,000. (previously NANC 351, Req 6)

RR6-128 SOA SWIM Maximum Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the SOA SWIM Maximum tunable parameter. (previously NANC 351, Req 7)

RR6-129 Service Provider LSMS SWIM Recovery Indicator

NPAC SMS shall provide a Service Provider LSMS SWIM Recovery Indicator tunable parameter, which defines whether a LSMS supports SWIM recovery. (previously NANC 351, Req 8)

RR6-130 Service Provider LSMS SWIM Recovery Indicator Default

NPAC SMS shall default the Service Provider LSMS SWIM Recovery Indicator tunable parameter to FALSE. (previously NANC 351, Req 9)

RR6-131 Service Provider LSMS SWIM Recovery Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SWIM Recovery Indicator tunable parameter. (previously NANC 351, Req 10)

RR6-190 LSMS SWIM Maximum Tunable

NPAC SMS shall provide a LSMS SWIM Maximum tunable parameter, which is defined as the maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery. (previously, NANC 351, Req 11)

RR6-191 LSMS SWIM Maximum Tunable Default

NPAC SMS shall default the LSMS SWIM Maximum tunable parameter to 50,000. (previously NANC 351, Req 12)

RR6-192 LSMS SWIM Maximum Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the LSMS SWIM Maximum tunable parameter. (previously NANC 351, Req 13)

6.7.1 Notification Recovery

The following section defines specific requirements of the Notification Recovery functionality supported by the NPAC SMS.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-29 Notification Recovery

NPAC SMS shall support recovery of all CMIP notifications defined in the IIS that are emitted over the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces. Examples of notifications to be recovered include:

•	subscriptionVersionNewNPA-NXX
•	subscriptionVersionDonorSP-CustomerDisconnectDate
•	subscriptionAudit-DiscrepancyRpt
•	subscriptionAuditResults
•	lnpNPAC-SMS-Operational-Information
•	subscriptionVersionNewSP-CreateRequest (time sensitive T1 New SP)
•	subscriptionVersionOld-SP-ConcurrenceRequest (time sensitive T1 Old SP)
•	subscriptionVersionOldSPFinalWindowExpiration (time sensitive T2 Old SP)
•	subscriptionVersionStatusAttributeValueChange
•	numberPoolBlockStatusAttributeValueChange
•	attributeValueChange
•	objectCreation
•	objectDeletion
•	subscriptionVersionNewSP-FinalCreateWindowExpiration (if supported by the recovering SOA)
•	subscriptionVersionRangeStatusAttributeValueChange
•	subscriptionVersionRangeAttributeValueChange
•	subscriptionVersionRangeObjectCreation
•	subscriptionVersionRangeDonorSP-CustomerDisconnectDate
•	subscriptionVersionRangeNewSP-CancellationAcknowledge
•	subscriptionVersionRangeNewSP-CreateRequest
•	subscriptionVersionRangeOldSP-ConcurrenceRequest
•	subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration
•	subscriptionVersionRangeNewSPFinalCreateWindowExpiration
	For a complete list of notifications reference the IIS.

RR6-79 TN Range Notification Information – Recovery of TN Range Notifications

NPAC SMS shall send TN Range Notifications during recovery that mimic the same TN Range Notifications that would have been received by the Service Provider had they been associated during the original broadcast of the TN Range Notifications. (Formerly NANC 179 Req 8)

RR6-80 TN Range Notification Information – Single NPA-NXX

NPAC SMS shall only allow a TN Range Notification to be inclusive within a single NPA-NXX. (Formerly NANC 179 Req 9)

RR6-81 TN Range Notifications – When They Will be Sent

NPAC SMS shall send, to Service Providers that have their TN Range Notification Indicator set to TRUE, the corresponding range notifications in place of the following notifications and their recovery counterpart:

• subscriptionVersionStatusAttributeValueChange

• subscriptionVersionAttributeValueChange

• subscriptionVersionObjectCreation

• subscriptionVersionDonorSP-CustomerDisconnectDate

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

• subscriptionVersionNewSP-CancellationAcknowledge

• subscriptionVersionNewSP-CreateRequest

• subscriptionVersionOldSP-ConcurrenceRequest

• subscriptionVersionOldSPFinalConcurrenceWindowExpiration

• subscriptionVersionNewSPFinalCreateWindowExpiration

(Formerly NANC 179 Req 10)

RR6-82 Range Sizes and Format of Notifications Sent in Recovery

NPAC SMS shall, during recovery, send a service provider’s notifications in the original range sizes and in the format that corresponds to their TN Range Notification Indicator value at the time of recovery. (Formerly NANC 179 Req 11)

RR6-30 Notification Recovery – Order of Recovery

NPAC SMS shall recover all notifications, failed or successful, in the order the NPAC SMS attempts to send them when notification recovery is requested by the SOA or LSMS.

RR6-31 Notification Recovery – Time Range Limit

NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a notification recovery request.

RR6-32 Notification Recovery – SOA and LSMS Independence

NPAC SMS shall support the recovery of notifications for the SOA and LSMS as independent requests.

RR6-33 Notification Recovery – SOA Notifications

NPAC SMS shall allow the SOA to only recover SOA notifications.

RR6-83 Maintaining Priority of SOA Notifications During Recovery

NPAC SMS shall, during recovery, maintain the priority of the SOA Notifications that reflect the values of the SOA Notification Priority Tunable Parameter at the time the notification was created. (Formerly NANC 329 Req 5.5)

RR6-34 Notification Recovery – LSMS Notifications

NPAC SMS shall allow the LSMS to only recover LSMS notifications.

RR6-89 Linked Replies Information – Sending Linked Replies During Notification Data Recovery to SOA

NPAC SMS shall send notification data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, in groups of notifications based on the Notification Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 24)

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-90 Linked Replies Information – Sending Linked Replies During Notification Data Recovery to Local SMS

NPAC SMS shall send notification data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of notifications based on the Notification Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 25)

RR6-91 Linked Replies Information – Notification Data Recovery Maximum Size to SOA

NPAC SMS shall allow notification data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, to be as large as the Notification Data Maximum Linked Recovered Notifications tunable parameter value. (Previously NANC 187 Req 38)

RR6-96 Linked Replies Information – Notification Data Recovery Maximum Size to Local SMS

NPAC SMS shall allow notification data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Notification Data Maximum Linked Recovered Notifications tunable parameter value. (Previously NANC 187 Req 39)

RR6-132 Notification Recovery – Notification Data Criteria

NPAC SMS shall require a SOA/LSMS to specify one of the following choices for notification data recovery criteria:

• Time-range

• SWIM (Send What I Missed)

(previously NANC 351, Req 0.5)

6.7.2 Network Data Recovery

The following section defines specific requirements of the Network Data Recovery functionality supported by the NPAC SMS.

RR6-37 Network Data Recovery

NPAC SMS shall provide a mechanism that allows a SOA or LSMS to recover network data downloads that were missed during a broadcast to the SOA or LSMS.

RR6-38 Network Data Recovery – Order of Recovery

NPAC SMS shall recover all network data download broadcasts in time sequence order when network data recovery is requested by the SOA or LSMS.

RR6-39 Network Data Recovery – Time Range Limit

NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a network data recovery request.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-40 Network Data Recovery – SOA and LSMS Independence

NPAC SMS shall support the recovery of network data for the SOA and LSMS as independent requests.

RR6-41 Network Data Recovery – SOA Network Data

NPAC SMS shall allow the SOA to only recover network data downloads intended for the SOA.

RR6-42 Network Data Recovery – LSMS Network Data

NPAC SMS shall allow the LSMS to only recover network data downloads intended for the LSMS.

RR6-43 Network Data Recovery – Network Data Criteria

NPAC SMS shall support the following network data download criteria:

• Single Service Provider or all Service Providers with optional time range

• SWIM Send What I Missed

RR6-44 Network Data Recovery – Network Data Choices

NPAC SMS shall require one of the following network data download choices:

•	npa-nxx-data (with one of the two selections below)
	- npa-nxx-range
	- all

•	lrn data (with one of the two selections below)
	- lrn-range
	- all

• all network data

•	npa-nxx-x-data (with one of the two selections below)
	- npa-nxx-x-range
	- all

RR6-45 Resynchronization of Number Pool NPA-NXX-X Holder Information – Local SMS NPA-NXX-X Indicator set to TRUE

NPAC SMS shall process a Service Provider request to download Network data over the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall send the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer LSMS NPA-NXX-X Indicator is set to TRUE. (Previously N-380)

RR6-46 Resynchronization of Number Pool NPA-NXX-X Holder Information – Local SMS NPA-NXX-X Indicator set to FALSE

NPAC SMS shall process a Service Provider request to download Network data over the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall suppress the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer LSMS NPA-NXX-X Indicator is set to FALSE. (Previously N-390)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-47 Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and queuing of messages to Local SMS

NPAC SMS shall queue up a single instance of all messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the NPAC SMS and where the resynchronization flag is set to TRUE. (Previously N-392)

RR6-48 Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and sending of queued messages to Local SMS

NPAC SMS shall send queued up messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider has sent a message to the NPAC SMS that resynchronization has been completed. (Previously N-394)

RR6-49 Resynchronization of Number Pool NPA-NXX-X Holder Information – Filters on NPA-NXX-X resync to Local SMS

NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X resynchronization to the Local SMS(s) via the NPAC SMS to Local SMS Interface. (Previously N-400)

RR6-50 Resynchronization of Number Pool NPA-NXX-X Holder Information – SOA NPA-NXX-X Indicator set to TRUE

NPAC SMS shall process a Service Provider request to download Network data over the SOA to NPAC SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall send the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer SOA NPA-NXX-X Indicator is set to TRUE. (Previously N-410)

RR6-51 Resynchronization of Number Pool NPA-NXX-X Holder Information – SOA NPA-NXX-X Indicator set to FALSE

NPAC SMS shall process a Service Provider request to download Network data over the SOA to NPAC SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall suppress the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer SOA NPA-NXX-X Indicator is set to FALSE. (Previously N-420)

RR6-52 Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and queuing of messages to SOA

NPAC SMS shall queue up a single instance of all messages to the SOA, via the SOA to NPAC SMS Interface, when a Service Provider establishes an association with the NPAC SMS and where the resynchronization flag is set to TRUE. (Previously N-430)

RR6-53 Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and sending of queued messages to SOA

NPAC SMS shall send queued up messages to the SOA, via the SOA to NPAC SMS Interface, when a Service Provider has sent a message to the NPAC SMS that resynchronization has been completed. (Previously N-440)

Release4 3.3:© 1997 — 2006 NeuStar, Inc.	6-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-54 Resynchronization of Number Pool NPA-NXX-X Holder Information – Filters on NPA-NXX-X resync to SOA

NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X resynchronization to the SOA(s) via the SOA to NPAC SMS Interface. (Previously N-450)

RR6-92 Linked Replies Information – Sending Linked Replies During Network Data Recovery to SOA

NPAC SMS shall send network data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 15)

RR6-93 Linked Replies Information – Sending Linked Replies During Network Data Recovery to Local SMS

NPAC SMS shall send network data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 16)

RR6-94 Linked Replies Information – Network Data Recovery Maximum Size to SOA

NPAC SMS shall allow network data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (Previously NANC 187 Req 29)

RR6-95 Linked Replies Information – Network Data Recovery Maximum Size to Local SMS

NPAC SMS shall allow network data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (Previously NANC 187 Req 30)

6.7.3 Subscription Data Recovery

The following section defines specific requirements of the Subscription Data Recovery functionality supported by the NPAC SMS.

RR6-55 Subscription Data Recovery

NPAC SMS shall provide a mechanism that allows an LSMS to recover subscription data downloads that were missed during a broadcast to the LSMS.

RR6-56 Subscription Data Recovery – Order of Recovery

NPAC SMS shall recover subscription data download broadcasts in time sequence order when subscription data recovery is requested by the LSMS.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-57 Subscription Data Recovery – Time Range Limit

NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a subscription data recovery request.

RR6-58 Subscription Data Recovery – Subscription Data Choices

NPAC SMS shall require an LSMS to specify one of the following choices in a subscription data recovery request:

• time-range

• TN

• TN-range (NPA-NXX-XXXX) – (YYYY)

• SWIM (Send What I Missed)

RR6-59 Subscription Data Recovery – Full Failure SV

NPAC SMS shall exclude Subscription Versions with a status of failed, when subscription data recovery is requested by the LSMS.

RR6-60 Subscription Data Recovery – SV Timestamp for Requested Time Range

NPAC SMS shall use the Subscription Version’s Broadcast Timestamp value to determine if an SV falls within the requested time range for a subscription data recovery request.

RR6-97 Subscription Data Recovery – Statuses of Subscription Versions Recovered

NPAC SMS shall include Subscription Versions with a status of active, partial failure, disconnect-pending, old with a failed list, and sending, at the time subscription data recovery is requested by the Local SMS and processed by the NPAC SMS, for all Subscription Versions with broadcast activity during the requested recovery timeframe. (Previously NANC 297 Req 1)

RR6-61 Subscription Data Recovery – Removal of Service Provider from Failed List

NPAC SMS shall remove a Service Provider from the Failed SP List of an SV, upon successful recovery of the subscription data.

RR6-98 Subscription Data Recovery – Removal of Service Provider from Failed SP List of Subscription Versions Recovered

NPAC SMS shall remove a Service Provider from the Failed SP List of a Subscription Version with a status of sending, even if there are additional retry attempts, after the subscription data recovery response has been sent to the Local SMS of that Service Provider. (Previously NANC 297 Req 2)

RR6-99 Subscription Data Recovery – Suppression of Broadcast of Subscription Versions Recovered

NPAC SMS shall ensure that the download of subscription data that was in a sending status at the start of the Subscription Data recovery process, even if there are additional retry attempts, is not sent to the Service Provider at the completion of recovery that included subscription data to the Local SMS. (Previously NANC 297 Req 3)

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-62 Subscription Data Recovery – Successful Recovery of SV Data and Removal of Service Provider from Failed List – Both Service Providers

NPAC SMS shall send, to the Old and New Service Providers, the status and a list of all Local SMSs that currently exist on the Failed SP List of an SV, upon successful recovery of the subscription data, with the exception of modify active or disconnect requests.

RR6-63 Subscription Data Recovery – Successful Recovery of SV Data and Removal of Service Provider from Failed List – New Service Provider Only

NPAC SMS shall send, to the New Service Provider only, the status and a list of all Local SMSs that currently exist on the Failed SP List of an SV, upon successful recovery of the subscription data, specific to modify active or disconnect requests.

RR6-133 Subscription Version Failed SP List – Recovery of Excluded Service Provider Subscription Versions

NPAC SMS shall, for a recovery of subscription data, in instances where the NPAC SMS excluded the Service Provider from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface, allow the Local SMS to recover a Subscription Version with all current attributes, even though the Service Provider is no longer on the Failed SP List. (previously NANC 227/254, Req 3)

RR6-64 Number Pool Block Holder Information Resynchronization – Block

NPAC SMS shall process a Service Provider request to download Block data over the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and requests Block data based on criteria sent to the NPAC SMS upon association. (Previously B-690)

RR6-65 Number Pool Block Holder Information Resynchronization – Block Criteria

NPAC SMS shall accept criteria for Block data, of either Time Range in GMT or Block Range entry fields or SWIM, where the Time Range in GMT includes the starting time in GMT and ending time in GMT based on the Activation Start Timestamp/Disconnect Broadcast Timestamp/Modify Broadcast Timestamp, and the Block Range includes the starting Block and ending Block. (Previously B-691)

Note: If the Block Range was 303-242-2 through 303-355-6, the range would contain all Blocks within the TN Range of 303-242-2000 through 303-355-6999.

RR6-66 Number Pool Block Holder Information Resynchronization – Block Range Tunable Parameters

NPAC SMS shall use the existing Subscription Version tunables for Maximum Download Duration and Maximum Number of Download Records, as defined in the Functional Requirements Specification’ s Appendix C, for Blocks that can be resynchronized by a Local SMS. (Previously B-695)

RR6-67 Number Pool Block Holder Information Resynchronization – Rejection of Block Criteria

NPAC SMS shall reject a resynchronization request, if the criteria of either Time Range or Block Range, exceeds the current values of the Maximum Download Duration or Maximum Number of Download Records tunables. (Previously B-698)

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-68 Number Pool Block Holder Information Resynchronization – Block resync and queuing of messages

NPAC SMS shall queue up a single instance of all messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the NPAC SMS and where the resynchronization flag is set to TRUE. (Previously B-700)

RR6-69 Number Pool Block Holder Information Resynchronization – Block resync and sending of queued messages

NPAC SMS shall send, queued up messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider has sent a message to the NPAC SMS that resynchronization has been completed. (Previously B-710)

RR6-70 Number Pool Block Holder Information Resynchronization – Filters on Block resync

NPAC SMS shall apply NPA-NXX Filters to Block resynchronization to the Local SMS(s), via the NPAC SMS to Local SMS Interface. (Previously B-720)

RR6-71 Number Pool Block Holder Information Resynchronization – Update to Failed SP List

NPAC SMS shall update the Block Failed SP List and Subscription Version Failed SP List, by removing the resyncing Local SMS, upon a successful response to a resynchronization request to a previously failed EDR Local SMS, as defined in RR3-138.1 and RR3-138.2. (Previously B-730)

RR6-100 Number Pool Block Data Recovery – Statuses of Number Pool Blocks Recovered

NPAC SMS shall include Number Pool Blocks with a status of active, partial failure, old with a failed list, and sending, at the time Number Pool Block data recovery is requested by the Local SMS and processed by the NPAC SMS, for all Number Pool Blocks with broadcast activity during the requested recovery timeframe. (Previously NANC 297 Req 4)

RR6-101 Number Pool Block Data Recovery – Removal of Service Provider from Failed SP List of Number Pool Blocks Recovered

NPAC SMS shall remove a Service Provider from the Failed SP List of a Number Pool Block with a status of sending, even if there are additional retry attempts, after the Number Pool Block data recovery response has been sent to the Local SMS of that Service Provider. (Previously NANC 297 Req 5)

RR6-134 Number Pool Block Failed SP List – Recovery of Excluded Service Provider Subscription Versions

NPAC SMS shall, for a recovery of number pool block data, in instances where the NPAC SMS excluded the Service Provider from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface, allow the Local SMS to recover a Number Pool Block or its associated pool-type subscription versions with all current attributes, even though the Service Provider is no longer on the Failed SP List. (previously NANC 300, Req 3)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-102 Number Pool Block Data Recovery – Suppression of Broadcast of Number Pool Blocks Recovered

NPAC SMS shall ensure that the download of Number Pool Block data that was in a sending status at the start of the Number Pool Block Data recovery process, even if there are additional retry attempts, is not sent to the Service Provider at the completion of recovery that included Number Pool Block data to the Local SMS. (Previously NANC 297 Req 6)

RR6-72 Number Pool Block Holder Information Resynchronization – Status Update to Block after Successful Resynchronization

NPAC SMS shall update the status of the Block, specified in the resynchronization request for a Block Creation, Modification, or Deletion, at the completion of the resynchronization to the Local SMS, as defined in RR3-137.1, RR3-137.2, RR3-137.3, and RR3-137.4. (Previously B-740)

RR6-73 Number Pooling Subscription Version Information Resynchronization – Filters on Subscription Versions Resync

NPAC SMS shall filter out Subscription Versions with LNP Type of POOL for Resynchronization of Subscription Version data, when the resyncing Service Provider has an EDR Indicator set to TRUE. (Previously SV-522)

RR6-74 Number Pooling Subscription Version Information Resynchronization – Disconnect or Port-To-Original of a TN within a Pooled 1K Block

NPAC SMS shall examine a Service Provider’s EDR Indicator, at the time of resync, to determine the message to resync, for a disconnect or a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block. (Previously SV-530)

RR6-75 Number Pooling Subscription Version Information Resynchronization – Disconnect TN within a Pooled 1K Block to EDR Local SMS

NPAC SMS shall, for a resync of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the EDR Local SMS to recover the Delete request of the Subscription Version that was active prior to the disconnect broadcast, regardless of it’s status, to an EDR Local SMS. (Previously SV-540)

Note: The NPAC SMS will resync an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the disconnect request (SV2), as defined in the IIS Flows for Disconnect of a Ported Pooled Number, and regardless of the status on SV1.

RR6-76 Number Pooling Subscription Version Information Resynchronization – Disconnect TN within a Pooled 1K Block to non-EDR Local SMS

NPAC SMS shall, for a resync of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the non-EDR Local SMS to recover the Create request of the Subscription Version that was created to restore default routing, regardless of it’s status, and regardless of the status of the Subscription Version that was active prior to the disconnect broadcast, to a non-EDR Local SMS. (Previously SV-550)

Note: The NPAC SMS will resync an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV2) that was created to restore default routing (SV1), even though the Failed SP List resides on SV1, as defined in the IIS Flows for Disconnect of a Ported Pooled Number, and regardless of the status on SV1 and SV2.

Release 3.3:© 1997 — 2006 NeuStar, Inc.	6-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

NPAC SMS Interfaces

RR6-77 Number Pooling Subscription Version Information Resynchronization —Port-To-Original TN within a Pooled 1K Block to EDR Local SMS

NPAC SMS shall, for a resync of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the EDR Local SMS to recover the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast, regardless of it’s status, and regardless of the status of the Subscription Version that is used to generate the Port-To-Original request to the NPAC SMS, to an EDR Local SMS. (Previously SV-560)

Note: The NPAC SMS will resync an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number, and regardless of the status on SV1 and SV2.

RR6-78 Number Pooling Subscription Version Information Resynchronization — Port-To-Original TN within a Pooled 1K Block to non-EDR Local SMS

NPAC SMS shall, for a resync of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the non-EDR Local SMS to recover the Create request of the Subscription Version that was created to restore default routing, and shall NOT allow the non-EDR Local SMS to recover the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast, regardless of it’s status, regardless of the status of the Subscription Version that is used to generate the Port-To-Original request to the NPAC SMS, and regardless of the status of the Subscription Version that was created to restore default routing, to a non-EDR Local SMS. (Previously SV-570)

Note: The NPAC SMS will resync an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV3) that was created to restore default routing, and will NOT resync an M-DELETE of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number, and regardless of the status on SV1, SV2, and SV3.

RR6-103 Linked Replies Information — Sending Linked Replies During Subscription Data Recovery to Local SMS

NPAC SMS shall send subscription data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Subscription Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 20)

RR6-104 Linked Replies Information — Subscription Data Recovery Maximum Size to Local SMS

NPAC SMS shall allow subscription data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Subscription Data Maximum Linked Recovered Objects tunable parameter value. (Previously NANC 187 Req 34)

RR6-105 Linked Replies Information — Sending Linked Replies During Number Pool Block Recovery to Local SMS

NPAC SMS shall send number pool block data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Number Pool Block Data Linked Replies Blocking Factor tunable parameter value. (Previously related to NANC 187)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-23	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

RR6-106 Linked Replies Information — Number Pool Block Recovery Maximum Size to Local SMS

NPAC SMS shall allow number pool block data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Number Pool Block Data Maximum Linked Recovered Objects tunable parameter value. (Previously related to NANC 187)

6.7.4 Service Provider Recovery

RR6-135 Service Provider Data Recovery

NPAC SMS shall provide a mechanism that allows a SOA or LSMS to recover service provider downloads that were missed during a broadcast to the SOA or LSMS. (previously NANC 352, Req 1)

RR6-136 Service Provider Data Recovery Only in Recovery Mode

NPAC SMS shall allow a SOA or LSMS to recover service provider data ONLY in recovery mode. (previously NANC 352, Req 2)

RR6-137 Service Provider Data Recovery — Order of Recovery

NPAC SMS shall recover all service provider data download broadcasts in time sequence order when service provider recovery is requested by the SOA or LSMS. (previously NANC 352, Req 3)

RR6-138 Service Provider Data Recovery — Time Range Limit

NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a service provider data recovery request. (previously NANC 352, Req 4)

RR6-139 Service Provider Data Recovery — SOA and LSMS Independence

NPAC SMS shall support the recovery of service provider data for the SOA and LSMS as independent requests. (previously NANC 352, Req 5)

RR6-140 Service Provider Data Recovery — SOA Network Data

NPAC SMS shall allow the SOA to only recover service provider data downloads intended for the SOA. (previously NANC 352, Req 6)

RR6-141 Service Provider Data Recovery — LSMS Network Data

NPAC SMS shall allow the LSMS to only recover service provider data downloads intended for the LSMS. (previously NANC 352, Req 7)

RR6-142 Service Provider Data Recovery — Service Provider Data Criteria

NPAC SMS shall support the following service provider data download criteria:

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-24	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

• Single Service Provider with optional time range, or all Service Providers with optional time range

• SWIM (Send What I Missed)

(previously NANC 352, Req 8)

RR6-143 Service Provider Data Recovery — Network Data Choices

DELETED

RR6-144 Linked Replies Information — Sending Linked Replies During Service Provider Data Recovery to SOA

NPAC SMS shall send Service Provider data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (previously NANC 352, Req 10)

RR6-145 Linked Replies Information — Sending Linked Replies During Service Provider Data Recovery to Local SMS

NPAC SMS shall send Service Provider data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (previously NANC 352, Req 11)

RR6-146 Linked Replies Information — Service Provider Data Recovery Maximum Size to SOA

NPAC SMS shall allow Service Provider data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (previously NANC 352, Req 12)

RR6-147 Linked Replies Information — Service Provider Data Recovery Maximum Size to Local SMS

NPAC SMS shall allow Service Provider data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (previously NANC 352, Req 13)

6.8 Out-Bound Flow Control

RR6-148 Out-Bound Flow Control Upper Threshold Tunable

NPAC SMS shall provide an Out-Bound Flow Control Upper Threshold tunable parameter which is defined as the number of non-responsive messages sent to a SOA/LSMS before Out-Bound Flow Control is invoked, on a per association basis. (previously NANC 368, Req 1)

RR6-149 Out-Bound Flow Control Upper Threshold Tunable Default

NPAC SMS shall default the Out-Bound Flow Control Upper Threshold tunable parameter to 100 messages. (previously NANC 368, Req 2)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-25	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

RR6-150 Out-Bound Flow Control Upper Threshold Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Out-Bound Flow Control Upper Threshold tunable parameter. (previously NANC 368, Req 3)

RR6-151 Out-Bound Flow Control Lower Threshold Tunable

NPAC SMS shall provide an Out-Bound Flow Control Lower Threshold tunable parameter which is defined as the number of non-responsive messages sent to a SOA/LSMS that is in a Flow Control state before normal processing is resumed, on a per association basis. (previously NANC 368, Req 4)

RR6-152 Out-Bound Flow Control Lower Threshold Tunable Default

NPAC SMS shall default the Out-Bound Flow Control Lower Threshold tunable parameter to 75 messages. (previously NANC 368, Req 5)

RR6-153 Out-Bound Flow Control Lower Threshold Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Out-Bound Flow Control Lower Threshold tunable parameter. (previously NANC 368, Req 6)

6.9 Roll-Up Activity and Abort Behavior

RR6-154 Roll-Up Activity-Single Tunable

NPAC SMS shall provide a Roll-Up Activity Timer — Single tunable parameter, which is defined as the number of minutes before roll-up activity is initiated for an event involving a single SV. (previously NANC 347/350, Req 1)

RR6-155 Roll-Up Activity-Single Tunable Default

NPAC SMS shall default the Roll-Up Activity Timer — Single tunable parameter to 15 minutes. (previously NANC 347/350, Req 2)

RR6-156 Roll-Up Activity-Single Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Roll-Up Activity Timer — Single tunable parameter. (previously NANC 347/350, Req 3)

RR6-157 Roll-Up Activity Timer Expire SVRange Tunable

NPAC SMS shall provide a Roll-Up Activity Timer Expire SVRange tunable parameter which is defined as the number of minutes before roll-up activity is initiated for an event involving a range of SVs. (previously NANC 347/350, Req 4)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-26	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

RR6-158 Roll-Up Activity Timer Expire SVRange Tunable Default

NPAC SMS shall default the Roll-Up Activity Timer Expire SVRange tunable parameter to 60 minutes. (previously NANC 347/350, Req 5)

RR6-159 Roll-Up Activity Timer Expire SVRange Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Roll-Up Activity Timer Expire SVRange tunable parameter. (previously NANC 347/350, Req 6)

RR6-160 Abort Processing Behavior Upper Threshold Tunable

NPAC SMS shall provide an Abort Processing Behavior Upper Threshold tunable parameter which is defined as the number of minutes before an NPAC abort will occur for a SOA/LSMS that has at least one outstanding message with a delta between the origination time and the current time that is equal to or greater than the tunable window, regardless of whether the SOA/LSMS has incurred any other activity (request or response). (previously NANC 347/350, Req 7)

RR6-161 Abort Processing Behavior Upper Threshold Tunable Default

NPAC SMS shall default the Abort Processing Behavior Upper Threshold tunable parameter to 60 minutes. (previously NANC 347/350, Req 8)

RR6-162 Abort Processing Behavior Upper Threshold Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Abort Processing Behavior Upper Threshold tunable parameter. (previously NANC 347/350, Req 9)

6.10 NPAC Monitoring of SOA and LSMS Associations

RR6-163 NPAC SMS Monitoring of SOA and Local SMS Connections via a Application Level Heartbeat

NPAC SMS shall be capable of supporting an Application Level Heartbeat via an Application Level Heartbeat message to a Service Provider SOA/Local SMS. (previously NANC 299, Req 1)

RR6-164 NPAC SMS-to-SOA Application Level Heartbeat Indicator

NPAC SMS shall provide a Service Provider SOA Application Level Heartbeat Indicator tunable parameter which defines whether a SOA supports an Application Level Heartbeat message. (previously NANC 299, Req 2)

RR6-165 NPAC SMS-to-SOA Application Level Heartbeat Indicator Default

NPAC SMS shall default the Service Provider SOA Application Level Heartbeat Indicator tunable parameter to FALSE. (previously NANC 299, Req 3)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-27	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

RR6-166 NPAC SMS-to-SOA Application Level Heartbeat Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Application Level Heartbeat Indicator tunable parameter. (previously NANC 299, Req 4)

RR6-167 NPAC SMS-to-Local SMS Application Level Heartbeat Indicator

NPAC SMS shall provide a Service Provider Local SMS Application Level Heartbeat Indicator tunable parameter which defines whether an Local SMS supports an Application Level Heartbeat message. (previously NANC 299, Req 5)

RR6-168 NPAC SMS-to- Local SMS Application Level Heartbeat Indicator Default

NPAC SMS shall default the Service Provider Local SMS Application Level Heartbeat Indicator tunable parameter to FALSE. (previously NANC 299, Req 6)

RR6-169 NPAC SMS-to- Local SMS Application Level Heartbeat Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Local SMS Application Level Heartbeat Indicator tunable parameter. (previously NANC 299, Req 7)

RR6-170 NPAC SMS Application Level Heartbeat Tunable Parameter

NPAC SMS shall provide an Application Level Heartbeat Interval tunable parameter that defines the period of quiet time (no interface traffic) the NPAC should wait after the receipt of any interface traffic (request or response), before sending an Application Level Heartbeat message to the SOA/Local SMS. (previously NANC 299, Req 8)

RR6-171 NPAC SMS Application Level Heartbeat Tunable Parameter Usage

NPAC SMS shall use the same tunable value for both SOA and the Local SMS Associations. (previously NANC 299, Req 9)

RR6-172 NPAC SMS Application Level Heartbeat Tunable Parameter Default

NPAC SMS shall default the Application Level Heartbeat Interval tunable parameter to 15 minutes. (previously NANC 299, Req 10)

RR6-173 NPAC SMS Application Level Heartbeat Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the NPAC SMS Application Level Heartbeat tunable parameter. (previously NANC 299, Req 11)

RR6-174 NPAC SMS Application Level Heartbeat Timeout Tunable Parameter

NPAC SMS shall provide an Application Level Heartbeat Timeout tunable parameter that defines the period of time the NPAC should wait after sending an Application Level Heartbeat message to the SOA/Local SMS and not receiving a response from the SOA/Local SMS, before aborting the association. (previously NANC 299, Req 12)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-28	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

RR6-175 NPAC SMS Application Level Heartbeat Timeout Tunable Parameter Usage

NPAC SMS shall use the same tunable value for both SOA and the Local SMS Associations. (previously NANC 299, Req 13)

RR6-176 NPAC SMS Application Level Heartbeat Timeout Tunable Parameter Default

NPAC SMS shall default the Application Level Heartbeat Timeout tunable parameter to 1 minute. (previously NANC 299, Req 14)

RR6-177 NPAC SMS Application Level Heartbeat Timeout Tunable Parameter Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the NPAC SMS Application Level Heartbeat Timeout tunable parameter. (previously NANC 299, Req 15)

6.11 Separate SOA Channel for Notifications

RR6-178 SOA Notification Channel Service Provider Indicator

NPAC SMS shall provide a Service Provider SOA Notification Channel indicator which defines whether a SOA supports a separate SOA association dedicated to notifications. (previously NANC 383, Req 1)

RR6-179 SOA Notification Channel Service Provider Indicator — Default

NPAC SMS shall default the Service Provider SOA Notification Channel indicator to FALSE. (previously NANC 383, Req 2)

RR6-180 SOA Notification Channel Service Provider Indicator — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Notification Channel indicator. (previously NANC 383, Req 3)

RR6-181 Separation of Association Functions

DELETED

RR6-182 Separate Association for the Notification Function From different NSAPs

NPAC SMS shall accept a separate association from the SOA for the Notification function from different Service Provider NSAPs, when the SOA Notification Channel tunable is set to TRUE. (previously NANC 383, Req 5)

RR6-183 Security Management of Multiple SOA Associations of Different Association Functions

NPAC SMS shall manage security for multiple SOA associations of different association functions from different Service Provider NSAPs. (previously NANC 383, Req 6)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-29	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

NPAC SMS Interfaces

RR6-184 Sending of SOA Notifications when Notification Channel is Active

NPAC SMS shall send notifications for a particular Service Provider across a Notification Channel when it is active. (previously NANC 383, Req 7)

RR6-185 Separate Notification Channel during Recovery

NPAC SMS shall only allow a separate Notification Channel association to request notification recovery, when the Service Provider SOA Notification Channel tunable is TRUE. (previously NANC 383, Req 8)

RR6-186 Treatment of Multiple Associations when there is an Intersection of Association Function

NPAC SMS shall accept an association bind request, in the case of an intersection of the association functions of an existing SOA association, and abort any previous associations that use that same function. (previously NANC 383, Req 9)

6.12 Maintenance Window Timer Behavior

RR6-187 NPAC Maintenance Windows — Timer Update Tool

NPAC SMS shall support a “Knowledgeable-Internal-NPAC-Generation — Timer-Update-Tool” that would update applicable timer events based on an input parameter that defined the amount of time the timers should be extended. (previously NANC 385, Req 1)

RR6-188 NPAC Maintenance Windows — Timer Update Tool — Affected Timers

NPAC SMS shall use the “Knowledgeable-Internal-NPAC-Generation — Timer-Update-Tool” to update the following timers:

• Initial Concurrence Window (New SPID and Old SPID, Short and Long)

• Final Concurrence Window (New SPID and Old SPID, Short and Long)

• Cancellation Initial Concurrence Window (New SPID and Old SPID, Short and Long)

• Cancellation Final Concurrence Window (New SPID and Old SPID, Short and Long)

(previously NANC 385, Req 2)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	6-30	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

7. Security

7.1 Overview

In addition to the general security requirements based on the user interface paradigm, there are requirements for the security on an OSI application-to-application interface (such as the one specified in Section 6, NPAC SMS Interfaces, for the SMS to SMS and SMS to SOA interfaces).

7.2 Identification

The NPAC will accept only authorized NPAC customers through interface connections, and among NPAC customers, the NPAC will make appropriate limitations on their actions (for example, letting only old or new Service Providers view a pending record). The NPAC will only accept authorized customer user IDs. However, the NPAC will make no distinction among an NPAC customer’s employees; the NPAC customer and their systems must control individual NPAC customer employee actions.

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 Administrative and NPAC SOA Low-tech Interfaces.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

7.3 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 Administrative and NPAC SOA Low-Tech Interfaces.

R7-10 User Authentication

NPAC SMS shall authenticate the identity of all NPAC and Service Provider users of the NPAC Administrative and NPAC SOA Low-tech Interfaces prior to their initially gaining access to NPAC SMS.

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

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-3	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-4	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

R7-27.1 Password Generator

NPAC SMS shall provide a password generator.

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

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-5	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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, and calendar date.

R7-40.1 System Access, User Authentication Procedure Entry — Method

NPAC SMS shall provide a mechanism to restrict user login based on method of entry.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-6	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-7	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

          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

NPAC SMS shall provide security documentation that defines and describes procedures for adding users.

R7-50.2 System Access, Security Administration -Deleting Users

NPAC SMS shall provide security documentation that defines and describes procedures for deleting users.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-8	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

R7-53.3 Authorized User Access to Data

NPAC SMS shall ensure that only authorized NPAC Administrative and NPAC SOA Low-tech Interfaces 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.

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

7.5 Data and System Integrity

R7-63 Identify Originator of System Resources

NPAC SMS shall identify the originator of any accessible system resources.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-9	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

R7-67 Database Integrity Checking

NPAC SMS shall include database integrity checking utilities for the NPAC SMS database.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-10	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

7.6 Audit

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-11	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-12	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-13	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-14	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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 NPA Administrative and NPAC SOA Low-tech Interfaces upon completion of the user login sequence.

7.8 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

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.9 OSI Security Environment

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-15	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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.9.3 Security Mechanisms

This section outlines the requirements to specify security mechanisms.

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-16	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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

• System ID

• System type

• User ID

• Departure time

• Sequence number

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-17	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

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.

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.9.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-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.9.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.2 Generalized Time — Valid Message Timeframe

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 the Departure Time Threshold tunable number of minutes of the NPAC SMS system clock.

RR7-3 Generalized Time — Departure Time Threshold Tunable Parameter

NPAC SMS shall provide a Departure Time Threshold tunable, which is defined as the maximum number of minutes of difference between the departure time of a message from the sending system, and the receipt of that message at the receiving system.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-18	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

RR7-4 Generalized Time — Departure Time Threshold Tunable Parameter Default

NPAC SMS shall default the Departure Time Threshold tunable parameter to five (5) minutes.

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

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

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-19	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

R7-108.3 Phone Confirmation

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

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

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 Application Basis

NPAC SMS shall expect new key initiation to be requested on a per Service Provider application basis.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-20	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Security

R7-111.7 NPAC Key Change Algorithm

NPAC SMS shall, upon determination that its key list has been compromised, change its own private key.

R7-111.8 Service Provider Key Marked Used/Invalid

NPAC SMS shall only mark an SP key as invalid or used when the service provider changes keys.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	7-21	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

8. Audit Administration

2.1 Overview

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

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

A8-1 Service Provider Audits Issued Immediately

NPAC SMS will process audit requests from service providers immediately.

8.2 Service Provider User Functionality

R8-1 Service Providers Audit Request — Single TN

DELETED

R8-2.1 Service Providers Audit Request — Range of TNs

DELETED

RR8-19 Service Provider Audit Request — Required Information

NPAC SMS shall require the following information as part of an audit request over the SOA to NPAC SMS interface or Service Provider Personnel:

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

• Unique Audit Name

• TN (either a single or range of TNs)

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

• Specify an activation Date/Time stamp range, i.e., only audit records activated between a specific time window

• 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

- WSMSC data (only Service Provider Local SMSs that support this attribute will be audited on this attribute)

Default: Full audit

8.3 NPAC User Functionality

R8-4         NPAC Personnel Audit Request — Single TN

DELETED

R8-5.1       NPAC Personnel Audit Request — Range of TNs

DELETED

RR8-20      NPAC Personnel Audit Request – Required Information

NPAC SMS shall require the following information as part of an audit request from NPAC Personnel:

• Unique Audit Name

• TN (either a single or a range of TNs)

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

• Specify an activation Date/Time stamp range, i.e., only audit records activated between a specific time window.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

• 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

- WSMSC data (only Service Provider Local SMSs that support this attribute will be audited on this attribute)

Default: Full audit

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.

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

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 that are accepting Subscription Version data downloads for the given NPA-NXX via the NPAC SMS to Local SMS interface, as described in the NPAC SMS Interoperable Interface Specification.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

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, broadcast to the Service Provider an update for any TN that was NOT found in the Service Provider’s Subscription Version database, where the status of the Subscription Version contains a status of Active or Partial Failure.

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.

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-19      Record Audit Results in an Audit Log

NPAC SMS shall record all audit results in an audit log.

RR8-4     Skip Subscription Versions with a Status of Sending

NPAC SMS shall, when processing the audit query results from a Local SMS, NOT perform comparisons or attempt to correct any Subscription Version within the requested range, which has a status of sending.

RR8-5       Report No Discrepancies Found in Audit Results for Skipped Subscription Versions

NPAC SMS shall consider a skipped Subscription Version as non-discrepant, and report no discrepancies found in the audit results.

RR8-21      Audit for Support of SV Type

NPAC SMS shall audit the SV Type attribute as part of a full audit scope, only when a Service Provider’s LSMS supports SV Type. (previously NANC 399, Req 17)

RR8-22      Audit for Support of Alternative SPID

NPAC SMS shall audit the Alternative SPID attribute as part of a full audit scope, only when a Service Provider’s LSMS supports Alternative SPID. (previously NANC 399, Req 18)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

8.5 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 by specifying the unique audit name.

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 containing the following information:

• Audit name

• 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

• An audit failure

• No discrepancies found

R8-22      NPAC Personnel Generate and View an Audit Report

NPAC SMS shall allow NPAC and Service Provider personnel 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-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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

8.6 Additional Requirements

RX8-1      Valid Audit Statuses

NPAC SMS shall support the following valid audit statuses:

• In-progress

• Canceled

• Complete

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

RR8-3.1   Data Integrity Frequency — Tunable Parameter

NPAC SMS shall provide a Data Integrity Frequency tunable parameter which is defined as the frequency in days that the data integrity sampling is performed.

RR8-3.2    Data Integrity Frequency — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Data Integrity Frequency tunable parameter.

RR8-3.3    Data Integrity Frequency — Tunable Parameter Default

NPAC SMS shall default the Data Integrity Frequency tunable parameter to seven days. The allowable range is between one and ninety (1-90) days.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

8.8      Audit Processing in a Number Pool Environment

The Audit processing that is described in this section deals with all Subscription Versions in a Number Pooling environment, whether ported, pooled, or pooled ported numbers. Audit processing in a Number Pooling environment will use the information in the Service Provider’s profile (NPAC Customer LSMS EDR Indicator) to determine whether to send a query for a TN Range only (non-EDR Local SMSs), or a TN Range and Block (EDR Local SMSs).

RR8-6    Audit Processing for All Subscription Versions in a Number Pooling Environment

NPAC SMS shall process an audit request of an Active-Like Subscription Version(s), by performing the following steps: (Previously A-2)

• Validate that the audit request is valid (existing FRS functionality).

• Validate that the Block associated with the TN contained in the Subscription Version(s), exists in the NPAC SMS.

• Send queries of TN Range, or TN Range with Activation Timestamp, to non-EDR Local SMSs that are accepting downloads for the given NPA-NXX.

• Send queries of Block(s) AND TN Range or TN Range with Activation Timestamp, to EDR Local SMSs that are accepting downloads for the given NPA-NXX.

• Process non-EDR Local SMS responses using same functionality as audits for LSPP and LISP Subscription Versions.

• Process EDR Local SMS responses for the Block(s) by doing a comparison. If a discrepancy exists, the NPAC SMS data is considered “correct”, and a correction should be sent to the EDR Local SMS.

• Process EDR Local SMS responses for Subscription Versions, as follows:

Ø	LSPP and LISP – Use existing audit functionality
Ø	POOL – “No Data” is correct response, SVs for other LNP Types need to be deleted.

• Send audit results and notification of discrepancies, back to requesting SOA, only for the TN Range that was requested, even if other TNs were affected because of EDR Local SMS. The existing notification report will be unchanged, and will not contain block information. In cases were an EDR Local SMS erroneously contained a Number Pool Block, the NPAC SMS shall send a Number Pool Block delete to the Local SMS, but shall not report any discrepancy back to the requesting SOA for this Local SMS if this was the only discrepancy.

• Suppress status change and attribute change notifications, for Subscription Versions, to the Block Holder SOA.

• Send status change and attribute change notifications, for Blocks, to the Block Holder SOA when the SOA Origination is TRUE, and only when an audit correction causes the status and/or Failed SP List to be updated to different values.

RR8-7   Audit Discrepancy and Results Notifications for Pooled Number Subscription Versions to Requesting SOA

NPAC SMS shall, for audits of Subscription Versions with LNP Type of POOL, send notifications of discrepancies found and audit results to the requesting SOA. (Previously A-10)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

RR8-8    Audit Discrepancy and Results Notifications for Pooled Number Subscription Versions for Audited TNs

NPAC SMS shall, for audits of Subscription Versions with LNP Type of POOL, only send back notifications to the requesting SOA, of the audited TNs, even if other TNs were modified. (Previously A-15)

RR8-9    Audit Status Attribute Value Change Notification Send for Pooled Number Blocks

NPAC SMS shall send status change notifications, for Blocks, to the Block Holder SOA when the SOA Origination is TRUE, only when an audit correction causes the status and/or Failed SP List to be updated to different values. (Previously A-35)

Note: Therefore, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Partial Failure, nothing is sent to the Block Holder SOA; however, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Active, a notification is sent to the Block Holder SOA. Likewise, if a Failed SP List gets updated, a notification is sent to the Block Holder SOA.

RR8-10   Audit Attribute Value Change Notification Send for Pooled Number Blocks

NPAC SMS shall send an attribute change notifications, for Blocks, to the Block Holder SOA when the SOA Origination is TRUE, only when an audit correction causes the status and/or Failed SP List to be updated to different values. (Previously A-36)

Note: Therefore, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Partial Failure, nothing is sent to the Block Holder SOA; however, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Active, a notification is sent to the Block Holder SOA. Likewise, if a Failed SP List gets updated, a notification is sent to the Block Holder SOA.

RR8-11   Audit for Pooled Numbers and Block to EDR Local SMS

NPAC SMS shall send a query for Subscription Version(s), resulting from the TN Range or TN Range with Activation Timestamp audit request for Subscription Version(s) with LNP Type of POOL, and a query for the corresponding Block of the Subscription Version(s) with LNP Type of POOL, to an EDR Local SMS that is accepting Block and Subscription Version data download for the given NPA-NXX via the NPAC SMS to Local SMS Interface. (Previously A-40)

RR8-12   Audit Response – Ignore missing SVs for Pooled Ports at EDR Local SMS

NPAC SMS shall consider a query response of No Data, as a valid response from an EDR Local SMS, for a Subscription Version with LNP Type of POOL, and shall not include this as a discrepancy for the Subscription Version. (Previously A-50)

RR8-13   Audit Response — Delete erroneous SVs for Pooled Ports at EDR Local SMS

NPAC SMS shall consider a query response, which contains a Subscription Version, as a discrepancy from an EDR Local SMS, for a Subscription Version with LNP Type of POOL, by sending a Subscription Version Delete message for the Subscription Version. (Previously A-60)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Audit Administration

RR8-14   Audit Response – Compare NPAC SMS Block to Service Provider Block at EDR Local SMS

NPAC SMS shall conduct a comparison of the Block sent back in the audit response by the EDR Local SMS, to the Block stored in the NPAC SMS. (Previously A-80)

RR8-15   Audit Response – Block Missing from EDR Local SMS

NPAC SMS shall consider a query response of No Data related to a Block, for a Block that exists in the NPAC SMS, other than a status of Old, as a discrepant response from an EDR Local SMS, and shall send a Block Create/Activate message. (Previously A-90)

RR8-16   Audit Response – Block Discrepant at EDR Local SMS

NPAC SMS shall consider a query response with mis-matched data for a Block, as a discrepant response from an EDR Local SMS, and shall send a Block Modify message. (Previously A-100)

RR8-17   Audit Response – Extra Block at EDR Local SMS

NPAC SMS shall consider a query response of an existing Block, for a Block that has been de-pooled, as a discrepant response from an EDR Local SMS, when the latest version of the Block on the NPAC SMS contains a status of old, and shall send a Block Delete message. (Previously A-110)

RR8-18   Audit Processing – Skipping In-Progress Blocks

NPAC SMS shall skip the audit of a Block with a status of Sending, such that no discrepancies will be found for the Block. (Previously A-120)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	8-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

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 Administrative Interface to select the type of report required.

R9-2      NPAC Personnel Selection of Output Destination

NPAC SMS shall allow NPAC personnel using the NPAC Administrative Interface 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 Administrative Interface 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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

RX9-1      Service and Network Data Reports

NPAC SMS shall support the following service and network data reports for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface:

1.	NPAC Service Tunable Parameters Report
2.	List of Service Provider’s LRNs
3.	Open NPA-NXXs List

RX9-2      Service Provider Reports

NPAC SMS shall support the following Service Provider reports for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface:

1.	Service Provider Profile (Service Provider’s own data only)
2.	Service Provider’s Subscription List by Status (Service Provider’s own data only)

RX9-3      Subscription Data Reports

NPAC SMS shall support the following subscription data reports for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface:

1.	Subscriptions Listed by Status
2.	Subscriptions Listed by Service Provider by Status

RX9-4      System Reports

NPAC SMS shall support the following system reports for NPAC system administration personnel using the NPAC Administrative Interface:

1.	Overall CPU System Utilization
2.	Storage Utilization
3.	NPAC SMS Application Performance (SOA/LSMS Downloads per Second)
4.	NPAC SMS Application Performance (SOA/LSMS Subscription Activation Time)
5.	NPAC SMS-SOA Link Utilization
6.	NPAC SMS-LSMS Link Utilization
7.	NPAC SMS Application Performance (SOA/LSMS Response Time)
8.	NPAC SMS Application Performance (Interface Transaction Rate)
9.	NPAC SMS Application Performance (Provider SMS Database Sampling)

RX9-5      Security Reports

NPAC SMS shall support the following security reports for NPAC security administration personnel using the NPAC Administrative Interface:

1. Access Privileges Matrix

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

2.	Authorized Users List
3.	Security Log
4.	Invalid Access Attempts
5.	Encryption Keys List

RX9-6      Log File Reports

NPAC SMS shall support the following log file reports for NPAC personnel using the NPAC Administrative Interface:

1.	History Report
2.	Error Report
3.	Service Provider Notification Report
4.	Subscription Transaction Report
5.	Service Provider Administration Report
6.	Subscription Administration Report
7.	Cause Code Usage Log Report
8.	Resend Excluded Service Provider Report

RX9-7      Audit Reports

NPAC SMS shall support an Audit Results Report.

RX9-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 – Database Sample Report

NPAC SMS shall generate an NPAC SMS data integrity report.

9.3 System Functionality

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

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.

9.3.1 National Number Pooling Reports

RR9-7 Pooled Number Reports – OpGUI Report Generation

NPAC SMS shall support reports that list pooling information for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface. (Previously RR9-7 of Appendix F: Midwest Region Number Pooling)

RR9-2 Pooled Number Reports – Query functions

NPAC SMS shall support pooled number reports that allow queries on any combination of SPID, and TN Range, where the NPAC SMS returns all TNs that meet the selection criteria. (Previously R-10)

RR9-8 Pooled Number Reports – Block Holder Default Routing Report

NPAC SMS shall support a report that list the number pool range, the block holder, and the block holder default routing information for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface. (Previously RR9-8 of Appendix F: Midwest Region Number Pooling)

RR9-3 Pooled Number Reports – Block Holder Default Routing Report Data Elements

NPAC SMS shall support a report that lists the number pool range, the block holder, and the block holder default routing information, that contains the Block Holder ID, Service Provider Name, and the following data elements: (Previously R-25)

Block ID (primary sort)
NPA-NXX-X (secondary sort)
Effective Date
LRN
DPC (CLASS, CNAM, ISVM, LIDB and if supported WSMSC)
SSN (CLASS, CNAM, ISVM, LIDB and if supported WSMSC)

RR9-4 Pooled Number Reports – Block Holder Default Routing Report Page Break

NPAC SMS shall page break the report listed in RR9-3, for every change in new Block Holder ID. (Previously R-26)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

RR9-9 Pooled Number Reports – Active-Like TNs in a NPA-NXX-X Report

NPAC SMS shall support a report that list all Active-Like numbers in a 1K block (NPA-NXX-X) for a block holder, for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface. (Previously R-30)

RR9-10 Pooled Number Reports – Active-Like TNs in a NPA-NXX-X Report Data Elements

NPAC SMS shall support a report that lists all Active-Like numbers in a 1K Block for a block holder, where the status is active/partial failure/old with a Failed SP List/disconnect pending, that contains the following data elements: (Previously R-40)

TN (primary sort)
LNP Type
Activation Start Time Stamp
SP Name
Status

RR9-11 Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report

NPAC SMS shall support a report, used for NPA-NXX-X and Block Creation, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where no active Subscription Version exists, or have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the Subscription Version is a Port-to-Original port, for NPAC personnel using the NPAC Administrative Interface. (Previously R-70)

RR9-12 Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report Data Elements

NPAC SMS shall support a report, used for NPA-NXX-X and Block Creation, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where no active Subscription Version exists, or have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the Subscription Version is a Port-to-Original port, that contains the following data elements: (Previously R-80)

TN
Old Service Provider SPID
New Service Provider SPID
Due Date
Status

RR9-13 Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report Sort Priority

NPAC SMS shall sort the report listed in RR9-12, in the following order: (Previously R-81)
     New Service Provider SPID (primary sort)
     TN (secondary sort)

RR9-14 Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report Page Break

NPAC SMS shall page break the report listed in RR9-12, for every change in SPID. (Previously R-82)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

RR9-15 Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report

NPAC SMS shall support a report, used for de-pooling, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the currently active Subscription Version is LNP Type of POOL, for NPAC personnel using the NPAC Administrative Interface. (Previously R-130)

RR9-16 Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report Data Elements

NPAC SMS shall support a report, used for de-pooling, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the currently active Subscription Version is LNP Type of POOL, that contains the following data elements: (Previously R-140)

TN
Old Service Provider SPID
New Service Provider SPID
Due Date
Status

RR9-17 Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report Sort Priority

NPAC SMS shall sort the report listed in RR9-16, in the following order: (Previously R-141)
      New Service Provider SPID (primary sort)
      TN (secondary sort)

RR9-18 Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report Page Break

NPAC SMS shall page break the report listed in RR9-16, for every change in new SPID. (Previously R-142)

9.3.2 Cause Code Reports

RR9-19 Logging Cause code usage by SPID Reporting

NPAC SMS shall log the following information when an Old Service Provider places a Subscription Version into conflict: date, time, New SPID, Old SPID, cause code value. (previously NANC 375, Req 4)

RR9-20 Cause Code Usage Log Report via OpGUI

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Cause Code Usage Log Report on cause code usage log data for conflict situations. (previously NANC 375, Req 5)

RR9-21 Cause Code Usage Log Report Monthly Generation

NPAC SMS shall produce a monthly Cause Code Usage Log Report on cause code usage log data for conflict situations. (previously NANC 375, Req 6)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

RR9-22 Cause Code Usage Log Report Sort Criteria

NPAC SMS shall separate out the Cause Code Usage Log Report into two sections when generating the Cause Code Usage Log Report on cause code usage log data for conflict situations. The first section will use sort criteria of Old SPID (primary) and New SPID (secondary), the second section will reverse the order and use sort criteria of New SPID (primary) and Old SPID (secondary). (previously NANC 375, Req 7)

RR9-23 Cause Code Usage Log Report Selection Criteria

NPAC SMS shall use selection criteria of month and year when generating the Cause Code Usage Log Report on cause code usage log data for conflict situations. (previously NANC 375, Req 8)

RR9-24 Cause Code Usage Log Report Display

NPAC SMS shall display the Cause Code Usage Log Report data with headers as specified in the example below. A page break will separate out every change of SPID that is in the primary sort. (previously NANC 375, Req 9)

9.3.3 Resend Excluded Service Provider Report

RR9-25 Subscription Version Failed SP List – Excluded Service Provider Log Data Availability for the Excluded Service Provider Report

NPAC SMS shall allow the Excluded Service Provider log data to be available for the Excluded Service Provider Report. (previously NANC 227/254, Req 4)

RR9-26 Subscription Version Failed SP List – Resend Excluded Service Provider Report by Current SPID via OpGUI

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Current SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 5)

RR9-27 Subscription Version Failed SP List – Resend Excluded Service Provider Report by Current SPID Request

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and current SPID option (of either an individual SPID or all SPIDs) when generating the Resend Excluded Service Provider Report by Current SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 6)

RR9-28 Subscription Version Failed SP List – Resend Excluded Service Provider Report by Current SPID Request Sort Criteria

NPAC SMS shall use the following sort order when generating the Resend Excluded Service Provider Report by Current SPID on Excluded Service Provider log data:

1. current SPID (ascending)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

2.	TN (ascending)
3.	date/time (earliest date/time to latest date/time)
4.	excluded SPID (ascending)
5.	SVID (ascending)

(previously NANC 227/254, Req 7)

RR9-29 Subscription Version Failed SP List –Resend Excluded Service Provider Report by Excluded SPID via OpGUI

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 8)

RR9-30 Subscription Version Failed SP List – Resend Excluded Service Provider Report by Excluded SPID Request

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and excluded SPID option (of either an individual SPID or all SPIDs) when generating the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 9)

RR9-31 Subscription Version Failed SP List –Resend Excluded Service Provider Report by Excluded SPID Request Sort Criteria

NPAC SMS shall use the following sort order when generating the Excluded Service Provider Report on Excluded Service Provider log data:

1.	excluded SPID (ascending)
2.	TN/NPA-NXX-X (ascending)
3.	date/time (earliest date/time to latest date/time)
4.	currentSPID/Blockholder SPID (ascending)
5.	SVID/Number Pool Block -ID (ascending)

(previously NANC 227/254, Req 10)

RR9-32 Number Pool Block Failed SP List – Excluded Service Provider Log Data Availability for the Excluded Service Provider Report

NPAC SMS shall allow the Excluded Service Provider log data to be available for the Excluded Service Provider Report. (previously NANC 300, Req 4)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

RR9-33 Number Pool Block Failed SP List –Resend Excluded Service Provider Report by Current SPID/Blockholder SPID via OpGUI

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Current SPID/Blockholder SPID on Excluded Service Provider log data. (previously NANC 300, Req 5)

RR9-34 Number Pool Block Failed SP List – Resend Excluded Service Provider Report Request by Current SPID/Blockholder SPID

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and Current SPID/Blockholder SPID option (of either an individual SPID or all SPIDs in the failed SP list) when generating the Resend Excluded Service Provider Report by Current SPID/Blockholder SPID on Excluded Service Provider log data. (previously NANC 300, Req 6)

RR9-35 Number Pool Block Failed SP List – Resend Excluded Service Provider Report by Current SPID/Blockholder SPID Request Sort Criteria

NPAC SMS shall use the following sort order when generating the Resend Excluded Service Provider Report by Current SPID/Blockholder SPID on Excluded Service Provider log data:

1.	Current SPID/Blockholder SPID (ascending)
2.	TN/NPA-NXX-X (ascending)
3.	date/time (earliest date/time to latest date/time)
4.	excluded SPID (ascending)
5.	SVID/Number Pool Block -ID (ascending)

(previously NANC 300, Req 7)

RR9-36 Number Pool Block Failed SP List –Resend Excluded Service Provider Report by Excluded SPID via OpGUI

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 300, Req 8)

RR9-37 Number Pool Block Failed SP List – Resend Excluded Service Provider Report by Excluded SPID Request

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and excluded SPID option (of either an individual SPID or all SPIDs) when generating the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 300, Req 9)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

RR9-38 Number Pool Block Failed SP List –Resend Excluded Service Provider Report by Excluded SPID Request Sort Criteria

NPAC SMS shall use the following sort order when generating the Excluded Service Provider Report on Excluded Service Provider log data:

1.	excluded SPID (ascending)
2.	TN/NPA-NXX-X (ascending)
3.	date/time (earliest date/time to latest date/time)
4.	Current SPID/Blockholder SPID (ascending)
5.	SVID/Number Pool Block -ID (ascending)

(previously NANC 300, Req 10)

Note: The TN and SVID attributes were added to requirements 7 & 10 in this change order because of the corresponding change order (NANC 227/254) for SVs in Release 3.3.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	9-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	10-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

Performance and Reliability

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.

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 both the NPAC SMS to Local SMS interface and the SOA to NPAC 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 reason for the downtime

• When the down time will start

• When the down time will stop

Release 3.3: © 1997 — 2006 NeuStar, Inc.	10-12	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Performance and Reliability

• An NPAC contact number

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

• Unscheduled down time

• Mean time to repair

• System availability on a monthly basis to the Service Provider

Release 3.3: © 1997 — 2006 NeuStar, Inc.	10-13	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Performance and Reliability

10.2       Capacity and Performance

R10-16 Capacity

NPAC SMS will have the capacity to support a user group in the NPAC sized for the region they service.

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

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	10-14	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Performance and Reliability

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	10-15	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Performance and Reliability

1.1       Billing

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.

R11-5 Generating Usage Measurements for the Number of Messages Processed by type

NPAC SMS shall measure the number of messages processed by type for each Service Provider.

R11-6 Generating Usage Measurements for the Number of Messages Downloaded

NPAC SMS shall measure the number of messages downloaded to each Service Provider.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	11-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Performance and Reliability

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 Service Provider

• Allocated Mass Storage

• Messages Processed by type (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.

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	11-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Business Process Flow Diagrams

Appendix A. Business Process Flow Diagrams

This appendix contains pictorial representations of the business process flows discussed in Section 2, Business Process Flows, on page 2-1.

[Graphic Omitted: NPAC Business Process Flows Legend]

[Graphic Omitted: NPAC SMS Provision Service Process]

[Graphic Omitted: NPAC SMS Subscription Version Creation Process]

[Graphic Omitted: NPAC SMS Activate and Data Download Process]

[Graphic Omitted: NPAC SMS Disconnect Process]

Release 3.3: © 1997 — 2006 NeuStar, Inc.	A-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Business Process Flow Diagrams

[Graphic Omitted: NPAC SMS Repair Process]

[Graphic Omitted: Conflict Process]

[Graphic Omitted: NPAC SMS Disaster Recovery Process]

[Graphic Omitted: Cancellation Process]

[Graphic Omitted: Audit Process]

[Graphic Omitted: Report Process]

Release 3.3: © 1997 — 2006 NeuStar, Inc.	A-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Glossary

Appendix B. Glossary

This glossary provides a comprehensive list of definitions and acronyms that apply to NPAC SMS.

Active-like SVs	SVs that contain a status of active, sending, partial failure, old with a Failed SP List, or disconnect pending.
Block	A range of 1000 pooled TNs within the NPA-NXX, beginning with a station of n000, and ending with n999, where n is a value between 0 and 9.
Block Holder	The recipient Service Provider of a 1K Block from the code holder. Also defined as the NPA-NXX-X holder in the LERG Routing Guide.
Cascading Delete	A delete of an NPA-NXX-X where the NPAC sends deletes of Pooled SV data to non-EDR LSMSs, and sends deletes of Block data to EDR LSMSs. Once all LSMSs have successfully deleted the Pooled data, the status of SVs and the Block is Old, and both Failed SP Lists are empty, the NPA-NXX-X is deleted.
Central Time (standard/daylight)	This is the time in the central time zone, that includes daylight savings time. It changes twice a year based on standard time and daylight savings time. The NPAC SMS runs on hardware that uses this time.
CLASS	Custom Local Area Signaling Services. Premium local service features, such as call forwarding or automatic callback.
CMIP	Common Management Information Protocol
CMISE	Common Management Information Service Element
CNAM	Caller Id with Name
Code Holder	The code holder is the LERG Routing Guide assignee of the NPA-NXX.
Contaminated Number	An unavailable number (e.g., working), within a 1K Block, at the time the 1K Block is donated to the Pooling Administrator.
De-Pool	Return of a 1K pooled block to the Number Administrator. Also referred to as “un-allocation of the block”, or “reclamation” (INC definition).
Default Routing Restoration	Reinstatement of the default routing for the TN as defined in the applicable block information, in order to provide vacant number treatment.
DPC	Destination Point Code
EDR (Efficient Data Representation)	The ability to represent 1000 TNs as a range.
EDR within the NPAC	A storage mechanism where a 1K range of TNs is represented, stored and communicated as a Range entity.
Effective Date	The date that is considered to be the “ownership switchover” date for the 1K Block from the Code Holder (NPA-NXX owning SP) to the Block Holder ( NPA-NXX-X owning SP). This is the date published in the LERG Routing Guide, and is also used by the Pooling Administrator and the NPAC.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	B-1	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Glossary

FR	Frame Relay
GDMO	Guideline for Definition of Managed Objects
GMT	Greenwich Mean Time
GTT	Global Title Translation
ICC	Illinois Commerce Commission
ISO	International Organization of Standardization
ISVM	Inter-Switch Voice Mail
LERG	Refers to the TelcordiaTM LERGTM Routing Guide
LIDB	Line Information Database
LNP	Local Number Portability
Local Time (in the GUI)	The time zone of the local user. Most time representations in the NPAC OP GUI are represented in the user’s local time zone based on the PC’s clock being set to the correct time. The time zone label is included in time display in the GUI.
	EST for Eastern Time Zone
	CST for Central Time Zone
	MST for Mountain Time Zone
	PST for Pacific Time Zone
LRN	Location Routing Number. A routing number in the same form as a TN used to identify the TN’s serving switch when the TN is a ported number.
LSMS	Local Service Management System
LISP	Local Intra-Service Provider Portability. Movement of end-user TN from one switch to another, but within the same Service Provider’s Network.
LSPP	Local Service Provider Portability. Movement of end user TN from one Service Provider to another Service Provider.
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.
NPA	An NPA code is the first three digits of the 10-digit destination number for all inter-NPA calls within the North America Numbering Plan Area.
NPA-NXX-X	A range of 1000 pooled TNs within the NPA-NXX, beginning with a station of n000, and ending with n999, where n is a value between 0 and 9.
NPAC Customer	Any customer of the NPAC SMS.
NPAC SMS	Number Portability Administration Center and Service Management System

Release 3.3: © 1997 — 2006 NeuStar, Inc.	B-2	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Glossary

NSAP	Network Layer Service Access Point
Number Pooling Block Holder Information	Data in the NPAC SMS that contains the first 7-digits of a 1K range of TNs, default routing for a block of TNs, and the activation timestamp of the TNs within the 1K range.
Number Pooling NPA-NXX-X Holder Information	Data in the NPAC SMS that contains the first 7-digits of a range of TNs, the block holder (service provider), and the effective date of the block. According to the NPAC definition, this is considered Network data.
NXX	A code normally used as a central office code. It may also be used as an NPA code or special NPA code.
OCN	Operating Company Number
OSI	Open Systems Interconnect
Pending-like SVs	SVs that contain a status of pending, conflict, cancel-pending, or failed.
PKCS	Public Key Crypto System
Port on Demand	Porting of a single TN or range of TN’s from the code holder to the block holder at a time desired by the block holder that is on, or after the effective date of the pool. This is NOT supported by the National Number Pooling architecture.
Ported TN	A TN ported to a switch that is not the NANP-assigned switch.
PPP	Point-To-Point Protocol
Pre-Port	Porting of an entire block of TN’s from the code holder to the block holder on, or after, the effective date of the pool. This is supported by the National Number Pooling architecture.
PSAP	Presentation Layer Service Access Point
Roll-Up Activity	The consolidation/closure of a broadcast event in the NPAC, and feedback (responses, non-responses) from each Service Provider, such that the status and failed-list for an SV or NPB will be updated.
RFP	Request for Proposal
RSA	A popular encryption algorithm whose name is derived from the initials of its inventors: Rivest, Shamir, and Adelman.
Schedule/Re-Schedule of Block Create Event	A process within the NPAC SMS that allows NPAC Personnel to create a Scheduled Event in the NPAC SMS, for a Block Create. The Event can be immediately kicked-off, or scheduled for a future date (pending validation edits in both of these cases).
SCP	Service Control Point
SIC-SMURF	Selection Input Criteria SPID Migration Update Request Files. Files created by the NPAC SMS and used by NPAC and Service Providers to update their databases during a SPID Migration Update.
SMS	Service Management System
Snapback	Notification for TN reassignment.
SOA	Service Order Activation
SP	Service Provider. Generally refers to a facilities-based user of the NPAC SMS.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	B-3	North American Numbering Council (NANC)
	Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Glossary

SSAP	Session Layer Service Access Point
SSN	Subsystem Number
TN	Telephone Number
TSAP	Transport Layer Service Access Point
Unique Alarmable Error Message (Code)	An individual error message in the NPAC SMS that is only used by the NPAC for the individual Number Pooling requirement where the error message is listed. Alarming of the error message is configurable (i.e., it can either be turned ON or turned OFF).
Vacant Number	A non-working number.
Vacant Number Treatment	A recorded announcement played to the calling party, when the NPA-NXX of the TN they have dialed is valid, but the 10-digit TN is not a working number.
Version	Time-sensitive or status-sensitive instance of a subscription.
WSMSC	Wireless Short Message Service Center

Release 3.3: © 1997 — 2006 NeuStar, Inc.	B-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.		March 9, 2006

System Tunables

Appendix C. System Tunables

This appendix provides a comprehensive list of tunables identified throughout the FRS and their default values.

SUBSCRIPTION TUNABLES

	Default
Tunable Name	Value	Units	Valid Range
Long Initial	9	business	1-72
Concurrence Window		hours
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 port and at least one of the Service Providers are using “Long” timers. (T1 timer)
Long Final Concurrence	9	business	1-72
Window		hours
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 port and at least one of the Service Providers are using “Long” timers. (T2 timer)
Short Initial	1	business	1-72
Concurrence Window		hours
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 port and both of the Service Providers are using “Short” timers. (T1 timer)
Short Final Concurrence	1	business	1-72
Window		hours
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 port and both of the Service Providers are using “Short” timers. (T2 timer)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

SUBSCRIPTION TUNABLES

	Default
Tunable Name	Value	Units	Valid Range
Conflict Expiration	30	calendar	1-180
Window		days
The length of time conflict subscriptions will remain in the conflict state before cancellation.
Maximum Subscription	50	records	10-150
Query
The maximum number of subscription versions returned by a query to the NPAC.
Pending Subscription	90	calendar	1-180
Retention		days
The length of time pending subscriptions will remain in the pending state before cancellation.
Conflict Restriction	17:00	HH:MM	00:00-24:00
Window	UTC
	daylight
	savings
	time
	18:00
	UTC
	standard
	time
The time on the business day prior to the New Service Provider due date that a Subscription version is no longer allowed to be set to conflict by the Old Service Provider provided that the Create Subscription Version Final Concurrence Window (T2) timer has expired. The Conflict Restriction Window does not apply for short timers.
Long Conflict Resolution	6	business	1-72
New Service Provider		hours
Restriction
The number of business hours after the subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the new Service Provider using long timers.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

SUBSCRIPTION TUNABLES

	Default
Tunable Name	Value	Units	Valid Range
Short Conflict	6	Business	1-72
Resolution New Service		hours
Provider Restriction
The number of business hours after the subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the new Service Provider using short timers.
Long Cancellation-	9	Business	1-72
Initial Concurrence		hours
Window
The numbers of hours after the version is set to cancel pending by which both Service Providers using long timers are expected to acknowledge the pending cancellation.
Short Cancellation-	9	Business	1-72
Initial Concurrence		hours
Window
The numbers of hours after the version is set to cancel pending by which both Service Providers using short timers are expected to acknowledge the pending cancellation.
Long Cancellation-	9	business	1-72
Final Concurrence		hours
Window
The number of hours after the second cancel pending notification is sent by which both Service Providers using long timers are expected to acknowledge the pending cancellation.
Short Cancellation-	9	business	1-72
Final Concurrence		hours
Window
The number of hours after the second cancel pending notification is sent by which both Service Providers using short timers are expected to acknowledge the pending cancellation.
Old Subscription	18	calendar	1-36
Retention		months
The length of time old subscriptions will be retained.
Cancel-Pending	90	calendar	1-360
Subscription Retention		days

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

SUBSCRIPTION TUNABLES

	Default
Tunable Name	Value	Units	Valid Range
The length of time canceled subscriptions, with last status of pending, will be retained.
Cancel-Conflict	30	calendar	1-360
Subscription Retention		days
The length of time canceled subscriptions, with last status of conflict, will be retained.
Short Business Day	12	calendar	1-24
Duration		hours
The number of hours from the tunable business day start time for short business days.
Long Business Day	12	calendar	1-24
Duration		hours
The number of hours from the tunable business day start time for long business days.
Short Business Day Start	13:00	hh:mm	00:00 — 24:00
Time	UTC
	daylight
	savings
	time
	14:00
	UTC
	standard
	time
The start of the business day for short business days. The value is specified by the contracting region.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

SUBSCRIPTION TUNABLES

	Default
Tunable Name	Value	Units	Valid Range
Long Business Day Start	9:00AM	hh:mm	00:00 — 24:00
Time	Local
	Time
	(in the
	predomi
	nant
	time
	zone)
	within
	each
	region,
	stored
	in UTC
The start of the business day for long business days in that region. The value is specified by the contracting region
Short Business Days	Monday	Days	Monday –
	- Friday		Sunday
The business days available for Service Providers using short business days.
Long Business Days	Sunday	Days	–Sunday –
	- Saturday		Saturday
The business days available for Service Providers using long business days.
Regional NPAC NPA-	TRUE		True/False
NXX Live Indicator
Tunable that indicates whether or not the NPA-NXX Live TimeStamp functionality will be supported by the NPAC SMS for a particular NPAC Region.
Regional Automatic	TRUE		True/False
Conflict Cause Code
Tunable that indicates whether or not the Automatic Conflict Cause Code functionality will be supported by the NPAC SMS for a particular NPAC Region.
Regional Prevent	TRUE		True/False
Conflict Resolution
50/51 Tunable

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

SUBSCRIPTION TUNABLES

	Default
Tunable Name	Value	Units	Valid Range
Tunable that indicates whether or not the prevention of conflict resolution for cause code 50 or 51 by the New Service Provider is supported by the NPAC SMS for a particular NPAC Region.

Table C- 1 — Subscription Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
Subscription Activation	3	attempts	1-10
Retry Attempts
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	2	minutes	1-60
Retry Interval
The delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request.
Subscription	3	attempts	1-10
Modification Retry
Attempts
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	2	minutes	1-60
Modification Retry
Interval
The delay between sending modified active subscription versions to a Local SMS that has not acknowledged receipt of the modification request.
Subscription Disconnect	3	attempts	1-10
Retry Attempts

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
The number of times the NPAC SMS will resend a subscription disconnect message to an unresponsive Local SMS.
Subscription Disconnect	2	minutes	1-60
Retry Interval
The amount of time that shall elapse between subscription disconnect retries.
Local SMS Retry	3	attempts	1-10
Attempts
The default number of times the NPAC SMS will resend a message to an unresponsive Local SMS.
Local SMS Retry	2	minutes	1-60
Interval
The default delay between sending messages to an unresponsive Local SMS.
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	2	minutes	1-60
The default delay between sending messages to an unresponsive SOA.
Failed Login Attempts	3	attempts	0-10
The number of allowable incorrect logon attempts
Failed Login Shutdown	60	seconds	0-300
Period
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	60	days	1-360

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
The number of days for which a userId has not been used before the NPAC SMS disables that userId.
Password Age Limit	90	days	1-360
The amount of time for password aging.
Password Expiration	7	days	1-30
Notice
The amount of time prior to a password expiring that the NPAC SMS will notify a user.
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	6	months	1-36
The amount of time in which a password cannot be reused.
Record Logons After	10	attempts	0-100
Failure
The threshold for consecutive failed logon attempts after which logon attempts will be recorded in the audit log.
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.
Maximum Number of Download Records	10000	records	1-200000
The maximum number of SV records for a single data download for a TN-based recovery request.
Also, the maximum number of records for a single data download for a network data recovery request.
Refer to the NPAC Customer Data Model, section 3.1.2, for information on the maximum for timestamp-based SV recovery requests.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
Maximum Download	60	minutes	1-1440
Duration
The maximum time range allowed for a data download.
Maximum Number of	2000	records	1-2000
Download Notifications
The maximum number of notifications for a single notification recovery download.
Service Provider and	50	objects	1-2000
Network Data Linked
Replies Blocking Factor
The maximum number of objects in a single service provider or network data recovery linked reply response.
Subscription Data	50	objects	1-2000
Linked Replies Blocking
Factor
The maximum number of objects in a single subscription data recovery linked reply response.
Notification Data Linked	50	notifications	1-2000
Replies Blocking Factor
The maximum number of notifications in a single notifications recovery linked reply response.
Number Pool Block Data	50	Objects	1-2000
Linked Replies Blocking
Factor
The maximum number of objects in a single number pool block data recovery linked reply response.
Service Provider and Network Data Maximum Linked Recovered Objects	10000	objects	1-10000
The maximum number of objects sent in a service provider or network data recovery response, when the SOA/LSMS supports Linked Replies.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
Subscription Data	10000	objects	1-10000
Maximum Linked
Recovered Objects
The maximum number of objects sent in a subscription data recovery response, when the LSMS supports Linked Replies.
Notification Data	2000	notifications	1-10000
Maximum Linked
Recovered Notifications
The maximum number of notifications sent in a notification recovery response, when the SOA/LSMS supports Linked Replies.
Number Pool Block Data	10000	objects	1-10000
Maximum Linked
Recovered Objects
The maximum number of objects sent in a number pool block data recovery response, when the LSMS supports Linked Replies.
SOA SWIM Maximum	50000	objects	10000 — 100000
Tunable
The maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery.
LSMS SWIM Maximum	50000	objects	10000 — 100000
Tunable
The maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery.
Out-Bound Flow	100	Messages	50 — 500
Control Upper
Threshold Tunable
The number of non-responsive messages sent to a SOA/LSMS before Out-Bound Flow Control is invoked.
Out-Bound Flow	75	Messages	1 — 500
Control Lower
Threshold Tunable

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
The number of non-responsive messages sent to a SOA/LSMS that is in a Flow Control state before normal processing is resumed, on a per association basis.
Roll-Up Activity — Single	15	Minutes	1 — 60
Tunable
The number of minutes before roll-up activity is initiated for an event involving a single SV.
Roll-Up Activity Timer	60	Minutes	1 — 60
Expire SVRange
Tunable
The number of minutes before roll-up activity is initiated for an event involving a range of SVs.
Abort Processing	60	Minutes	1 — 180
Behavior Upper
Threshold Tunable
The number of minutes before an NPAC abort will occur for a SOA/LSMS that has at least one outstanding message with a delta between the origination time and the current time that is equal to or greater than the tunable window, regardless of whether the SOA/LSMS has incurred any other activity (request or response).
Regional NPAC NPA	False	Boolean	True/False
Edit Flag Indicator
An indicator as to whether or not NPA edits will be enforced by the NPAC SMS for a particular NPAC region.
NPAC SMS Application	15	Minutes	5 — 60
Level Heartbeat Tunable
Defines the period of quiet time (no interface traffic) the NPAC should wait after the receipt of any interface traffic (request or response), before sending an Application Level Heartbeat message to the SOA/Local SMS.
NPAC SMS Application	1	Minutes	1 — 5
Level Heartbeat
Timeout Tunable

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

COMMUNCIATIONS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
The period of time the NPAC should wait after sending an Application Level Heartbeat message to the SOA/Local SMS, and not receiving a response from the SOA/Local SMS, before aborting the association.

Table C- 2 — Communications Tunables

AUDIT TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
Canceled Audit	30	days	1-360
Retention Period
The length of time canceled audits will be retained.
Data Integrity Sample	1000	SVs	1-5000
Size
The number of active Subscription Versions in a sample to be monitored by the NPAC SMS.
Data Integrity Sample	7	Days	1-90
Frequency
The interval in days between Data Integrity Samples conducted by the NPAC SMS.
Subscription Query	50	Subscriptions	1-5000
Record Limit
The maximum number of records that can be returned from a query.

Table C- 3 — Audit Tunables

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

LOGS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
Local SMS Activation	90	days	1-360
Log Retention Period
The number of days Local SMS activation responses will remain in the log.
Audit Log Retention	90	days	1-360
Period
The length of time audit logs will be retained.
Error Log Retention	90	days	1-360
Period
The length of time system error logs will be retained.
History File Data	365	days	1-365
Storage
The length of time history logs will be retained.
Usage Log Retention	90	days	1-360
The length of time usage logs will be retained.

Table C- 4 — Logs Tunables

KEYS TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
Key Change Interval	365	days	1-365
How often the key is changed automatically.

Table C- 5 — Keys Tunables

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

BLOCK TUNABLES

	Default		Valid
Tunable Name	Value	Units	Range
NPA-NXX Availability – First Usage Effective Date Window	5	days	5-360
The minimum length of time between the Creation date (exclusive) and the effective date/due date (inclusive), when creating a NPA-NXX-X or Subscription Version for the first time within that NPA-NXX.

Table C- 6 — Block Tunables

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

SOA Notification Priority Tunables

Many notifications are sent to both the Old Service Provider and the New Service Provider. As indicated in the table below, some of these notifications can have different priorities based on whether the Service Provider is acting as the Old Service Provider or the New Service Provider for the port. During the notification evaluation process this option was not given to all notifications that are sent to both the Old Service Provider and the New Service Provider for one or more reasons. Some of those reasons were:

• volume of the particular notification was very small

• importance of the particular notification was determined to be equal whether a Service Provider was acting as the Old Service Provider or the New Service Provider for the port

#	Notification Name	Priority
L-1.0	NPAC SMS Operational Information Notification	MEDIUM
L-2.0	Subscription Audit Discrepancy Report	MEDIUM
L-3.0	Subscription Audit Results	MEDIUM
L-4.0	Subscription Version Cancellation Acknowledge Request	MEDIUM
A	Scenario A: the OLD SP is requesting cancellation and no concurrence from New SP.
L-4.0	Subscription Version Cancellation Acknowledge Request	MEDIUM
B	Scenario B: the New SP is requesting cancellation and no concurrence from Old SP.
L-6.0	Subscription Version — Donor SP — Customer Disconnect Date Notification	MEDIUM
L-7.0	Subscription Version Local SMS Action Results	N/A
L-8.0	Subscription Version New NPA-NXX Notification	MEDIUM (to SOA)
L-9.0	Subscription Version New SP Create Request Notification (T1 timer expiration for New SP concurrence)	MEDIUM
L-10.0	Subscription Version Old SP Concurrence Request Notification (T1 timer expiration for Old SP concurrence)	MEDIUM
L-11.0	Subscription Version Status Attribute Value Change Notification – Activates – To the New Service Provider	MEDIUM
A1	When an INTER or INTRA SV has been created in the Local SMSs (or ‘activated‘ by the SOA) and the SV status has been set to: Active or Partial-Failure. The notification is sent to both SOAs: Old and New. If the status has been set to Partial-

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

#	Notification Name	Priority
	Failure, this notification contains the list of Service Providers (SP) LSMSs that have failed to receive the broadcast.
	Note: See L-11.0 E for Deletes and L-11.0 F for Modify Actives
L-11.0	Subscription Version Status Attribute Value Change Notification – Activates – To the Old Service Provider	MEDIUM
A1.5	When an INTER or INTRA SV has been created in the Local SMSs (or ‘activated‘ by the SOA) and the SV status has been set to: Active or Partial-Failure. The notification is sent to both SOAs: Old and New. If the status has been set to Partial-Failure, this notification contains the list of Service Providers (SP) LSMSs that have failed to receive the broadcast.
	Note: See L-11.0 E for Deletes and L-11.0 F for Modify Actives
L-11.0	Subscription Version Status Attribute Value Change Notification – re-sends to fail list – To The New Service Provider	MEDIUM
A2	Intermediate Notification for Partial Failure. Every time a SP is removed from the Failed SP-List, the NPAC re-sends the notification to both SOAs. This iteration happens until the last SP is cleared from the fail-list.
L-11.0	Subscription Version Status Attribute Value Change Notification – re-sends to fail list – To The Old Service Provider	MEDIUM
A2.5	Intermediate Notification for Partial Failure. Every time a SP is removed from the Failed SP-List, the NPAC re-sends the notification to both SOAs. This iteration happens until the last SP is cleared from the fail-list.
L-11.0	Subscription Version Status Attribute Value Change Notification – clear Fail List – To The New Service Provider	MEDIUM
A3	Final Notification associated with a Partial Failure. Upon clearing the Failed SP-List, the NPAC sends the same notification to both SOAs but with an SV status of active and empty fail-list.
L-11.0	Subscription Version Status Attribute Value Change Notification – clear Fail List – To The Old Service Provider	MEDIUM
A3.5	Final Notification associated with a Partial Failure. Upon clearing the Failed SP-List, the NPAC sends the same notification to both SOAs but with an SV status of active and empty fail-list.
L-11.0	Subscription Version Status Attribute Value Change Notification – total failure	MEDIUM
B	When an SV has failed to be created (or ‘activated’) in ALL LSMSs and the SV status has been set to Failed. The notification is sent to both SOAs: Old and New.
L-11.0	DELETED

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

#	Notification Name	Priority
C
L-11.0	Subscription Version Status Attribute Value Change Notification – re-sends	MEDIUM
D1	When the NPAC re-sends Modify Active or Deletes to the LSMSs for SVs with statuses of Active or Old, with a Fail SP List (the notification is sent regardless of the final status of the SV) The notification is sent to the Current (New) SOA.
L-11.0	Subscription Version Status Attribute Value Change Notification – set to OLD	MEDIUM
E	When the SV status has been set to old. (Port to Original, port-of-a port, port to original of a Pool TN (or snap back), disconnect, disconnect of a ported Pool TN). The notification is received only by those SOAs that actually have the SV in their local DB. It varies with the scenario.
	Note: See L-11.0 A1.5 for Activates and L-11.0 F for Modify Actives
L-11.0	Subscription Version Status Attribute Value Change Notification – Modify active	MEDIUM
F	When an Active SV has been modified in the LSMS or there has been a cancellation of a Disconnect-Pending SV and the status of the SV has been re-set to Active (with or without a Fail-SP-List). The notification is sent only to the current SOA.
	Note: See L-11.0 A1 for Activates and L-11.0 E for Deletes
L-11.0	Subscription Version Status Attribute Value Change Notification – cancel pending	MEDIUM
G	When a Pending or Conflict SV has been cancelled by the Old or New SP and the NPAC SMS has set the SV status to Cancel-Pending. Also, when a Cancel-Pending SV is modified back (un-do) to Pending.The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification — cancel	MEDIUM
H1	When the NPAC SMS has set the status of a, cancel-pending, SV to CANCEL after concurrence and cancellation acknowledgment by both SOAs has been received in the NPAC The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification — cancel	MEDIUM
H2	When the NPAC SMS has set the status of a, cancel-pending, SV to CANCEL after the New Service Provider has cancelled the Pending SV but the Old Service Provider has not acknowledged the cancellation by the time the Cancellation Acknowledgement Final Concurrence Timer has expired. The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification — cancel	MEDIUM
H3	When the NPAC SMS has set the status of a pending SV to CANCEL after cancellation request by the originating SOA with no concurrence from the other

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

#	Notification Name	Priority
	SOA. (Only one create action has been received in the NPAC and the same provider sends the cancellation request before the second provider send a create request.) The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification — cancel	MEDIUM
H4	When the NPAC SMS has set the status of a conflict SV to CANCEL after the Conflict Cancellation Window expires, if no resolution has been reached for the conflict, the NPAC automatically cancels the Conflict SV. The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification – Disconnect pending	MEDIUM
I	When an active SV is being disconnected with an Effective Release Date in the NPAC and the SV status is set to Disconnect-Pending. Only the current SOA receives the notification.
L-11.0	Subscription Version Status Attribute Value Change Notification – Fail disconnect	MEDIUM
J	When the NPAC attempts to delete an Active SV and the request fails to ALL LSMSs and the SV status is re-set to Active. Only the Current SOA receives the notification.
L-11.0	Subscription Version Status Attribute Value Change Notification — Conflict	MEDIUM
K1	When the status of a Pending SV is set to conflict. The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification — Conflict	MEDIUM
K2	When the status of a Cancel-Pending SV is set to conflict. Cancel-Pending to Conflict is when the Old Service Provider has cancelled the Pending SV but the New Service Provider has not acknowledged the cancellation by the time the Cancellation Acknowledgement Final Concurrence Timer has expired. The notification is sent to both SOAs: Old and New.
L-11.0	Subscription Version Status Attribute Value Change Notification	MEDIUM
L	After Conflict Resolution, when the status of the Conflict SV is re-set to Pending. The notification is sent to both SOAs: Old and New.
L-12.0	Subscription Version Old SP Final Concurrence Timer Expiration Notification	MEDIUM
	(T2 expiration for Old SP concurrence)
L-13.0	Number Pool Block Status Attribute Value Change Notification	MEDIUM
A	The Pool Block has being created in the LSMSs (EDR and Non_EDR) and the Block Status has being set to Active or Partial Failure;

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

#	Notification Name	Priority
L-13.0	Number Pool Block Status Attribute Value Change Notification	MEDIUM
B	The creation of the Pool Block has failed in all the LSMSs (EDR and Non-EDR) and the Block Status has been set to Failed.
L-13.0	Number Pool Block Status Attribute Value Change Notification	MEDIUM
C	The NPAC attempts to re-send a failed Pool Block or failed SVs to SP in the fail-SP-List of the Block and the Block status changes to Active, Partial Failure or Failure.
L-13.0	Number Pool Block Status Attribute Value Change Notification	MEDIUM
D	The attributes in the Pool Block have been modified in the LSMSs (EDR and Non-EDR) and the Block Status has been re-set to Active (with or without fail-sp-list).
L-13.0	Number Pool Block Status Attribute Value Change Notification	MEDIUM
E	When a Pool Block has been ‘de-pooled’ from the LSMSs (EDR and Non-EDR) and the Block Status has been set to Old (with or without fail-sp-list).
L-13.0	Number Pool Block Status Attribute Value Change Notification	MEDIUM
F	When the NPAC SMS has attempted to ‘de-pool’ a block but the request has failed to ALL LSMSs (EDR and Non-EDR) and the Block Status has been reset to Active with a Failed-SP-list.
L-14.0	Subscription Version New SP Final Create Window Expiration Notification	MEDIUM
	It will be sent after T2 expiration to both SPs SOAs (old and new) to inform them that the T2 timer has expired and the new SP hasn’t send its create request yet. The SV will remain in status of Pending until the New SP sends the Create or the NPAC cancels it.
S-1.00	Object Creation	MEDIUM
S-2.00	Object Deletion	MEDIUM
S-3.00	Attribute Value Change	MEDIUM
A	For pending SVs
S-3.00	Attribute Value Change	MEDIUM
B	For Pool Blocks

Table C- 7 – SOA Notification Priority Tunables

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

System Tunables

Release 3.3: © 1997 — 2006 NeuStar, Inc.	C-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Encryption Key Exchange

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

ENCRYPTION KEY EXCHANGE FILE FORMAT

Field
Number	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	variable1		integer
8	public modulus	Binary	variable2		integer

¹. The size of the public exponent is determined by the previous field of the key data, public exponent size.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	D-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Encryption Key Exchange

Field
Number	Field Name	Type	Size (bytes)		Format
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

Table D- 1 — Encryption Key Exchange File Format

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

Release 3.3: © 1997 — 2006 NeuStar, Inc.	D-2		North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a
Freely distributable subject to the terms of the GNU GPL, see inside cover notice.			March 9, 2006

Encryption Key Exchange     

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.	Verify that the key list has been received by the intended recipient.
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 D-1 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.

ENCRYPTION KEY ACKNOWLEDGEMENT FILE FORMAT

Field
Number	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

Table D- 2 — Encryption Key Acknowledgement File Format

Release 3.3: © 1997 — 2006 NeuStar, Inc.	D-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Encryption Key Exchange     

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.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	D-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

Appendix E. Download File Examples

The NPAC can generate Bulk Data Download files for Network Data (including SPID, LRN, NPA-NXX and NPA-NXX-X), Subscription Versions (including Number Pool Blocks) and Notifications.

All fields within files discussed in the following section are variable length. The download reason in all “Active-like” download files is always set to new. The download reason in all “Latest View” download files is set to the appropriate download reason based on activation/modification/deletion activity. ASCII 13 is the value used as the value for carriage return (CR) in the download files.

All Time Stamps contained within the download files and SMURF files, and file names are in GMT (Greenwich Mean Time). Files that contain three timestamps reference the time the files is created, and start and end time range. When the time range is not specified, the default start timestamp is 00-00-0000000000 and the default end timestamp is 99-99-9999999999.

Subscription Download File

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

If the Bulk Data Download input selection criteria specifies Latest View of Subscription Version Activity, the file will include all subscription versions with a Broadcast Timestamp that falls within a specified time range. If the Bulk Data Download input selection criteria specifies Active/Disconnect Pending/Partial Failure Subscription Versions Only, the file will include subscription versions with a status of Active, Disconnect Pending or Partial Failure or a status of Sending with a download reason of New or Modify that have an Activation timestamp that occurs at or before the time that the BDD request begins to be processed. File data is further narrowed when the input selection criteria includes a TN range. This will result in a file that includes information only on those subscription versions that fall within that TN range.

The file name for the Subscriptions download file will be in the format:

NPANXX-NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSSThe NPANXX-NPANXX values map to the selection criteria. The first timestamp is the time the request begins processing, the second timestamp is the beginning timestamp for the time range and the third timestamp is the ending timestamp for the time range. For active-like views the second and third timestamp will be set by default.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

The Subscriptions file given in the example would be named:

     303123-303125.25-12-1996081122.25-12-1996080000.25-12-1996125959

0001|3031231000|1234567890|0001|19960916152337|

123123123|123|123123123|123|123123123|123|123123123|123|

123456789012|12|0001|0|0(CR)           (end of subscription 1)

0002|3031241000|1234567891|0001|19960825011010|

123123123|123|123123123|123|123123123|123|123123123|123|

123456789013|13|0001|0|0(CR)           (end of subscription 2)

0003|3031251000|1234567892|0001|19960713104923|

123123123|123|123123123|123|123123123|123|123123123|123|

123456789014|13|0001|0|0(CR)           (end of subscription 3)

Figure E- 1 — Subscription Download File Example

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)
6	CLASS DPC	123123123 (This value is 3 octets)
7	CLASS SSN	123 (This value is 1 octet and usually set to 000)
8	LIDB DPC	123123123 (This value is 3 octets)
9	LIDB SSN	123 (This value is 1 octet and usually set to 000)
10	ISVM DPC	123123123 (This value is 3 octets)
11	ISVM SSN	123 (This value is 1 octet and usually set to 000)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE FIELDS IN THE SUBSCRIPTION DOWNLOAD FILE

Field
Number	Field Name	Value in Example
12	CNAM DPC	123123123 (This value is 3 octets)
13	CNAM SSN	123 (This value is 1 octet and usually set to 000)
14	End user Location Value	123456789012
15	End User Location Type	12
16	Billing Id	0001
17	LNP Type	0
18	Download Reason	0
19	WSMSC DPC	Not present if LSMS or SOA does not support the WSMSC DPC as shown in this example. If it were present the value would be in the same format as other DPC data.
20	WSMSC SSN	Not present if LSMS or SOA does not support the WSMSC SSN as shown in this example. If it were present the value would be in the same format as other SSN data.
21	SV Type	Not present if LSMS or SOA does not support the SV Type as shown in this example. If it were present the value would be as defined in the SV Data Model.
22	Alternative SPID	Not present if LSMS or SOA does not support the Alternative SPID as shown in this example. If it were present the value would be as defined in the SV Data Model.

Table E- 1 — Explanation of the Fields in The Subscription 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.

If the Bulk Data Download input selection criteria specifies Latest View of Network Data Activity, the files will include data with a Broadcast Timestamp that falls within the specified time range (NPA-NXX and LRN will use Creation Timestamp for a match and NPA-NXX-X data will use Modified Timestamp for a

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

match). If the Bulk Data Download input selection criteria specifies All Network Data, the files will include a representation of all network data as it exists on the NPAC SMS. All SPID data is included all of the time, regardless of selection criteria.

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 E-2 directly correlates to the values for the Service Provider in the download file example, as seen in Figure E-2.

The file name for the Service Provider download file will be in the format:

          SPID.DD-MM-YYYYHHMMSS (The “SPID” portion is the literal string “SPID”.)

The Service Provider file given in the example would be named:

          SPID.13-10-1996081122

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
3	Service Provider Type	Not present if the Service Provider does not support SP TYPE.

Table E- 2 — Explanation of the Fields in the Network Service Provider Download File

0001|AMERITECH|0(CR)                     (Service Provider Id/Name/SP Type)

Figure E- 2 — Network Service Provider Download File Example, SP Supports SP Type

0001|AMERITECH(CR)                     (Service Provider Id/Name)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

Figure E-2a — Network Service Provider Download File Example, SP Does Not Support SP Type

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

NPA/NXX Download File

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 E-3 directly correlates to the values for the first NPA/NXX in the download file example, as seen in Figure E-3.

The file name for the NPA-NXX download file will be in the format:

     NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The NPANXX portion is the literal string “NPANXX”.)

The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively. In the case of the All Network Data view, the second and third time stamps are set by default as no time range may be set by the user for this view.

The NPA-NXX file given in the example would be named:

     NPANXX.13-10-1996081122.12-10-1998080000.13-10-1998133022

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	303123
4	Creation TimeStamp	19960101155555
5	Effective TimeStamp	19960105000000
6	Download Reason	0

Table E- 3 — Explanation of the Fields in the Network NPA/NXX Download File

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

          0001|2853|303-123|19960101155555|19960105000000|0(CR)(NPA-NXX 1)

          0001|2864|303-124|19960101155556|19960105000000|0(CR)(NPA-NXX 2)

          0001|2870|303-125|19960101155557|19960105000000|0(CR)          (NPA-NXX 3)

Figure E- 3 — Network NPA-NXX Download File Example

LRN Download File

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 E-4 directly correlates to the values for the first LRN in the download file example, as seen in Figure E-4.

The file name for the LRN download file will be in the format:

     LRN.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The LRN portion is the literal string “LRN”.)

The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively. In the case of the All Network Data view, the second and third time stamps are set by default as no time range may be set by the user for this view.

The LRN file given in the example would be named:

LRN.13-10-1996081122.12-10-1998080000.13-10-1998133022

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

Table E- 4 — Explanation of the Fields in the Network LRN Download File

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

          0001|1624|1234567890|19960101155559|0(CR)              (LRN 1)

          0001|1633|1234567891|1996010115570010|0(CR)          (LRN 2)

          0001|1650|1234567892|1996010115580505|0(CR)          (LRN 3)

Figure E- 4 — Network LRN Download File Example

NPA-NXX-X Download File

The following table describes the sample NPA-NXX-X download file which contains two records in the file, individual fields are pipe delimited, with a carriage return ( CR ) after each NPA-NXX-X 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 E-5 directly correlates to the values for the first NPA-NXX-X in the download file example, as seen in Figure E-5.

The file name for the NPA-NXX-X download file will be in the format:

     NPANXXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The NPANXXX portion is the literal string “NPANXXX”, and the timestamp maps to the current time [GMT].)

The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively. In the case of the All Network Data view, the second and third time stamps are set by default as no time range may be set by the user for this view.

The NPA-NXX-X file given in the example would be named:

     NPANXXX.02-11-1998133022.12-10-1998080000.13-10-1998133022

EXPLANATION OF THE FIELDS IN THE NETWORK NPA-NXX-X DOWNLOAD FILE

Field
Number	Field Name	Value in Example
1	Service Provider Id	0001
2	NPA-NXX-X Id	2853
3	NPA-NXX-X Value	303-123-6

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE FIELDS IN THE NETWORK NPA-NXX-X DOWNLOAD FILE

Field
Number	Field Name	Value in Example
4	Creation TimeStamp	19980101155555
5	Effective TimeStamp	19980105000000
6	Modified TimeStamp	19980105001111
7	Download Reason	0

Table E- 5 — Explanation of the Fields in the Network NPA-NXX-X Download File

           0001|2853|303-123-6|19980101155555|19980105000000|19980105001111|0(CR)          (NPA-NXX-X 1)

           0001|2864|303-124-4|19980101155556|19980105000000|19980105001111|0(CR)          (NPA-NXX-X 2)

Figure E- 5 — Network NPA-NXX-X Download File Example

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

Block Download File

The following table describes each field of the sample Block download file. This download file example contains data for three Blocks, with three lines for each Block. Each Block is one record in the file, pipe delimited, with a carriage return( CR ) between each Block. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.

Table E-6 describes the entries for Block 1: The “Value in Example” column directly correlates to the values for Block 1 in the download file example, as seen in Figure E-6.

Blocks in the download file are selected by a combination of NPA-NXX-X begin and end, as well as TIME begin and end range. The TIME Range is keyed off the Broadcast Timestamp. The file name for the Block download file will be in the format:

NPANXXX-NPANXXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS

The NPANXXX-NPANXXX values map to the NPA-NXX-X selection criteria, the first stamp maps to the current time (when the file is generated), the second time stamp maps to the begin time range, and the third time stamp maps to the end time range. All three time stamps are represented in GMT.

The Block file given in the example would be named:

     3031235-3031252.17-09-1996153344.11-07-1996091222.17-09-1996153344

The files available for LSMS compares will be defined as one or more NPA-NXX-Xs per file.

          1|3031231|1234567890|0001|19960916152337|123123123|123|123123123|

          123|123123123|123|123123123|123|||0(CR)          (end of Block 1)

          2|3031241|1234567891|0001|19960825011010|123123123|123|123123123|

          123|123123123|123|123123123|123|||0(CR)          (end of Block 2)

          3|3031251|1234567892|0001|19960713104923|123123123|123|123123123|

          123|123123123|123|123123123|123|||0(CR)          (end of Block 3)

Figure E- 6 — Block Download File Example

EXPLANATION OF THE FIELDS IN THE BLOCK DOWNLOAD FILE

Field
Number	Field Name	Value in Example
1	Block Id	1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE FIELDS IN THE BLOCK DOWNLOAD FILE

Field
Number	Field Name	Value in Example
2	NPA-NXX-X	3031231
3	LRN	1234567890
4	New Current Service Provider Id	0001
5	Activation Timestamp	19960916152337 (yyyymmddhhmmss)
6	CLASS DPC	123123123 (This value is 3 octets)
7	CLASS SSN	123 (This value is 1 octet and usually set to 000)
8	LIDB DPC	123123123 (This value is 3 octets)
9	LIDB SSN	123 (This value is 1 octet and usually set to 000)
10	ISVM DPC	123123123 (This value is 3 octets)
11	ISVM SSN	123 (This value is 1 octet and usually set to 000)
12	CNAM DPC	123123123 (This value is 3 octets)
13	CNAM SSN	123 (This value is 1 octet and usually set to 000)
14	WSMSC DPC	Not present if LSMS or SOA does not support the
		WSMSC DPC as shown in this example. If it were
		present the value would be in the same format as
		other DPC data.
15	WSMSC SSN	Not present if LSMS or SOA does not support the
		WSMSC SSN as shown in this example. If it were
		present the value would be in the same format as
		other SSN data.
16	Download Reason	0
17	SV Type	Not present if LSMS or SOA does not support the
		SV Type as shown in this example. If it were
		present the value would be as defined in the SV
		Data Model.
18	Alternative SPID	Not present if LSMS or SOA does not support the
		Alternative SPID as shown in this example. If ti
		were present the value would be as defined in the
		SV Data Model.

Table E- 6 — Explanation of the Fields in The Block Download File

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

Notifications Download File

The Notification download file contains records for notifications as they are defined in the IIS. Each record contains required and optional attributes and data is logged at the time of notification generation based on the reason the notification was generated as well as NPAC Customer profile settings. The inclusion of TN/TN Range/NPA-NXX-X in respective notifications is not dependent on the NPAC Customer settings for Subscription Version TN Attribute Flag and Number Pool Block NPA-NXX-X Attribute Flag indicators.

The Notifications download file example (Figure E- 8 — Notification Download File Example, below) contains two records in the file, individual fields are pipe delimited, with a carriage return( CR ) after each Notification 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 E-7 directly correlates to the values for the hypothetical Notification in the download file example, as seen in Figure E-8.

The file name for the Notifications download file will be in the format:

     Notifications.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The Notifications portion is the literal string “ Notifications”.)

The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively.

The Notifications file given in the example would be named:

     Notifications.15-10-2004081122.12-10-2004080000.13-10-2004133022

In the download file each notification can be identified by the combination of the Notification ID and Object ID fields. LNP specific notifications are defined with a unique Notification ID in the GDMO however some notifications sent across the interface are CMIP primitives and do not have unique Notification IDs. In order to uniquely identify these notifications in the download file, the original CMIP primitive Notification ID has been augmented with a 1000-series number to create a unique Notification ID/Object ID combination. For example, the subscriptionVersionNPAC-ObjectCreation notification is a CMIP primitive notification that uses a Notification ID of (6) and Object ID of (21) across the interface. At the same time the LNP specific notification, subscriptionVersionDonorSP-CustomerDisconnectDate as defined in the GDMO uses the same Notification ID and Object ID. In order to uniquely identify the subscriptionVersionNPAC-ObjectCreation notification for the download file we have augmented the Notification ID to a 1000-series number of, (1006). The Object ID remains the same (21). The affected notifications are:

• SubscriptionVersionNPAC-ObjectCreation (Notification ID 1006, Object ID 21)

• SubscriptionVersionNPAC-attributeValueChange (Notification ID 1001, Object ID 21)

• SubscriptionAudit-objectCreation (Notification ID 1006, Object ID 19)

• Subscription Audit-objectDeletion (Notification ID 1007, Object ID 19)

• NumberPoolBlock-objectCreation (Notification ID 1006, Object ID 30)

• NumberPoolBlock-attributeValueChange (Notification ID 1001, Object ID 30)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF FIELDS IN A HYPOTHETICAL NOTIFICATIONS DOWNLOAD FILE

Field
Number	Field Name	Value in Example
1	Creation TimeStamp	The time the notification was created.
		For example: 19960101155555
2	Service Provider Id	1111
3	System Type (SOA=0, LSMS=1)	0
4	Notification ID	1
5	Object ID	18
6	WSMSC DPC	Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported WSMSC DPC at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support the WSMSC DPC at the time of notification generation as shown in this example. If it were present the value would be in the same format as other DPC data (for example, 123123123 (This value is 3 octets)).
		Value in example:
7	WSMSC SSN	Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported WSMSC SSN at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support the WSMSC SSN at the time of notification generation as shown in this example. If it were present the value would be in the same format as other SSN data (for example, 123 (This value is 1 octet and usually set to 000)).
		Value in example:
8	Subscription Timer Type	Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported Timer Type at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support Timer Type at the time of notification generation. (1) for Short or (0) for Long.
		Value in example: 1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF FIELDS IN A HYPOTHETICAL NOTIFICATIONS DOWNLOAD FILE

Field
Number	Field Name	Value in Example
9	Subscription Business Type	Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported Business Type at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support Business Type at the time of notification generation. (0) for Short or (1) for Long.
		Value in example: 0
10	Range Type (consecutive list=1, non-consecutive list =2)	1
		NOTE: This field is only present in range notifications and included here for field definition and illustration purposes only.
11	Attribute 1	1234
12	Attribute 2	303123
13	Attribute 3	20040915000000
14	Attribute 4	0
15	Attribute 5	20040831173545
N	Attribute n

Table E- 7 — Explanation of the Fields in the Notifications Download File

          19960101155555|1111|0|1|18|||1|0|1|1234|303123|20040915000000|0|20040831173545(CR) (Notification 1)

          19960101155555|1111|0|1|18|||1|0|1|1235|303242|20040915000000|0|20040831173549(CR) (Notification 2)

Figure E- 8 — Notification Download File Example

The format for each potential notification type is provided in the following table.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
SOA Notifications
subscriptionVersionCancellationAcknowledgeRequest
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	4
5	Object ID	21
6	Version TN	3031231000
7	Version ID	1234567899
subscriptionVersionRangeCancellationAcknowledgeRequest (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	18
5	Object ID	14
6	Range Type Format	1
7	Starting Version TN	3031231000
8	Ending Version TN	3031232000
9	Starting Version ID	1200000001
10	Ending Version ID	1200001002
subscriptionVersionRangeCancellationAcknowledgeRequest (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	18
5	Object ID	14
6	Range Type Format	2
7	Starting Version TN	3031231000
8	Ending Version TN	3031231009
9	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 10).
10	Version ID	1230000001
11	Version ID	1230000004
12	Version ID	1230000006
13	. . . Version ID “n”	1230000009
subscriptionVersionDonorSP-CustomerDisconnectDate
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	6
5	Object ID	21
6	Customer Disconnect Date	20050530230000
7	Effective Release Date	20050530230000
8	Version TN	3031231000

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
9	Version ID	1234567899
subscriptionVersionRangeDonorSP-CustomerDisconnectDate (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	17
5	Object ID	14
6	Customer Disconnect Date	20050530230000
7	Effective Release Date	20050530230000
8	Range Type Format	1
9	Starting Version TN	3032201000
10	Ending Version TN	3032201009
11	Starting Version ID	1234000000
12	Ending Version ID	1234000008
subscriptionVersionRangeDonorSP-CustomerDisconnectDate (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	17
5	Object ID	14

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
6	Customer Disconnect Date	20050530230000
7	Effective Release Date	20050530230000
8	Range Type Format	2
9	Starting Version TN	1232201000
10	Ending Version TN	1232201010
11	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 11).
12	Version ID	1234000099
13	Version ID	1234000103
14	... Version ID “n”	1234000119
subscriptionVersionNewSP-CreateRequest
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	9
5	Object ID	21
6	Old Service Provider ID	1003
7	Old Service Provider Due Date	20050530230000
8	Old Service Provider Authorization	0
9	Old Service Provider Authorization Time Stamp	20050520125032
10	Subscription Status Change Cause Code	50

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
11	Subscription Timer Type	0
12	Subscription Business Type	1
13	Version TN	1232201999
14	Version ID	1234000099
subscriptionVersionRangeNewSP-CreateRequest (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	19
5	Object ID	14
6	Old Service Provider ID	0002
7	Old Service Provider Due Date	20050530230000
8	Old Service Provider Authorization	0
9	Service Provider Authorization Time Stamp	20050520123045
10	Subscription Status Change Cause Code	50
11	Subscription Timer Type	0
12	Subscription Business Type	1
13	Range Type Format	1
14	Starting Version TN	3032201999
15	Ending Version TN	3032202012
16	Starting Version ID	1234000000

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
17	Ending Version ID	1234000013
subscriptionVersionRangeNewSP-CreateRequest (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	19
5	Object ID	14
6	Old Service Provider ID	0234
7	Old Service Provider Due Date	20050530230000
8	Old Service Provider Authorization	0
9	Service Provider Authorization Time Stamp	200505220231632
10	Subscription Status Change Cause Code	50
11	Subscription Timer Type	0
12	Subscription Business Type	1
13	Range Type Format	2
14	Starting Version TN	3033301600
15	Ending Version TN	3033301699
16	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 100).
17	Version ID	2340000000
18	Version ID	2340000016

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
19	... Version ID “n”	2340000023
subscriptionVersionOldSP-ConcurrenceRequest
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	10
5	Object ID	21
6	New Current Service Provider ID	2003
7	Service Provider Due Date	20050530230000
8	New Service Provider Creation Time Stamp	20050518231625
9	Subscription Timer Type	0
10	Subscription Business Type	1
11	Version TN	3033301000
12	Version ID	1234560000
subscriptionVersionRangeOldSP-ConcurrenceRequest (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	20
5	Object ID	14

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
6	New Current Service Provider ID	2003
7	Service Provider Due Date	20050530230000
8	New Service Provider Creation Time Stamp	20050518231625
9	Subscription Timer Type	0
10	Subscription Business Type	1
11	Range Type Format	1
12	Starting Version TN	3033301000
13	Ending Version TN	3033301009
14	Starting Version ID	1000000001
15	Ending Version ID	1000000010
subscriptionVersionRangeOldSP-ConcurrenceRequest (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	20
5	Object ID	14
6	New Current Service Provider ID	2003
7	Service Provider Due Date	20050530230000
8	New Service Provider Creation Time Stamp	20050518231625
9	Subscription Timer Type	0
10	Subscription Business Type	1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
11	Range Type Format	2
12	Starting Version TN	3033300000
13	Ending Version TN	3033300099
14	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 100).
15	Version ID	1000000001
16	Version ID	1000000009
17	... Version ID “n”	1000001011
subscriptionVersionStatusAttributeValueChange
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	11
5	Object ID	21
6	Subscription Version Status	1
7	Subscription Version Status Change Cause Code	0
8	Version TN	3033301290
9	Version ID	1234500009
10	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 3).
		Note: If there aren’t any Service Providers on the Failed list then the last field will be the VersionID.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
11	(failed list) Service Provider ID - - Service Provider Name	2003-TelCo
12	(failed list) Service Provider ID - - Service Provider Name	2910-Tel S
13	...	1034-Tel M
subscriptionVersionRangeStatusAttributeValueChange (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1001
3	System Type	0
4	Notification ID	14
5	Object ID	14
6	Subscription Version Status	1
7	Subscription Version Status Change Cause Code	0
8	Range Type Format	1
9	Starting Version TN	3034401000
10	Ending Version TN	3034401001
11	Starting Version ID	4420000097
12	Ending Version ID	4420000098
13	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 2).
		Note: If there aren’t any Service Providers on the Failed list then the last field will be the Ending VersionID.
14	(failed list) Service Provider ID - - Service Provider Name	2003-TelCo

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
15	(failed list) Service Provider ID - - Service Provider Name	2910-Tel S
subscriptionVersionRangeStatusAttributeValueChange (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1001
3	System Type	0
4	Notification ID	14
5	Object ID	14
6	Subscription Version Status	1
7	Subscription Version Status Change Cause Code	0
8	Range Type Format	2
9	Starting Version TN	3034401012
10	Ending Version TN	3034401019
11	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 8).
12	Version ID	1000050090
13	Version ID	1000050096
14	Version ID	1000050099
15	... Version ID “n”	1000005100
16	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 3).
		Note: If there aren’t any Service Providers on the Failed list then the last field will be the VersionID “n”.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-25	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
17	(failed list) Service Provider ID - - Service Provider Name	2003-TelCo
18	(failed list) Service Provider ID - - Service Provider Name	2910-Tel S
19	...	1034-Tel M
subscriptionVersionNPAC-ObjectCreation
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1001
3	System Type	0
4	Notification ID	1006
5	Object ID	21
6	New Service Provider Creation Time Stamp	20050518231625
7	New Service Provider Due Date	20050530230000
8	Old Service Provider Authorization Time Stamp
9	Old Service Provider Due Date
10	Old Service Provider Authorization
11	New Current Service Provider ID	1001
12	Old Service Provider ID	1003

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-26	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
13	Conflict Time Stamp
14	Status Change Cause Code
15	Subscription Version Status	1
16	Version TN	3034401000
17	Version ID	1239999909
subscriptionVersionRangeObjectCreation (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	16
5	Object ID	14
6	New Service Provider Creation Time Stamp	20050518231625
7	New Service Provider Due Date	20050530230000
8	Old Service Provider Authorization Time Stamp
9	Old Service Provider Due Date

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-27	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
10	Old Service Provider Authorization
11	New Current Service Provider ID	0001
12	Old Service Provider ID	1003
13	Conflict Time Stamp
14	Status Change Cause Code
15	Subscription Version Status	1
16	Range Type Format	1
17	Starting Version TN	3034401000
18	Ending Version TN	3034402000
19	Starting Version ID	1234500001
20	Ending Version ID	1234501002
subscriptionVersionRangeObjectCreation (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	16
5	Object ID	14
6	New Service Provider Creation Time Stamp	20050518231625

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-28	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
7	New Service Provider Due Date	20050530230000
8	Old Service Provider Authorization Time Stamp
9	Old Service Provider Due Date
10	Old Service Provider Authorization
11	New Current Service Provider	0001
12	Old Service Provider ID	1003
13	Conflict Time Stamp
14	Status Change Cause Code
15	Subscription Version Status	1
16	Range Type Format	2
17	Starting Version TN	3034401000
18	Ending Version TN	3034401097
19	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 98).
20	Version ID	2050505050
21	Version ID	2050505059

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-29	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS
DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
22	... Version ID “n”	2050507019
subscriptionVersionNPAC-attributeValueChange
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	1001
5	Object ID	21
6	New Service Provider Creation Time Stamp	20050518231625
7	New Service Provider Due Date	20050530230000
8	Old Service Provider Authorization Time Stamp
9	Old Service Provider Due Date
10	Old Service Provider Authorization
11	Conflict Time Stamp
12	Version TN	3034401000
13	Version ID	1234567890
subscriptionVersionRangeAttributeValueChange (* if a consecutive list)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-30	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	15
5	Object ID	14
6	New Service Provider Creation Time Stamp	20050518231625
7	New Service Provider Due Date	20050530230000
8	Old Service Provider Authorization Time Stamp
9	Old Service Provider Due Date
10	Old Service Provider Authorization
11	Conflict Time Stamp
12	Range Type Format	1
13	Starting Version TN	3034401000
14	Ending Version TN	3034401009
15	Starting Version ID	1000000000
16	Ending Version ID	1000000009

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-31	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
subscriptionVersionRangeAttributeValueChange (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	15
5	Object ID	14
6	New Service Provider Creation Time Stamp	20050518231625
7	New Service Provider Due Date	20050530230000
8	Old Service Provider Authorization Time Stamp
9	Old Service Provider Due Date
10	Old Service Provider Authorization
11	Conflict Time Stamp
12	Range Type Format	2
13	Starting Version TN	3034401000
14	Ending Version TN	3034401009

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-32	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
15	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 10).
16	Version ID	1000000000
17	Version ID	1000000013
18	... Version ID “n”	1000000016
subscriptionAudit-DiscrepancyRpt
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	2
5	Object ID	19
6	Service Provider ID	0001
7	Audit Failure Reason	2
8	Audit Discrepancy TN	3034401212
9	Version ID	1000000009
subscriptionAuditResults
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	3
5	Object ID	19
6	Audit Results Status	2

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-33	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
7	Number of Discrepancies	1
8	Time of Completion	20050521121419
9	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 3)
		Note: If there aren’t any Service Providers on the Failed list then the last field will be Time of Completion.
10	Failed Service Provider ID – Failed Service Provider Name	2091-TelX
11	Failed Service Provider ID – Failed Service Provider Name	3124-TelN
12	Failed Service Provider ID – Failed Service Provider Name	3092-TelY
subscriptionAudit-objectCreation
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	1006
5	Object ID	19
6	Audit ID	5303
subscription Audit-objectDeletion
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	1007

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-34	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
5	Object ID	19
6	Audit ID	5049
lnpNPAC-SMS-Operational-Information
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	1
5	Object ID	12
6	Maintenance Start Time	20050530020000
7	Maintenance End Time	20050530060000
8	NPAC Contact Number	8883321000
9	Additional Downtime Information	(graphic string 255)
subscriptionVersionNewNPA-NXX
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	8
5	Object ID	(21/12)
		* If this notification is generated by a subscription, then object ID= 21. If this notification is generated by a number pool block, then object ID=12.
6	NPA-NXX ID	2853
7	NPA-NXX	303440

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-35	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
8	NPA-NXX Effective Time Stamp	19960101155555
9	Service Provider ID	1003
subscriptionVersionOldSPFinalConcurrenceWindowExpiration
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0
4	Notification ID	12
5	Object ID	21
6	Subscription Timer Type	0
7	Subscription Business Type	1
8	Version TN	3034401000
9	Version ID	1234567890
subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	21
5	Object ID	14
6	Subscription Timer Type	0
7	Subscription Business Type	1
8	Range Type Format	1
9	Starting Version TN	3034401000

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-36	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
10	Ending Version TN	3034401009
11	Starting Version ID	1234567000
12	Ending Version ID	1234567010
subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	21
5	Object ID	14
6	Subscription Timer Type	0
7	Subscription Business Type	1
8	Range Type Format	2
9	Starting Version TN	3034401000
10	Ending Version TN	3034401009
11	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 10).
12	Version ID	1230000000
13	Version ID	1230000012
14	Version ID	1230000019
15	... Version ID “n”	1230000024
numberPoolBlock-objectCreation
1	Creation TimeStamp	For example: 19960101155555

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-37	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	1006
5	Object ID	30
6	Number Pool Block Creation Time Stamp	20050501122000
7	Number Pool Block ID	4421
8	Number Pool Block NPA-NXX-X	3033005
9	Block Holder SPID	0001
10	SOA Origination	1
11	LRN	7193000000
12	CLASS DPC	123123123 (This value is 3 octets)
13	CLASS SSN	123 (This value is 1 octet and usually set to 000)
14	LIDB DPC	123123123 (This value is 3 octets)
15	LIDB SSN	123 (This value is 1 octet and usually set to 000)
16	CNAM DPC	123123123 (This value is 3 octets)
17	CNAM SSN	123 (This value is 1 octet and usually set to 000)
18	ISVM DPC	123123123 (This value is 3 octets)
19	ISVM SSN	123 (This value is 1 octet and usually set to 000)
20	WSMSC DPC	123123123 (This value is 3 octets)
21	WSMSC SSN	123 (This value is 1 octet and usually set to 000)
22	Number Pool Block Status	1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-38	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
numberPoolBlock-attributeValueChange
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	1001
5	Object ID	30
6	Number Pool Block ID	1290
7	Number Pool Block NPA-NXX-X	3033006
8	SOA Origination	1
9	LRN	7193000000
10	CLASS DPC	123123123 (This value is 3 octets)
11	CLASS SSN	123 (This value is 1 octet and usually set to 000)
12	LIDB DPC	123123123 (This value is 3 octets)
13	LIDB SSN	123 (This value is 1 octet and usually set to 000)
14	CNAM DPC	123123123 (This value is 3 octets)
15	CNAM SSN	123 (This value is 1 octet and usually set to 000)
6	ISVM DPC	123123123 (This value is 3 octets)
17	ISVM SSN	123 (This value is 1 octet and usually set to 000)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-39	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
18	WSMSC DPC	123123123 (This value is 3 octets)
19	WSMSC SSN	123 (This value is 1 octet and usually set to 000)
numberPoolBlockStatusAttributeValueChange
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	13
5	Object ID	30
6	Number Pool Block ID	3240
7	Number Pool Block NPA-NXX-X	3033006
8	Block Status	4
9	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 3).
		Note: If there aren’t any Service Providers on the Failed list then the last field will be the Block Status.
10	(failed list) Service Provider ID — Service Provider Name	2003-TelCo
11	(failed list) Service Provider ID — Service Provider Name	2910-Tel S
12	...	1034-Tel M
subscriptionVersionNewSP-FinalCreateWindowExpiration
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-40	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
3	System Type	0
4	Notification ID	23
5	Object ID	21
6	New Current Service Provider ID	1234
7	Old Service Provider ID	2001
8	Old Service Provider Due Date	20050530230000
9	Old SP Authorization	0
10	Old SP Authorization Time Stamp	20050520125032
11	Status Change Cause Code	50
12	Subscription Timer Type	0
13	Subscription Business Type	1
14	Version TN	1232201999
15	Version ID	1234567890
subscriptionVersionRangeNewSP-FinalCreateWindow (* if a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	22
5	Object ID	14
6	New Current Service Provider ID	1234
7	Old Service Provider ID	2001
8	Old Service Provider Due Date	20050530230000

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-41	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
9	Old Service Provider Authorization	0
10	Old Service Provider Authorization Time Stamp	20050520123045
11	Status Change Cause Code	50
12	Subscription Timer Type	0
13	Subscription Business Type	1
14	Range Type Format	1
15	Starting Version TN	3034401000
16	Ending Version TN	3034401009
17	Starting Version ID	1234567000
18	Ending Version ID	1234567010
subscriptionVersionRangeNewSP-FinalCreateWindowExpiration (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	22
5	Object ID	14
6	New Current Service Provider ID	1234
7	Old Service Provider ID	2001
8	Old Service Provider Due Date	20050530230000
9	Old Service Provider Authorization	0
10	Old Service Provider Authorization TimeStamp	20050530231632

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-42	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
11	Status Change Cause Code	50
12	Subscription Timer Type	0
13	Subscription Business Type	1
14	Range Type Format	2
15	Starting Version TN	3034401000
16	Ending Version TN	3034401009
17	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 10).
18	Version ID	2340000000
19	Version ID	2340000016
20	... Version ID “n”	2340000023
LSMS Notifications
lnpNPAC-SMS-Operational-Information
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	1
4	Notification ID	1
5	Object ID	12
6	Maintenance Start Time	20050530020000
7	Maintenance End Time	20050530060000
8	NPAC Contact Number	8883321000
9	Additional Download Time Information	(graphic string 255)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-43	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
subscriptionVersionNewNPA-NXX
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	1
4	Notification ID	8
5	Object ID	(21/12) (If this notification is generated by a subscription version, then Object ID=21. If this notification is generated by a pooled block, then Object ID=12.
6	NPA-NXX ID	1239
7	NPA-NXX	303400
8	NPA-NXX Effective Time Stamp	050501120019
9	Service Provider ID	0001

Figure E- 8 — Notification Download File Example

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-44	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

SIC-SMURF NPA-NXX Download File

The SIC-SMURF NPA-NXX download file is used as input to the SPID migration update process in the NPAC SMS and all SOAs/LSMSs, to convert NPA-NXX data from the Old SPID to the New SPID. This file contains individual fields that are pipe delimited, with a carriage return (CR) after each SIC-SMURF NPA-NXX record.

The file name for the SIC-SMURF NPA-NXX download file will be in the format:

     SIC-SMURF-NPANXX.OldSPID.NewSPID.DD-MM-YYYYHHMMSS (The SIC-SMURF-NPANXX portion is the literal string “SIC-SMURF-NPANXX”. The OldSPID is the four digit ID of the Old Service Provider. The NewSPID is the four digit ID of the New Service Provider.)

The SIC-SMURF NPA-NXX file given in the example would be named:

     SIC-SMURF-NPANXX.0001.0002.25-12-1996081122

EXPLANATION OF THE FIELDS IN THE SIC-SMURF NPA-NXX DOWNLOAD FILE

Field
Number	Field Name	Value in Example
1	Old Service Provider Id	0001
2	New Service Provider Id	0002
3	NPA-NXX Value	312382

Example File:

                              0001|0002|312382(CR)                     (end of NPA-NXX 1)

                              0001|0002|312383(CR)                     (end of NPA-NXX 2)

                              0001|0002|312386(CR)                     (end of NPA-NXX 3)

                              0001|0002|312382(CR)                     (end of NPA-NXX 4)

                              0001|0002|312392(CR)                     (end of NPA-NXX 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-45	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

SIC-SMURF LRN Download File

The SIC-SMURF LRN download file is used as input to the SPID migration update process in the NPAC SMS and all SOAs/LSMSs, to convert LRN, Block (SOA/LSMS optional), Subscription Version, and scheduled event for Block (NPAC only) data from the Old SPID to the New SPID. This file contains individual fields that are pipe delimited, with a carriage return (CR) after each SIC-SMURF LRN record.

The file name for the SIC-SMURF LRN download file will be in the format:

     SIC-SMURF-LRN.OldSPID.NewSPID.DD-MM-YYYYHHMMSS (The SIC-SMURF-LRN portion is the literal string “SIC-SMURF-LRN”. The OldSPID is the four digit ID of the Old Service Provider. The NewSPID is the four digit ID of the New Service Provider.)

The SIC-SMURF-LRN file given in the example would be named:

     SIC-SMURF-LRN.0001.0002.25-12-1996081122

EXPLANATION OF THE FIELDS IN THE SIC-SMURF LRN DOWNLOAD FILE

Field
Number	Field Name	Value in Example
1	Old Service Provider Id	0001
2	New Service Provider Id	0002
3	LRN Value	3123820000

Example File:

                              0001|0002|3123820000 (CR)                      (end of LRN 1)

                              0001|0002|3123830000 (CR)                      (end of LRN 2)

                              0001|0002|3123860000 (CR)                      (end of LRN 3)

                              0001|0002|3123820000 (CR)                      (end of LRN 4)

                              0001|0002|3123920000 (CR)                      (end of LRN 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-46	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Download File Examples     

SIC-SMURF NPA-NXX-X Download File

The SIC-SMURF NPA-NXX-X download file is used as input to the SPID migration update process in the NPAC SMS and all SOAs/LSMSs, to convert NPA-NXX-X data (SOA/LSMS optional) from the Old SPID to the New SPID. This file contains individual fields that are pipe delimited, with a carriage return (CR) after each SIC-SMURF NPA-NXX-X record.

The file name for the SIC-SMURF NPA-NXX-X download file will be in the format:

     SIC-SMURF-NPANXXX.OldSPID.NewSPID.DD-MM-YYYYHHMMSS (The SIC-SMURF-NPANXXX portion is the literal string “SIC-SMURF-NPANXXX”. The OldSPID is the four digit ID of the Old Service Provider. The NewSPID is the four digit ID of the New Service Provider.)

The SIC-SMURF-NPA-NXX-X file given in the example would be named:

     SIC-SMURF-NPANXXX.0001.0002.25-12-1996081122

EXPLANATION OF THE FIELDS IN THE SIC-SMURF NPA-NXX-X DOWNLOAD FILE

Field
Number	Field Name	Value in Example
1	Old Service Provider Id	0001
2	New Service Provider Id	0002
3	NPA-NXX-X Value	3123820

Example File:

                              0001|0002|3123820(CR)                     (end of NPA-NXX-X 1)

                              0001|0002|3123824(CR)                     (end of NPA-NXX-X 2)

                              0001|0002|3123862(CR)                     (end of NPA-NXX-X 3)

                              0001|0002|3123868(CR)                      (end of NPA-NXX-X 4)

                              0001|0002|3123928(CR)                      (end of NPA-NXX-X 5)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	E-47	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Midwest Region Number Pooling     

Appendix F. Midwest Region

                        Number Pooling

This section, Appendix F: Midwest Region Number Pooling is deleted in version 3.0.0 of this document with NPAC Release 3.0.0.

Release 3.3: © 1997 — 2006 NeuStar, Inc.	F-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

Appendix G. Deleted Requirements

This section contains a list of assumption/constraint/requirement numbers that have been deleted over the lifetime of this document.

AR5-1 (Duplicates R5-25)
AR4-1.1
AR6-1
AR6-2
A10-1
A10-2
A10-3
A11-1
CN1-1
R3-l
R3-2
RX3-2
R3-4.1 (Duplicate — refer to R4-1)
R3-4.2 (Duplicate — refer to R4-3)
R3-5 (Duplicate — refer to R4-2)
RR3-11 (Replaced with RR3-229, RR3-230, RR3-231, and RR3-232)
RR3-30 (Replaced with RR3-233, RR3-234, RR3-235, and RR3-236)
R3-6.1 (Duplicate – refer to R3-7.2)
R3-12 (Duplicate – refer to R5-18)
RN3-4.10
RN3-4.3
RN3-4.36
RN3-4.37
RN 3-4.4
RN3-4.5
RN3-4.19
RN 3-4.29
RN3-4.33
RN3-4.34
RN3-4.35
RR3-51.1

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

RR3-51.2
RR3-64
RR3-90
RR3-91
RR3-92
RR3-98
RR3-99
RR3-100
RR3-141.2
RR3-167
RR3-168
RR3-178
RR3-179
RR3-208 (Merged into R3-7.1)
RR3-209 (Merged into R3-7.1)
RR3-226
RR3-470
RR3-471
R4-12 (Duplicate – refer to R4-2)
R4-18.1
R4-18.2
R4-18.3
R4-19 (Duplicate – refer to R4-3)
R4-23 (Duplicate – refer to R4-5.2)
R4-30.3
R4-30.4
R4-30.5
R4-30.7
R5-1.2 – (Duplicate refer to R5-20.3, R5-30.2, R5-53), R5-54, moved refer to R5-54.2)
R5-3.7
R5-3.8
R5-3.9
R5-4 (Duplicate – refer to RN5-1)
RR5-6.3
R5-8.2 (Duplicate – refer to R5-25)
RN5-9

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

RR5-10.4
RR5-10.5
RN5-11 (Duplicate – refer to R5-42 and R5-43)
RR5-12.2
RR5-13.1
RR5-13.2
RR5-15.1
RR5-15.2
RR5-16.1
R5-17.1 (Duplicate – refer to R5-18.8 and R5-20.1)
R5-17.2 (Duplicate – refer to R5-18.8 and R5-20.1)
RR5-16.2
RR5-17.1
RR5-17.2
RR5-17.3
RR5-17.4
RR5-18.1
RR5-18.2
R5-18.3
RR5-18.3
RR5-19
RR5-20
R5-21.5 (Duplicate – refer to R5-21.1)
R5-23.4
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)
RR5-26.2
R5-27.5 (Duplicate – refer to RR5-42.1)
RR5-28.2
R5-29.2
R5-31.1
R5-31.2
R5-32 (Duplicate – refer to R5-31.3)
R5-33 (Duplicate – refer to R5-35 and R5-36)
R5-34

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

R5-40.2 (Duplicate – refer to R5-34)
RR5-43 Activation with Old Service Provider Authorization
RR5-44
RR5-45
RR5-46
RR5-47
R5-48
RR5-48
RR5-49
R5-49.1
R5-49.2
RR5-54
R5-54.1
R5-54.2
R5-56 (Duplicate – refer to R5-57.1)
R5-64.2
R5-64.3
R5-64.4
R5-64.5
R5-64.6
R5-64.7
R5-65.3
R5-66.1
R5-71.1 (Superseded – refer to RR5-28)
R5-71.7
RR5-131
RR5-132
RR5-133
RR5-134
RR5-135
RR5-146
RR5-148
R6-1
R6-2.1
R6-2.2
R6-3

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

RX6-3.1
RR6-6 (Duplicate – refer to R10-10.1)
RR6-7 (Duplicate – refer to R10-10.1)
RR6-10
RR6-11 (Duplicate — refer to RX6-2.5)
RR6-12 (moved to RX6-2.6)
R6-10.1
R6-10.2
R6-10.3
R6-11
R6-12
R6-13
R6-14.1
R6-14.2
R6-15.1
R6-15.2
R6-15.3
R6-16.1
R6-16.2
R6-17.1
R6-17.2
R6-17.3
R6-18.1
R6-18.2
R6-18.3
R6-19
R6-20.1
R6-20.2
R6-20.3
R6-21
R6-29.1
R6-30.3
R6-31
R6-32
R6-33
R6-34

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

R6-4.1
R6-4.2
R6-4.3
R6-5.1
R6-5.2
R6-6.1
R6-6.2
R6-7.1
R6-7.2
R6-8.1
R6-8.2
R6-9.1
R6-9.2
R6-9.3
RR6-119
RR6-120
RR6-121
RR6-181
R7-11 (Duplicate – refer to R7-10)
R7-17 (Duplicate – refer to R7-15)
R7-30 (Duplicate – refer to R7-10)
R7-45 (Duplicate – refer to R7-47)
R7-59 (Duplicate – refer to R7-53.3)
R7-62.1 (Duplicate – refer R7-12)
R7-62.2 (Duplicate – refer to R7-12)
R7-71.1
R7-101.1
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)
R7-105.1 (Duplicate – refer to R7-97 and R7-98)
R7-110.2 (Duplicate – refer to R7-107.2)
R8-2.2
R8-5.2
R8-6.2

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Deleted Requirements     

R8-7.1
R8-7.2
R8-7.3
R8-8
R8-13
R8-14.1
R8-14.2
R8-16.2
R8-16.3
R8-16.4
R8-18 (Duplicate – refer to R8-7.3)
R8-24 (Duplicate – refer to R9-2)
R9-7
R9-8 (Duplicate – refer to R9-2)
R9-12.3 (Duplicate – refer to RX9-5 number 20)
R9-13 (Duplicate – refer to R9-2)
RR9-5
RR9-6
RN10-1
R10-15
R10-17
R11-7 (Duplicate – refer to RX11-5)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	G-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

Release Migration     

Appendix H. Release Migration

This section contains a list of requirements (in the format Rel3-seq #) that are specific to the NPAC SMS migration from Release 2.0 to Release 3.0. Once the NPAC SMS has migrated all applicable production data to the new release, these requirements will expire, and will no longer be required functionality for the NPAC SMS.

Rel3-1 National Number Pooling Migration – Conversion of Blocks for 1.4 Pooling

NPAC SMS shall provide a mechanism for Pooled Data in a pre-EDR environment, to be converted to Pooled Data in an EDR environment, prior to the live date for the National Number Pooling Release in the NPAC SMS.

Note: The Subscription Versions with LNP Type of POOL will remain in the NPAC SMS, and a corresponding NPA-NXX-X and EDR Block will be created in the NPAC SMS, but will not be broadcast over the Interface. (Previously M-10)

Rel3-2 National Number Pooling Migration – Setting of NPA-NXX-X Indicators

NPAC SMS shall provide a mechanism for the NPAC Customer SOA NPA-NXX-X Indicator and the NPAC Customer LSMS NPA-NXX-X Indicator, in the NPAC Customer Data Model, to be set for all Service Providers, prior to the live date for the National Number Pooling Release in the NPAC SMS. (Previously M-20)

Rel3-3 National Number Pooling Migration – Setting of EDR Indicators

NPAC SMS shall provide a mechanism for the NPAC Customer LSMS EDR Indicator, in the NPAC Customer Data Model, to be set for all Service Providers, prior to the live date for the National Number Pooling Release. (Previously M-30)

Release 3.3: © 1997 — 2006 NeuStar, Inc.	H-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.2a

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006

EX-99.2

Exhibit 99.2

NPAC SMS
INTEROPERABLE INTERFACE SPECIFICATION

NANC Version 3.3.2a

Prepared for:
The North American Numbering Council (NANC)

March 9, 2006

Release 3.3: © 1997 — 2006 NeuStar, Inc.

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.

This page intentionally left blank.

Table of Contents

Table Of Contents

1 Introduction	1
1.1 Document Overview	1
1.2 How To Use This Document	1
1.3 Document Numbering Strategy	1
1.4 Document Version History	2
1.4.1 Release 1.0	2
1.4.2 Release 2.0	2
1.4.3 Release 3.0	3
1.4.4 Release 3.1	3
1.4.5 Release 3.2	3
1.4.6 Release 3.3	3
1.5 References	4
1.5.1 Standards	4
1.5.2 Related Publications	5
1.6 Abbreviations/Definitions	6
2 Interface Overview	9
2.1 Overview	9
2.2 OSI Protocol Support	9
2.3 SOA to NPAC SMS Interface	10
2.3.1 Subscription Administration	10
2.3.2 Audit Requests	10
2.3.3 Notifications	11
2.3.4 Service Provider Data Administration	12
2.3.5 Network Data Download	12
2.3.6 Number Pool Block Administration	12
2.4 NPAC SMS to Local SMS Interface	12
2.4.1 Subscription Version, Number Pool Block and Network Data Download	13
2.4.2 Service Provider Data Administration	13
2.4.3 Notifications	13
3 Hierarchy Diagrams	15
3.1 Overview	15
3.1.1 Managed Object Model Inheritance Hierarchy	15
3.1.2 Log Record Managed Object Hierarchy	16
3.1.3 NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS	17
3.1.4 NPAC SMS to Local SMS Naming Hierarchy for the Local SMS	18
3.1.5 SOA to NPAC SMS Naming Hierarchy for the NPAC SMS	19
3.1.6 NPAC SMS to SOA Naming Hierarchy for the SOA	20
4 Interface Functionality to CMIP Definition Mapping	21
4.1 Overview	21
4.1.1 Primary NPAC Mechanized Interface Operations	21
4.1.2 Managed Object Interface Functionality	25
4.1.3 Action Interface Functionality	29

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		1

Table of Contents

4.1.4 Notification Interface Functionality	30
4.2 Scoping and Filtering Support	34
4.2.1 Scoping	34
4.2.2 Filtering	34
4.2.3 Action Scoping and Filtering Support	37
4.3 lnpLocal-SMS-Name and lnpNPAC-SMS-Name Values	37
4.4 OID Usage Information	37
4.4.1 OIDs Used for Bind Requests	37
4.4.2 Other OIDs of Interest	38
4.5 Naming Attributes	38
4.6 Subscription Version M_DELETE Messages	38
4.7 Number Pool Block M_DELETE Messages	38
4.8 Subscription Version Queries	38
5 Secure Association Establishment	41
5.1 Overview	41
5.2 Security	41
5.2.1 Authentication and Access Control Information	41
5.2.1.1 System Id	43
5.2.1.2 System Type	43
5.2.1.3 User Id	43
5.2.1.4 List Id	43
5.2.1.5 Key Id	44
5.2.1.6 CMIP Departure Time	45
5.2.1.7 Sequence Number	45
5.2.1.8 Association Functions	45
5.2.1.9 Recovery Mode	47
5.2.1.10 Signature	47
5.2.2 Association Establishment	47
5.2.3 Data Origination Authentication	49
5.2.4 Audit Trail	51
5.3 Association Management and Recovery	52
5.3.1 Establishing Associations	52
5.3.1.1 NpacAssociationUserInfo	52
5.3.1.2 Unbind Requests and Responses	52
5.3.1.3 Aborts	53
5.3.1.4 NPAC SMS Failover Behavior	53
5.3.1.5 Service Provider SOA and Local SMS Procedures	53
5.3.2 Releasing or Aborting Associations	54
5.3.3 Error Handling	55
5.3.3.1 NPAC SMS Error Handling	55
5.3.3.2 Processing Failure Error	55
5.3.3.3 NPAC SMS Detailed Error Codes	56
5.3.4 Recovery	56
5.3.4.1 Local SMS Recovery	61
5.3.4.2 SOA Recovery	61
5.3.4.3 Linked Action Replies during Recovery	61
5.4 Congestion Handling	63

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		2

Table of Contents

5.4.1 NPAC SMS Congestion	63
5.4.2 NPAC Handling of Local SMS and SOA Congestion	63
5.4.3 Out-Bound Flow Control	64
5.5 Abort Processing Behavior	64
5.6 Single Association for SOA/LSMS	65
5.7 Separate SOA Channel for Notifications	65
6 GDMO Definitions	67
7 General ASN.1 Definitions	69
8 LNP XML Schema	70
9 Subscription Version Status	71
10 Number Pool Block Status	75
Appendix A: Errors	A-1
Appendix B: Message Flow Diagrams	B-1

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		3

Introduction

1 Introduction

[Graphic Omitted: 1]

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

Section 1 Introduction — This section describes the conventions and organization of this document. It also lists related documentation.

Section 2 Interface Overview — This section contains an overview of protocol requirements and a brief description of the functionality provided in each interface.

Section 3 Hierarchy Diagrams — This section contains the class hierarchy diagrams for all managed objects defined in the interoperable interface.

Section 4 Interface Functionality to CMOP Definition Mapping — This section contains the mapping of the interface functionality to the managed objects, attributes, actions, and notifications.

Section 5 Secure Association Establishment— This section contains information on secure association establishment

Section 6 GDMO Definitions — This section contains the GDMO interface definitions supporting the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface

Section 7 General ASN.1 Definitions — This section contains the ASN.1 definitions that support the GDMO definitions in Section 7.

Section 8 Subscription Version Status — This section 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.

Appendix B Message Flow Diagrams — This appendix contains the message flow diagrams.

Appendix C Midwest Region Number Pooling Message Flow Diagrams — This appendix is deleted in Release 3.0.0.

1.3 Document Numbering Strategy

Starting with Release 2.0 the documentation number of the IIS document will be Version X.Y.Z as follows:

X – will only be incremented when a new major release of the NPAC SMS system is authorized. It will contain only the Change Orders that have been authorized for

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		1

Introduction

inclusion in this new major release.

Y –	will only be incremented when a new sub-release of an existing release X is authorized. It will contain only the Change Orders that have been authorized for inclusion in this new sub-release.
Z –	will be incremented when documentation only clarifications and/or backward compatibility issues or other deficiency corrections are made in the IIS and/or FRS. This number will be reset to 0 when Y is incremented.

For example, the first release of the Release 2 IIS will be numbered 2.0.0. If documentation only clarifications are introduced in the next release of the IIS document it will be numbered 2.0.1. If requirements are added to Release 2.0 that require NPAC SMS software changes then the next release of the IIS document will be numbered 2.1.0.

Starting with Release 3.2, the documentation number of the FRS document will include a “lowercase letter” following the Z designation. This “lowercase letter” will essentially serve as a version indicator for the release of the documentation, such that the X.Y.Za will be a unique identifier. It will be used for both drafts and final versions. For example, the first release using this new convention will be 3.2.0a, followed by 3.2.0b, and so on. . The “lower case letter” shall be reset to ‘a’ when Z is incremented.

This number scheme is intended to make the mapping between NPAC SMS and the FRS and IIS documentation consistent.

1.4	Document Version History
1.4.1	Release 1.0

NANC Version 1.0, released on 04/07/97, contains changes from the ICC Subcommittee IIS Version 1.1.5.

NANC Version 1.1, released on 05/08/97, contains changes from the NANC IIS Version 1.0.

NANC Version 1.2, released on 05/25/97, contains changes from the NANC IIS Version 1.1.

NANC Version 1.3, released on 07/09/97, contains changes from the NANC IIS Version 1.2.

NANC Version 1.4, released on 08/08/97, contains changes from the NANC IIS Version 1.3.

NANC Version 1.5, released on 09/09/97, contains changes from the NANC IIS Version 1.4.

NANC Version 1.6, released on 11/12/97, contains changes from the NANC IIS Version 1.5.

NANC Version 1.7, released on 12/12/97, contains changes from the NANC IIS Version 1.6.

NANC Version 1.8, released on 2/11/98, contains changes from the NANC IIS Version 1.7.

NANC Version 1.9, released on 5/13/98, contains changes from the NANC IIS Version 1.8.

NANC Version 1.10, released on 7/8/98, contains changes from the NANC IIS Version 1.9.

1.4.2 Release 2.0

NANC Version 2.0.0, released on 12/14/98, contains changes from the NANC IIS Version 1.10.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		2

Introduction

NANC Version 2.0.1, released on 2/25/99, contains changes from the NANC IIS Version 2.0.0.

NANC Version 2.0.2, released on 9/1/99, contains changes from the NANC IIS Version 2.0.1.

1.4.3 Release 3.0

NANC Version 3.0.0, released on 1/28/00 and 2/14/00 (revised version), contains changes from the NANC IIS Version 2.0.2.

NANC Version 3.0.1, released on 6/6/00, contains changes from the NANC IIS Version 3.0.0.

NANC Version 3.0.2, released on 9/11/00, contains changes from the NANC IIS Version 3.0.0.

1.4.4 Release 3.1

NANC Version 3.1.0, released on 8/24/01, contains changes from the NANC IIS Version 3.0.2.

1.4.5 Release 3.2

NANC Version 3.2.0, released on 8/27/02, contains changes from the NANC IIS Version 3.1.0

NANC Version 3.2.1a, released on 7/28/03, contains changes from the NANC IIS Version 3.2.0

NANC Version 3.2.2a, released on 6/30/04, contains changes from the NANC IIS Version 3.2.1a.

1.4.6 Release 3.3

NANC Version 3.3.0a, released on 4/25/05, contains changes from the NANC IIS Version 3.2.2a.

NANC Version 3.3.0b, released on 5/27/05, contains changes from the NANC IIS Version 3.3.0a.

NANC Version 3.3.0c, released on 6/22/05, contains changes from the NANC IIS Version 3.3.0b.

NANC Version 3.3.0d, released on 7/29/05, contains changes from the NANC IIS Version 3.3.0c.

NANC Version 3.3.1a, release on 10/14/05 contains documentation changes from the NANC IIS Version 3.3.0d.

NANC Version 3.3.2a, release on 3/9/2006 contains the following documentation changes from the NANC IIS Version 3.3.1a:

• Documentation only changes contained in Change Order NANC 407 NPAC Range Operations and Associated Notifications

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		3

Introduction

Documentation only changes contained in Change Order NANC 410 Doc Only Change Order: IIS

NOTE: With Release 3.3 of the NPAC SMS, new functionality related to SV Type and Optional Data (Alternative SPID) for a subscription version and number pool block, is implemented but is currently inactive in all NPAC Regions. Many existing flows in the IIS are impacted with the implementation of SV Type and Alternative SPID and can be identified by references “SVType” and “AlternativeSPID”. Until NAPM LLC approval, this functionality will remain inactive in the NPAC SMS system.

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

Bellcore TA- 1253, Generic Requirements for Operations Interfaces Using OSI Tools: Network Element Security Administration.

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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		4

Introduction

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

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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		5

Introduction

North American Number Council (NANC) Functional Requirements Specification, Number Portability Administration Center (NPAC), Service Management System (SMS), Version 3.3.2a March 9, 2006.

CTIA Report on Wireless Portability Version 2, July 7, 1998

1.6 Abbreviations/Definitions

A-PDU	Application Protocol Data Unit
ASN.1	Abstract Syntax Notation 1
BER	Basic Encoding Rules
CARE	Customer Account Record Exchange
Central Time	This is the time in the central time zone, which includes daylight savings time.
(standard/daylight)	It changes twice a year based on standard time and daylight savings time. The NPAC SMS runs on hardware that uses this time.
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
Local Time	The time zone of the local user. Most time representations in the NPAC OP GUI are represented in the user’s local time zone based on the PC’s clock setting. The time zone label is included in time display in the GUI.
	EST for Eastern Time Zone
	CST for Central Time Zone
	MST for Mountain Time Zone
	PST for Pacific Time Zone
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)
MIB	Management Information Base
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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		6

Introduction

SOA	Service Order Activation
SMS	Service Management System
TMN	Telecommunications Management Network
TN	Telephone Number
WSMSC	Wireless Short Message Service Center

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		7

Interface Overview

2 Interface Overview

[Graphic Omitted: 2]

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-EVENT-REPORT, and M-ACTION primitives are fully supported in a confirmed mode. Thus, the sequencing of operations is implied by the receipt of the confirmation or operation response, and NOT by the sequence that the operation request is received. The relationship from the SOA to the NPAC SMS and from 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 Section 5, Secure Association Establishment.

Note: The M-CANCEL-GET primitive may not be supported in some NPAC SMS implementations due to the fact that this functionality was not determined necessary for the interface defined.

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 Appendix B, Message Flow Diagrams, as well as the behavior for the managed objects.

The interface between the SOA and the NPAC SMS is called the “SOA to NPAC SMS interface”. The interface between the Local SMS and the NPAC SMS is called the “NPAC SMS to Local SMS interface”. No direction for operations is implied by the names of these interfaces.

All timestamps (GeneralizedTime fields) that are sent over the SOA to NPAC SMS interface and NPAC SMS to Local SMS interface, shall use Greenwich Mean Time (GMT). The universal time format (YYYYMMDDHHMMSS.0Z) is used. The default value is a non-specific format of 00000000000000.0Z.

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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		8

Interface Overview

2	PPP, MAC, FRAME Relay, ATM (IEEE 802.3)	Link
1	DS-1, DS-0 x n, ISDN, V.34	Physical

Multiple associations per service provider to the NPAC SMS can be supported when using different function masks. The secure association establishment is described in Section 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 and number pool block data changes, needed for concurrence or authorization for number porting, conflict-resolution, cancellation, outage information, customer disconnect dates, or the first use of an NPA-NXX.

• Network data from the NPAC SMS to SOA.

• Service provider data administration from the SOA to the NPAC SMS.

• SOA requests for number pool block administration (creation and modification) to the NPAC SMS and responses from the NPAC SMS to the SOA.

Mapping of this functionality into the CMIP Definitions is provided in Section 4 (see Exhibit 8.) The NPAC SMS currently uses a 32-bit signed integer for the Naming ID Value. The maximum value is ([2**31] – 1) or 2.14B. It is anticipated that all Service Providers will be able to successfully handle Naming ID Values up to this maximum. Additionally, it should be noted that there is NOT any rollover strategy (NANC 147), once this number is attained within the NPAC SMS.

2.3.1 Subscription Administration

Service provider subscription administration functionality includes the capability to:

• Create a subscription version or range of versions

• Cancel a subscription version

• Acknowledge cancellation of a subscription version

• 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

• Place a subscription into conflict

• Remove a subscription version from conflict

2.3.2 Audit Requests

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		9

Interface Overview

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 requesting 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 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 amount of time 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 cancellation within a timeframe specified by the NPAC SMS, notifications will be sent requesting 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. Notification of data value changes and object creations are sent for number pool block objects.

First usage notifications are also sent to the SOA when the first use of an NPA-NXX occurs from a subscription version or number pool block creation.

Each SOA notification is assigned a priority of high, medium, low or none. The category of none indicates that a Service Provider does not want to receive a particular notification. Notifications are then sent in order of priority from high to low.

SOA Service Providers can receive single or range versions of some notifications. If the service provider’s TN Range Notification Indicator is turned OFF in their service provider profile on the NPAC SMS, the following notifications will be sent:

Attribute Value Change for subscriptionVersionNPAC objects
Object Creation for subscriptionVersionNPAC objects
subscriptionVersionCancellationAcknowledgeRequest
subscriptionVersionDonorSP-CustomerDisconnectDate
subscriptionVersionNewSP-CreateRequest
subscriptionVersionNewSP-FinalCreateWindowExpiration
subscriptionVersionOldSP-ConcurrenceRequest
subscriptionVersionOldSPFinalConcurrenceWindowExpiration
subscriptionVersionStatusAttributeValueChange

If the service provider’s TN Range Notification Indicator is turned ON, the following notifications will be sent:

subscriptionVersionRangeAttributeValueChange for subscriptionVersionNPAC objects

subscriptionVersionRangeCancellationAcknowledgeRequest
subscriptionVersionRangeDonorSP-CustomerDisconnectDate
subscriptionVersionRangeNewSP-FinalCreateWindowExpiration
subscriptionVersionRangeNewSP-CreateRequest

subscriptionVersionRangeObjectCreation for subscriptionVersionNPAC objects

subscriptionVersionRangeOldSP-ConcurrenceRequest
subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration

subscriptionVersionRangeStatusAttributeValueChange

Notifications can be recovered by the SOA from the NPAC SMS. Notifications to be recovered are requested by time range and are recovered in the order the NPAC SMS

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		10

Interface Overview

attempted to sent them. Alternatively, notifications can be recovered using SWIM (Send What I Missed) recovery.

In situations where Subscription Versions are initially created in ranges, then have subsequent activity (modify, activate, disconnect, cancel) performed in singles, TN Range Notifications may changes. Specifically, if subsequent activity on a TN ranges does not equal the initial TN range (subsequent activity is either singles or a subset of the TN range), then initial and final timers (T1, T2) will result in single TN Notifications. TN range requests after the timers would still have the potential to generate TN Range Notifications for Service Providers that support this feature

2.3.4 Service Provider Data Administration

Service providers can use, read, and update their service provider information on the NPAC SMS using the SOA. Service providers can update some information in the service provider profile as well as add and delete their own network data. Changes to network data that result in mass updates are prevented from the SOA to the NPAC. Mass changes must be initiated by the service provider contacting the NPAC personnel directly.

2.3.5 Network Data Download

When network data (NPA-NXX, NPA-NXX-X , Service Provider, or LRN data for service providers) is created, modified, or deleted on the NPAC SMS, the data is automatically downloaded from the NPAC SMS to the SOA. The SOA may request that data be recovered using a recovery request that is sent from the SOA to the NPAC SMS. The SOA then receives the data to be recovered in the request response. Network data to be recovered can be requested based on a time range, SWIM data, service provider or all service providers, an NPA-NXX range or all NPA-NXX data, an NPA-NXX-X range or all NPA-NXX-X data, an LRN range or all LRN data, or all network data can be requested. If all network data is specified and the “NPAC Customer SOA NPA-NXX-X Indicator” has been set to TRUE in the service provider’s profile on the NPAC SMS, then NPA-NXX-X object data will be included in the recovery response.

Service providers can also directly read data they wish to download from the NPAC SMS MIB.

2.3.6 Number Pool Block Administration

Number pool blocks are a set of 1000 TNs represented by a 7 digit NPA-NXX-X (i.e. 555-333-1 represents 555-333-1000 through 1999). Service providers can create and modify the number pool blocks for which they are the block holder. Service providers can query all number pool block objects. Only the NPAC Personnel can initiate the removal of a number pool block object.

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, number pool block and network data from the NPAC SMS to the Local SMS.

• Service provider data administration from the Local SMS to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: ©1997 — 2006 NeuStar, Inc.		11

Interface Overview

• 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 Section 4 (see Exhibit 8.) The NPAC SMS currently uses a 32-bit signed integer for the Naming ID Value. The maximum value is ([2**31] – 1) or 2.14B. It is anticipated that all Service Providers will be able to successfully handle Naming ID Values up to this maximum. Additionally, it should be noted that there is NOT any rollover strategy (NANC 147), once this number is attained within the NPAC SMS.

2.4.1 Subscription Version, Number Pool Block and Network Data Download

When network data (NPA-NXX, NPA-NXX-X or LRN data for service providers) or subscription data or number pool block data is created, modified, or deleted 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 recovered using a recovery request that is sent from the Local SMS to the NPAC SMS. The Local SMS then receives the data to be recovered in the request response. Subscription data to be recovered can be requested based on time range, SWIM recovery, a TN, or a TN range. If the “NPAC Customer LSMS EDR Indicator” is set to TRUE in the service provider’s profile on the NPAC SMS, only number pool block data will be sent and no subscription versions with LNP type set to ‘pool’ will be sent. Number pool block data to be recovered can be requested by time-range, SWIM recovery, NPA-NXX-X or NPA-NXX-X range. Network data to be recovered can be requested based on a time range, SWIM recovery, service provider or all service providers, an NPA-NXX range or all NPA-NXX data, an NPA-NXX-X range or all NPA-NXX-X data, an LRN range or all LRN data, or all network data can be requested. If all network data is specified and the “NPAC Customer LSMS NPA-NXX-X Indicator” has been set to TRUE in the service provider’s profile on the NPAC SMS, then NPA-NXX-X object data will be included in the recovery response.

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 service provider information on the NPAC SMS using the Local SMS to NPAC SMS interface. Service providers can update some information in the 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 SMSs are sent notifications to ensure they are aware of planned down time in the NPAC SMS. Local SMSs are also sent notifications when a new NPA-NXX is to be used for the first time in a subscription version or number pool block by a serviceProvNPA-NXX-X creation.

Notifications can be recovered by the Local SMS from the NPAC SMS. Notifications to be recovered are requested by time range. Alternatively, notifications can be recovered using SWIM recovery.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3:©1997 - 2006 NeuStar, Inc.		12

Hierarchy Diagrams

3 Hierarchy Diagrams

[Graphic Omitted: 3]

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), the SOA (Exhibit 6.), and the NPAC SMS naming hierarchies for the SOA. (Exhibit 7). 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.

[Graphic Omitted: . The Managed Object Model Inheritance Hierarchy]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: ©1997 — 2006 NeuStar, Inc.		13

Hierarchy Diagrams

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.

[Graphic Omitted: . Log Record Managed Object Hierarchy]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		14

Hierarchy Diagrams

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.8, Association Functions.

[Graphic Omitted: The NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS.]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		15

Hierarchy Diagrams

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.8, Association Functions.

[Graphic Omitted: The NPAC SMS to Local SMS Naming Hierarchy for the Local SMS.]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		16

Hierarchy Diagrams

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.8, Association Functions.

[Graphic Omitted:. The SOA to NPAC SMS Naming Hierarchy for the NPAC SMS]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		17

Hierarchy Diagrams

3.1.6 NPAC SMS to SOA Naming Hierarchy for the SOA

The NPAC SMS to SOA Naming Hierarchy for SOA shows the naming hierarchy used in the SOA to instantiate objects defined in the SOA to NPAC SMS interface.

Shaded objects are instantiated at SOA 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 SOA or from actions taken while the SOA is running.

Each object class belongs to one or more Association Functions.

Refer to Section 5.2.1.8, Association Functions.

[Graphic Omitted: NPA SMS to SOA Naming Hierarchy for the SOA]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: ©1997 - 2006 NeuStar, Inc.		18

Interface Functionality to CMIP Definition Mapping

4 Interface Functionality to CMIP Definition Mapping

[Graphic Omitted: 4]

4.1 Overview

The following tables, Exhibits 8-12, 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

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Abort/Cancel Audit Request	from SOA	M-DELETE	subscriptionAudit
Audit Complete	to SOA	M-EVENT-REPORT:	subscriptionAudit
		subscriptionAuditResults
Audit Discrepancy	to SOA	M-EVENT-REPORT:	subscriptionAudit
		subscriptionAudit-DiscrepancyRpt
Audit Query	from SOA	M-GET	subscriptionAudit
Audit Request SOA	from SOA	M-CREATE	subscriptionAudit
Cancellation	from SOA (new service	M-ACTION:	lnpSubscriptions
Acknowledgement	provider)	subscriptionVersionNewSP-
		CancellationAcknowledge
Cancellation	from SOA (old service	M-ACTION:	lnpSubscriptions
Acknowledgment	provider)	subscriptionVersionOldSP-      CancellationAcknowledge
Conflict Removal	from SOA (new service	M-ACTION:	lnpSubscriptions
	provider)	subscriptionVersionRemoveFromConflict
Customer Disconnect	to SOA	M-EVENT-REPORT:	subscriptionVersionNPAC
Date		subscriptionVersionDonorSP-      CustomerDisconnectDate or	or lnpSubscriptions
		subscriptionVersionRangeDonorSP-      Customer DisconnectDate

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		19

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Final Request for      Version Create	to SOA (old service provider)	M-EVENT-REPORT:      subscriptionVersionOldSPFinalConcurrence      WindowExpiration or      subscriptionVersionRangeOldSPFinalCo ncur      renceWindowExpiration	subscriptionVersionNPAC or lnpSubscriptions
LSMS Filter NPA-      NXX Create	from LOCAL SMS or from SOA	M-CREATE	lsmsFilterNPA-NXX
LSMS Filter NPA-      NXX Delete	from LOCAL SMS or from SOA	M-DELETE	lsmsFilterNPA-NXX
LSMS Filter NPA-      NXX Query	from LOCAL SMS or from SOA	M-GET	lsmsFilterNPA-NXX
Network Data      Download	from LOCAL SMS or from SOA	M-ACTION:      lnpDownload or M-GET:	lnpNetwork
		scoped and filtered for intended      serviceProvLRN, serviceProvNPA-NXX      serviceProvNPA-NXX-X, service provider      attributes
Network Data      Update	from LOCAL SMS or from SOA	M-CREATE	serviceProvLRN,      serviceProvNPA-NXX
NPA-NXX-X      Create	to LOCAL SMS or to SOA	M-CREATE;	serviceProvNPA- NXX-X
NPA-NXX-X      Delete	to LOCAL SMS or to SOA	M-DELETE	serviceProvNPA- NXX-X
NPA-NXX-X      Modify	to LOCAL SMS or to SOA	M-SET	serviceProvNPA-NXX-X
New NPA-NXX	to LOCAL SMS or to SOA	M-EVENT-REPORT:      subscriptionVersionNewNPA-NXX	SubscriptionVersionNPAC lnpNPAC-SMS

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		20

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Number Pool       Block Change       Notification	to SOA	M-EVENT-REPORT attributeValueChange Notification or      numberPoolBlockStatusAttributeValueChange       Notification	numberPoolBlockNPAC
Number Pool       Block Create	from SOA	M-ACTION: numberPoolBlock-Create	lnpSubscriptions
Number Pool       Block Create	to LOCAL SMS	M-CREATE: for a single numberPoolBlock	numberPoolBlock
Number Pool       Block Modify	from SOA	M-SET: to a single numberPoolBlock	numberPoolBlockNPAC or      lnpSubscriptions
Number Pool       Block Modify	to LOCAL SMS	MSET: to a single numberPoolBlock or scoped and filtered by NPA-NXX-X range for mass update	numberPoolBlock or      lnpSubscriptions
Number Pool       Block Delete	to LOCAL SMS	M-DELETE: for a single numberPoolBlock	numberPoolBlock
Number Pool       Block Query	from LOCAL SMS or SOA	M-GET: To a single numberPoolBlockNPAC or scoped and filtered for intended numberPoolBlocks	lnpSubscriptions numberPoolBlockNPAC
Number Pool	to LOCAL SMS	M-GET:
Block Query		scoped and filtered for intended      numberPoolBlock	lnpSubscriptions
Notification	from LOCAL SMS	M-ACTION:
Recovery	or from SOA	lnpNotificationRecovery	lnpNPAC-SMS
Recovery      Complete	from LOCAL SMS or	M-ACTION:	lnpNPAC-SMS
	from SOA	lnpRecoveryComplete
Request for      Cancellation      Acknowledg-ment	to SOA	M-EVENT-REPORT:      subscription      VersionCancellationAcknowledgment      Request or      subscriptionVersionRangeCancellationAckn      owledgeRequest	subscriptionVersionNPAC or lnpSubscriptions
Request for      Version Create	to SOA      (new service      provider)	M-EVENT-REPORT:      subscriptionVersionNewSP-Create      Request or      subscriptionVersionRangeNewSP-CreateRequest	subscriptionVersionNPAC

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		21

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Request for    Version Create	to SOA   (old service provider)	M-EVENT-REPORT:      subscriptionVersionOldSP-Concurrence      Request or      subscriptionVersionRangeOldSP- Concurrence Request	subscriptionVersionNPAC or lnpSubscriptions
Service Provider      Network      Creation	to LOCAL SMS or to SOA	M-CREATE	serviceProvNetwork
Service Provider      Network      Deletion	to LOCAL SMS or to SOA	M-DELETE	serviceProvNetwork
Service Provider      Network Service      Provider Name      Change	to LOCAL SMS or to SOA	M-SET:      serviceProvName	serviceProvNetwork
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 and      subscriptionVersionStatusAttributeValue      Change or      subscriptionVersionRangeAttribute      ValueChange      subscriptionVersionRangeStatusAttribute      ValueChange	subscriptionVersionNPAC or lnpSubscriptions
Subscription      Version Conflict	from SOA (old service   provider)	M-ACTION:   subscriptionVersionOldSP-Create   setting subscriptionOldSP-Authorization = FALSE	subscriptionVersion
Subscription      Version Create	to LOCAL SMS	M-ACTION:      subscriptionVersionLocalSMS-Create for       multiple creates (i.e., range operations)      where the data in the subscription versions      is the same	lnpSubscriptions subscriptionVersion
		M-CREATE:
		for an individual subscriptionVersion
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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		22

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Subscription      Version      Download	to LOCAL SMS	M-ACTION: subscriptionVersionLocalSMS-Create or	lnpSubscriptions
		M-CREATE:
		for an individual subscriptionVersion
Subscription      Version      Download      Request	from LOCAL SMS	M-ACTION:      lnpDownload or	lnpSubscriptions
		M-GET:
		scoped and filtered for intended      subscriptionVersionNPAC criteria
Subscription      Version Modify	from SOA	M-ACTION: subscriptionVersion Modify or	lnpSubscriptions
		M-SET:
		on relevant subscriptionVersionNPAC      attributes for pending and conflict      versions
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

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.

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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 – 2006 NeuStar, Inc.		23

Interface Functionality to CMIP Definition Mapping

Managed Object Name	Interface Functionality Mapping
lnpLogAuditResultsRecord	Object used to log information from a subscriptionAuditResults notification.
lnpLogCancellation AcknowledgeRequest Record	Object used to log information from a subscriptionVersionCancellationAcknowledgeRequest notification.
lnpLogDonorSP-CustomerDi sconnectDateRecord	Object used to log information from a subscriptionVersionDonorSP-CustomerDisconnectDate notification.
lnpLogLocalSMS-ActionRes ultsRecord	Object used to log information from a subscriptionVersionLocalSMS-ActionResults notification.
lnpLogNewNPA-NXXRecord	Object used to log information from a subscriptionVersionNewNPA-NXX notification.
lnpLogNewSP-CreateReques tRecord	Object used to log information from a subscriptionVersionNewSP-CreateRequest notification.
lnpLogNumberPoolBlockSta tusAttributeValueChangeR ecord	Object used to log information from a numberPoolBlockStatusAttributeValueChange notification.
lnpLogOldSP-ConcurrenceR equestRecord	Object used to log information from a subscriptionVersionOldSP-ConcurrenceRequest notification.
lnpLogOldSP-FinalConcurrenceWindow-Expiration	Object used to log information from a subscriptionVersionOldSPFinalConcurrenceWindowExpiration notification
lnpLogOperational-Inform ationRecord	Object used to log information from a lnpNPAC-SMS-Operational-Information notification.
lnpLogRangeAttributeValu eChangeRecord	Object used to log information from a lnpLogRangeAttributeValueChange notification.
lnpLogRangeObjectCreatio nRecord	Object used to log information from a lnpLogRangeObjectCreation notification.
lnpLogRangeStatusAttribu teValueChangeRecord	Object used to log information from a lnpLogRangeStatusAttributeValueChange notification.
lnpLogRangeDonorSP-Custo merDisconnectDateRecord	Object used to log information from a lnpLogRangeDonorSP-CustomerDisconnectDate notification.
lnpLogRangeCancellationA cknowledgeRecord	Object used to log information from a lnpLogRangeCancellationAcknowledge notification.
lnpLogRangeNewSP-CreateR equestRecord	Object used to log information from a lnpLogRangeNewSP-CreateRequest notification.
lnpLogRangeNewSP-FinalCr eateWindowExpirationRecord	Object used to log information from a lnpLogRangeNewSP-FinalCreateWindowExpiration notification.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		24

Interface Functionality to CMIP Definition Mapping

Managed Object Name	Interface Functionality Mapping
lnpLogNewSP-FinalCreateW indowExpirationRecord	Object used to log information from a lnpLogNewSP-FinalCreateWindowExpiration notification.
lnpLogRangeOldSP-Concurr enceRequestRecord	Object used to log information from a lnpLogRangeOldSP-ConcurrenceRequest notification.
lnpLogRangeOldSPFinalCon currenceWindowExpiration Record	Object used to log information from a lnpLogRangeOldSPFinalConcurrenceWindowExpiration notification.
lnpLogStatusAttributeVal ueChangeRecord	Object used to log information from a subscriptionVersionStatusAttributeValueChange notification.
lnpLogHeartbeat-Informat ionRecord	Object used to log information from a Heartbeat-Information notification.
lnpLogSwimProcessing-Rec overyResultsRecord	Object used to log information from a swimProcessing-RecoveryResults notification.
lnpNetwork	Container object used to contain all service provider network data on the NPAC SMS, SOA, and Local SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support downloading of network data to the Local SMS and/or SOA and the 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 and SOA to NPAC SMS interfaces 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 and SOA to NPAC SMS interface to support retrieving of service provider data by the Local SMS and/or SOA and the functionality that allows service providers to update their service provider data on the NPAC SMS. Service providers can only retrieve their service provider data.
lnpSOA	Container object used to contain all objects on a SOA It is used in the SOA to NPAC SMS interface to support NPAC SMS communication to the service provider SOA system.
lnpSubscriptions	Container object used to contain all subscription versions and number pool blocks on the NPAC SMS and the Local SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support query of subscription and number pool block data on the NPAC SMS and downloading of subscription and number pool block data to the Local SMS.
lsmsFilterNPA-NXX	Object used to represent the NPA-NXX values for which a service provider does not want to be informed of subscription version broadcasts.
numberPoolBlock	Object used to represent a number pool block on the Local SMS. These objects are used to support number pool block download from the NPAC SMS to the EDR Local SMS using the NPAC SMS to Local SMS interface.
	Local SMS may support this object by setting the “NPAC Customer LSMS EDR Indicator” to TRUE in their service provider profile on the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		25

Interface Functionality to CMIP Definition Mapping

Managed Object Name	Interface Functionality Mapping
numberPoolBlockNPAC	Object used to represent a number pool block on the NPAC SMS. These objects are used to support number pool block administration from the SOA using the SOA to NPAC SMS interface. Capability is provided to the SOA for creation and modification. The NPAC SMS can create, modify and delete.
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 and SOA to NPAC SMS interfaces to support retrieving of service provider data and the 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 service provider data.
serviceProvLRN	Object used to represent an LRN associated with a service provider on the NPAC SMS, SOA, or Local SMS. These objects are used to support downloading of network LRN data to the Local SMS and/or SOA and the 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, SOA or Local SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support downloading of network data to the Local SMS and the 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, SOA or Local SMS. These objects are used to support downloading of network NPA-NXX data to the Local SMS and/or SOA and the 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.
serviceProvNPA-NXX-X	Object used to represent an NPA-NXX-X associated with a service provider on the NPAC SMS, SOA or Local SMS. These objects are used in number pooling to support downloading of network NPA-NXX-X data to the Local SMS or SOA. Only the NPAC SMS is allowed to create, delete and modify a service provider’s NPA-NXX-X data.
	Local SMS may support this object by setting the “NPAC Customer LSMS NPA-NXX-X Indicator” to TRUE in their service provider profile on the NPAC SMS.
	SOA may support this object by setting the “NPAC Customer SOA NPA-NXX-X Indicator” to TRUE in their service provider profile on the NPAC SMS.
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. If the subscription version LNP type is equal to ‘pool’, the appropriate number pool block will also be audited.
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, disconnect, and query.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		26

Interface Functionality to CMIP Definition Mapping

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

Exhibit 4. The Action Interface Functionality Table

Action Name	Interface Requirements Mapping
lnpDownload	This action is used to support the downloading of subscription, number pool block and network data to the Local SMS from the NPAC SMS. It also supports the downloading of network data to the SOA from the NPAC SMS.
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 or the SOA from the NPAC SMS using the SOA to NPAC SMS interface.
lnpNotificationRecovery	This action is used to support the downloading of notification data to the SOA and/or Local SMS from the NPAC SMS.
numberPoolBlock-Create	This action is used to support creation of the number pool block object by the block holder service provider from the SOA to the NPAC SMS using the SOA 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-CancellationAc knowledge	This action is used to support the acknowledgment of subscription versions with a status of cancel-pending by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.
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- CancellationAc knowledge	This action is used to support the acknowledgment of subscription versions with a status of cancel-pending by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		27

Interface Functionality to CMIP Definition Mapping

Action Name	Interface Requirements Mapping
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.
subscriptionVersion RemoveFromConflict	This action is used on the NPAC SMS via the SOA to NPAC SMS interface to set the subscription version status from conflict to pending.
lnpNotificationRecovery	This action is used on the NPAC SMS via the SOA to NPAC SMS or Local SMS to NPAC SMS interface to recover notifications.
subscriptionVersionActivateWithErrorCode	This action is used on the SOA to NPAC SMS interface by the new service provider to activate a subscription version id, TN or range of TNs via the SOA to NPAC SMS interface. This action’s reply contains an optional error code to be returned if the action is not successful.
subscriptionVersionCancelWithErrorCode	The action issued on the SOA to NPAC SMS interface by the SOA to cancel a subscription version. This action’s reply contains an optional error code to be returned if the action is not successful.
subscriptionVersionNewSP- CancellationAc knowledgeWithErrorCode	This action is used on the SOA to NPAC SMS interface by the new service provider to acknowledge cancellation of a subscriptionVersionNPAC with a status of cancel-pending. This action’s reply contains an optional error code to be returned if the action is not successful.
subscriptionVersionRemoveFromConflict WithErrorCode	This action used on the SOA to NPAC SMS interface by either the old or new service provider to set the subscription version status from conflict to pending. This action’s reply contains an optional error code to be returned if the action is not successful.
subscriptionVersionOldSP-CancellationAc knowledgeWithErrorCode	This action is used on the SOA to NPAC SMS interface by the old service provider to acknowledge cancellation of a subscriptionVersionNPAC with a status of cancel-pending. This action’s reply contains an optional error code to be returned if the action is not successful.

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

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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		28

Interface Functionality to CMIP Definition Mapping

Notification Name	Interface Requirements Mapping
numberPoolBlockStatusAttributeValueChange	This notification is issued when the number pool block status is modified and can contain the number pool block status and failed service provider list. This notification is issued over the NPAC SMS to SOA interface from the numberPoolBlockNPAC object.
subscriptionAuditDiscrepancyRpt	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.
subscriptionAuditResults	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 or subscriptionVersionRangeNewSP-CancellationAcknow ledge	This notification is issued to new and old service providers to request that a cancellation acknowledgment be sent for a subscription version in a cancel-pending state. This notification is issued via the SOA to NPAC SMS interface if the service provider fails to acknowledge the cancellation after a tunable amount of time specified in the NPAC SMS.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate	This notification informs the donor service provider SOA that a subscription version is being disconnected. This notification is issued from the NPAC SMS to a SOA via the SOA to NPAC SMS interface.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionLocalSMS-ActionResults	This notification contains the results of a subscriptionVersionLocalSMS-Cr eate 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 or SOA of a pending subscription version or new number pool block involving the first use of an NPA-NXX.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		29

Interface Functionality to CMIP Definition Mapping

Notification Name	Interface Requirements Mapping
subscriptionVersionNewSP-CreateRequest or subscriptionVersionRangeNewSP-CreateRequest	This notification is issued to the new service provider to request that a create request be sent for the subscription 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 if the new service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionNewSPFinalCreateWindow Expiration or subscriptionVersionRangeNewSPFinalCreateWindow Expiration	This notification is issued to the new and old service provider, if they support the Final Create Window Expiration Notification in their Service Provider profile, to inform them of the expiration of the Final Concurrence Window on the NPAC SMS. This notification is issued from the NPAC SMS to the SOA via the SOA to NPAC SMS interface.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionOldSP-ConcurrenceRequest or subscriptionVersionRangeOldSP-ConcurrenceRequest	This notification is issued to the old service provider to request that a create request be sent for the subscription version created by the new service provider to provide concurrence for porting. This notification is issued via the SOA to NPAC SMS interface if the old service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValue Change	This notification is issued when the subscription version status is modified. This notification is issued from the NPAC SMS to the SOA via the SOA to NPAC SMS interface.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionOldSPFinalConcurrenceWindow Expiration or subscriptionVersionRangeOldSPFinalConcurrence WindowExpiration	This notification is issued to the old service provider to request for a final time that a create request be sent for the subscription version created by the new service provider to provide concurrence for porting. This notification is issued via the SOA to NPAC SMS interface if the old service provider failed to authorize porting of a number after a tunable amount of time.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		30

Interface Functionality to CMIP Definition Mapping

Notification Name	Interface Requirements Mapping
subscriptionVersionRangeAttributeValueChange	This notification or the Attribute Value Change notification is sent when specified attributes have been updated. This notification is issued via the SOA to NPAC SMS interface.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
subscriptionVersionRangeObjectCreation	This notification or the object creation notification is sent when a subscriptionVersionNPAC object has been created. This notification is issued via the SOA to NPAC SMS interface.
	The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.
ApplicationLevelHeartBeat	This notification implements a SOA or LSMS Application Level Heartbeat function. With this functionality the NPAC SMS will send a periodic Heartbeat message when a quiet period between the SOA/LSMS and the             NPAC SMS exceeds the tunable value.
	This notification is prioritized and transmitted according to its SOA Notification Priority tunable in the NPAC SMS when sent over the NPAC SMS to SOA interface.
	Optionally, this notification may also be implemented on the SOA or Local SMS. With this functionality the SOA/Local SMS will send a periodic Heartbeat message when a quiet period between the SOA/Local SMS and the NPAC SMS exceeds the tunable value.
	This notification can be issued via the NPAC SMS to SOA and NPAC SMS to Local SMS interfaces. Optionally, this notification can also be issued via the SOA to NPAC SMS and LSMS to NPAC SMS interfaces.
swimProcessing-RecoveryResults	This notification contains the recovery results of a SWIM lnpDownload action or SWIM lnpNotificationRecovery action from a SOA/LSMS.
	This notification is issued via the SOA to NPAC SMS interface and the Local SMS to NPAC SMS interface.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 - 2006 NeuStar, Inc.		31

Interface Functionality to CMIP Definition Mapping

4.2 Scoping and Filtering Support

The following section defines the scoping and filtering support for both the SOA to NPAC SMS interface and LSMS to NPAC SMS interface.

4.2.1 Scoping

The NPAC SMS to Local SMS or SOA to NPAC SMS interfaces do not support scoping of CMIP operations of any type by the LSMS or SOA for the following objects:

• root

• lnpLocal-SMS

• lnpNetwork

• any object with an “empty” filter

NPAC SMS is not required to support Scope other than baseObject Scope for CMIP operations that specify baseManagedObjectClass of one of the following:

• lnpNPAC-SMS

• lnpServiceProvs

Scoped operations for subscriptionVersions or numberPoolBlocks to the LSMS must be supported on the baseObject (level 0) or from the lnpSubscriptions object with a non-empty filter.

The limit in scoping and functionality prevents the NPAC, SOA, and the LSMS systems from having to implement functionality or respond to large requests that are not necessary to support LNP over the mechanized interfaces.

4.2.2 Filtering

Filtering on the NPAC SMS is supported as defined in the GDMO. The NPAC SMS requires the Local SMS to support at a minimum the filter criteria specified below.

Limitations:

• OR and NOT filter support is not required for the Local SMS or SOA.

• NOT filter support is not required for the NPAC SMS.

• Filtering requests with a scope will not be issued to the Local SMS or SOA by the NPAC SMS for any object other than the subscriptionVersion and numberPoolBlock objects. No query will be used that requests both subscription versions and number pool blocks at the same time..

• All authorization rules apply to scoped and filtered operations. For example, a query for data that a service provider is not authorized to view will be failed with a reason of access denied.

• CMISSync is not supported for any scoped/filtered CMIP operation.

The following table shows the CMISE primitive filtering support required of the Local SMS by the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		32

Interface Functionality to CMIP Definition Mapping

Exhibit 6 — CMISE Primitive Filtering Support for Local System Objects

CMISE Primitives	Filter Supported	Notes
M-ACTION	N	No filtering is applied to the actions for the subscriptionVersion object.
M-GET	Y	TN Query with greaterOrEqual and lessOrEqual, and equality must be supported for auditing.
		The fields used with greaterOrEqual and lessOrEqual filters are subscriptionTN and subscriptionActivationTimeStamp.
		The field used with equality is subscriptionTN.
		Filters supported contain either a greaterOrEqual and lessOrEqual filter, or equality filter, for subscriptionTN only or a more complex filter.
		The more complex filter uses two criteria for filtering. The first criteria used is greaterOrEqual and lessOrEqual filters with subscriptionTN. The second criteria uses greaterOrEqual and lessOrEqual filters for subscriptionActivationTimeStamp. Both criteria must be matched for the data being queried (logical “and”).
		The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.
		Number Pool Block Query with greaterOrEqual and lessOrEqual, and equality for EDR support.
		The fields used with greaterOrEqual and lessOrEqual filters are numberPoolBlockNPA-NXX-X and numberPoolBlockActivationTimeStamp.
		The field used with equality is number PoolBlockNPA-NXX-X.
		Filters supported contain either a greaterOrEqual and lessOrEqual filter, or equality filter, for numberPoolBlockNPA-NXX-X only or a more complex filter.
		The more complex filter uses two criteria for filtering. The first criteria used is equality filter with numberPoolBlockNPA-NXX-X. The second criteria uses greaterOrEqual and lessOrEqual filters for numberPoolBlockActivationTimeStamp. Both criteria must be matched for the data being queried (logical “and”).
		The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		33

Interface Functionality to CMIP Definition Mapping

CMISE Primitives	Filter Supported	Notes
M-SET	Y	TN Modify with greaterOrEqual and lessOrEqual, and equality must be supported for Mass Update or TN range modify requests.
		The field used with greaterOrEqual and lessOrEqual filters is subscriptionTN.
		The fields used with equality are subscriptionTN and subscriptionNewCurrentSP.
		Filters supported contain either a greaterOrEqual and lessOrEqual filter, or equality filter, for subscriptionTN only, or a more complex filter.
		In the case of Modification of TNs for non-EDR number pool block the filter is more complex and uses two criteria for modification. The first criteria uses the subscriptionNewCurrentSP field with equality. The second criteria uses lessOrEqual and greaterOrEqual for subscriptionTN. Both criteria must be matched for the data being set (logical “and”). Additionally, a filter for LNP Type equal to ‘pool’ may be used.
		The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.
		Number Pool Block Modify with greaterOrEqual and lessOrEqual, and equality for EDR support.
		The field used with greaterOrEqual and lessOrEqual is numberPoolBlockNPA-NXX-X.
		The field used with equality is numberPoolBlockNPA-NXX-X.
		The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.
M-DELETE	Y	TN Delete with greaterOrEqual and lessOrEqual, and equality will be supported.
		The field used with greaterOrEqual and lessOrEqual filters is subscriptionTN.
		The field used with equality is subscriptionTN.
		The scope for the filter is level 1 only with a base managed object class of lnpSubscriptions.
		In the case of Deletion of TNs for non-EDR number pool block the filter is more complex and uses two criteria for deletion. The first criteria uses the subscriptionNewCurrentSP field with equality. The second criteria uses lessOrEqual and greaterOrEqual for subscriptionTN. Both criteria must be matched for the data being set (logical “and”). Additionally, a filter for LNP Type equal to ‘pool’ may be used.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		34

Interface Functionality to CMIP Definition Mapping

4.2.3 Action Scoping and Filtering Support

For messages sent to any object, the scope and filter will be checked to ensure it is appropriate for that object class.

• All M-ACTIONs that relate to subscriptions and number pool blocks are targeted to lnpSubscriptions.

• The ONLY filters allowed by the GDMO for lnpSubscriptions are “equality” and “present” for the single attribute lnpSubscriptionsName.

• If any one of the above M-ACTIONs is sent to a subscriptionVerisonNPAC or numberPoolBlockNPAC object you will get a “no such action” error response from that object.

• If you send a scoped/filtered M-ACTION whose scope includes objects of class subscriptionVersionNPAC or numberPoolBlockNPAC, you will receive an error “no such action” from each object specified by the filter.

4.3 lnpLocal-SMS-Name and lnpNPAC-SMS-Name Values

The following table (Exhibit 13) shows the values to be used for all currently identified NPAC regions for lnpNPAC-SMS-Name in the lnpNPAC-SMS object. The lnpLocal-SMS-Name for the lnpLocal-SMS object will be the service provider ID followed by a dash and the lnpNPA-SMS Name (e.g., 9999-Midwest Regional NPAC SMS).

Exhibit 13 — Defined lnpLocal-SMS-Name and lnpNPAC-SMS-Name Values

NPAC Customer Ids	NPAC SMS Region	lnpNPAC-SMS-Name
0000	Midwest	Midwest Regional NPAC SMS
0001	Mid-Atlantic	Mid-Atlantic Regional NPAC SMS
0002	Northeast	Northeast Regional NPAC SMS
0003	Southeast	Southeast Regional NPAC SMS
0004	Southwest	Southwest Regional NPAC SMS
0005	Western	West Regional NPAC SMS
0006	West Coast	West Coast Regional NPAC SMS
0007	Canada	Region8 NPAC Canada

4.4 OID Usage Information

4.4.1 OIDs Used for Bind Requests

Value	OID
CMIPUserInfo	2:1:1 (per standards and pp.49 IIS1.5)
CMIPAbortInfo	2:1:1 (per standards and pp.51 IIS1.5)
LnpAccessControl	{lnp-attribute 1} = 1:3:6:1:4:1:103:7:0:0:2:1
UserInfo (NpacAssociationInfo)	1:3:6:1:4:1:103:7:0:0:2:105
Application context	2:9:0:0:2 (per standards)

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		35

Interface Functionality to CMIP Definition Mapping

4.4.2 Other OIDs of Interest

Value	OID
AccessControl OID as part of a SMI notification	1:3:6:1:4:1:103:7:0:0:8:1
AccessControl as part of LNP notifications	{lnp-attribute 1} = 1:3:6:1:4:1:103:7:0:0:2:1

4.5 Naming Attributes

Non-zero values are not supported in the auto-instance naming attributes for Local Number Portability objects defined in the IIS.

4.6 Subscription Version M_DELETE Messages

M_DELETE commands are not sent for subscription versions set to old as a result of subsequent porting activity. M_DELETEs for subscription versions are only sent as a result of disconnect or port to original processing. Local SMS systems are responsible for deletion of the subscription versions in their Local SMS database due to the fact that some LSMS implementations may choose to retain old subscription versions in their database.

4.7 Number Pool Block M_DELETE Messages

M_DELETE commands are not sent for number pool blocks set to old as a result of subsequent porting activity. M_DELETEs for number pool blocks are only sent as a result of de-pool. Local SMS systems are responsible for deletion of the number pool blocks in their Local SMS database due to the fact that some LSMS implementations may choose to retain old number pool blocks in their database.

4.8 Subscription Version Queries

For Service Providers that support the enhanced SV Query functionality (Service Provider SV Query Indicator tunable parameter set to TRUE), the behavior is defined in this section.

If a subscription version query is requested by the SOA/LSMS, and the results are larger than the Maximum Subscription Query tunable value, the NPAC SMS will return subscription versions up to that max value. The SOA/LSMS would accept this message, then use it’s contents to send another query to the NPAC SMS, starting with the next TN, and so on until all SVs are returned to the SOA/LSMS. It will be up to the SOA/LSMS to manage the data returned from the NPAC SMS and determine the next request to send to the NPAC SMS in order to get the next set of subscription versions.

The NPAC SMS will continue to return subscription versions that meet the selection criteria. However, the NPAC SMS will not return a “count” to the SOA/LSMS for number of records that match the selection criteria. Service providers should modify their systems to support the following subscription version query operations to the NPAC SMS:

1. When data is returned from a subscription version query and there are exactly n (tunable) records returned, the SP must assume that they didn’t get all the data from their query.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		36

Interface Functionality to CMIP Definition Mapping

2.	After processing the first n records, they should send a new query that picks up where the data from the prior query ended.
3.	The subscription version data returned from the NPAC SMS for subscription version queries will be sorted by TN and then by subscription version ID so a filter can be created to pick up where the prior query ended.
4.	For example, if a SOA query to the NPAC SMS returns exactly 150 records and the last subscription version returned was TN ‘303-555-0150’ with subscription version ID of 1234. The filter used on the next query would be: All subscription versions where ((TN > 303-555-0150) OR (TN = 303-555-0150 AND subscription version ID > 1234).The NPAC SMS does support OR filters.
5.	Once the results from the NPAC SMS returns less than 150 records, the SP can assume they received all records in the requested query.
	Note: In this situation the NPAC SMS follows the linked replies for the subscription query results with an empty reply (this is an indication that the NPAC SMS is finished sending data for this request.

As an example, a Service Provider’s SOA sends a Subscription Version query to the NPAC SMS, There are 225 Subscription Versions that meet the selection criteria. Assuming the Maximum Subscription Query tunable value is set to 150 Subscription Versions, the SOA would receive data from the NPAC SMS in the form of 150 Subscription Versions in 150 linked replies (1 SV per linked reply) followed by a reply (for a total of 151 linked replies). The SOA would then send another query based on the algorithm described above. The SOA would then receive data from the NPAC SMS in the form of 75 Subscription Versions in 75 linked replies (1 SV per linked reply) followed by a reply (for a total of 76 linked replies).

Note: In this situation the NPAC SMS follows the linked replies for the subscription query results with an empty reply (this is an indication that the NPAC SMS is finished sending data for this request).

For Service Providers that DO NOT support the enhanced SV Query functionality (Service Provider SV Query Indicator tunable parameter set to FALSE), a complexityLimitation error is returned when the number of SVs in a query response exceed the Maximum Subscription Query tunable value.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		37

Secure Association Establishment

5 Secure Association Establishment

[Graphic Omitted: 5]

5.1 Overview

This section 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

The following access control information definition will be used in the AccessControl field of the association and CMIP PDUs to ensure a secure communication for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface:

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		38

Secure Association Establishment

LnpAccessControl ::= 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
	signature	[9]	BIT STRING
}
ServiceProvId ::= GraphicFixedString4
SystemID ::= CHOICE {
	serviceProvID [0] ServiceProvId,
	npac-sms [1] GraphicString60
}
SystemType ::= ENUMERATED {
	soa(0),
	local-sms(1),
	soa-and-local-sms(2), — value not supported
	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,
	dataDownload [2] NULL OPTIONAL
	notificationDownload [3] NULL OPTIONAL
}
LSMSUnits ::= SEQUENCE {
	dataDownload [0] NULL OPTIONAL,
	networkDataMgmt [1] NULL OPTIONAL,
	query [2] NULL OPTIONAL
}

Exhibit 4. Access Control

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		39

Secure Association Establishment

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 Service Provider ID. For the NPAC SMS, it is the unique identifier for the regional SMS.

In cases where a service provider is providing SOA services for an associated service provider, the primary service provider must establish the association with their System Id set to their primary Service Provider ID. PDUs that are subsequently sent to the NPAC SMS may contain the primary or associated Service Provider Ids of the requesting service provider. Associated Service Provider Ids are sent in the System Id when actions are being taken on behalf of an associated service provider by the service provider providing SOA services (the primary service provider). The Service Provider ID specified in the access control for PDUs sent after association establishment, whether it’s the primary or secondary Service Provider ID, is considered the requesting service provider and all validations will use this Service Provider ID.

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.

NPAC key lists and service provider key lists are to be managed based upon service provider id and presentations layer address (P-selector) of the service provider’s SOA system and/or Local SMS system. Also, a given service provider id and P-selector value can exist for one or more Network Service Access Points (NSAP).

The NPAC SMS must generate and maintain NPAC key lists based upon the service provider’s service provider id and P-selector value of the system(s) that support its SOA and LSMS interfaces. In addition, service providers(SOA systems and Local SMS systems) must also manage the NPAC’s key lists. Each side of the interface must support multiple NPAC key lists per service provider id and P-selector value.

Service providers (SOA system and Local SMS system) must generate and maintain key lists based upon the service provider’s service provider id and P-selector value of the system(s) that support its SOA and LSMS interfaces. Furthermore, the NPAC SMS must also manage the service provider’s key lists.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		40

Secure Association Establishment

Each side of the interface must support multiple service provider(SOA system and Local SMS) key lists per service provider id and P-selector value.

In cases where a service provider is providing SOA services for an associated service provider, key lists are only exchanged with the primary service provider using the primary service provider id.

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 variable between 600 and 2048 bits.

Since key lists are to be managed based upon service provider id and the P-selector value of a service provider’s SOA system and/or Local SMS system, keys are to be treated independently at the presentation layer for an association. By using presentation layer support of a key list, SOA and Local SMS systems can have one key or unique keys to support the SOA and LSMS interfaces. The following situations are supported:

1.	If a service provider has one process supporting the SOA and LSMS interface, then the process has one P-selector value supporting both interfaces. The SOA/Local SMS system would use the same key list and the same key for all associations created for the both the SOA and LSMS interface. The NPAC SMS would in turn have one NPAC key list and key to support both interfaces.
2.	If a service provider has two processes supporting the SOA and LSMS interface, then each process would have different P-selector values. The SOA and Local SMS systems would use separate key lists and keys per interface. In detail, the SOA system would use a key list and key for all associations involving the SOA interface and the Local SMS system would use a different key list and key for all associations involving the LSMS interface. The NPAC SMS would also manage separate key lists and keys per the SOA and LSMS interface. Furthermore, the NPAC SMS would use the same key list and key for all associations within a given interface.
3.	If a service provider has an SOA system or a Local SMS system that consists of multiple processes, then each processes would have different P-selector values. Therefore, each process would manage separate key lists and separate keys per process. The NPAC SMS would also manage separate key lists/keys per process. For example, if a Local SMS system consists of 2 processes (one process supporting subscription data and the other supporting network/query data), the processes would have separate P-selector values and use separate key lists/keys per association. The NPAC SMS would also manage separate key lists and keys per process within the LSMS interface.

Note: In cases where a service provider is providing SOA services for an associated service provider, keys are used from primary service provider key lists

If the service provider determines their key is compromised they should change their own private key and list. If the NPAC determines that their key is compromised then they should change their own private key and list. The NPAC should not invalidate a service provider’s key and vice versa. However, should

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		41

Secure Association Establishment

either side of the industry interfaces (SOA and Local SMS interface) change keys, the remote side is expected to mark the previously used key as used (key expiration). Previously used keys (ListId/KeyId combinations) are considered expired and result in a security violation across the industry interface when re-used.

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. The universal time format (YYYYMMDDHHMMSS.0Z) is used. In order to ensure data integrity and no-repudiation the NPAC SMS system must be synchronized to within five 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 its first message to the Local SMS would use sequence number 1 not sequence number 4.

5.2.1.8 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 and the associated bit mask value:

Exhibit 75 Association Functions

Association Function	Association Request Initiator	SOA	Local SMS
SOA Management (Audit and Subscription Version)		0x02
Classes:
lnpSubscriptions
numberPoolBlock
numberPoolBlockNPAC
subscriptionAudit
subscriptionVersion
subscriptionVersionNPAC

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		42

Secure Association Establishment

Association Function	Association Request Initiator	SOA		Local SMS
Service Provider and Network Data Management			0x02		0x04
Classes:
lnpNetwork
lnpNPAC-SMS
lnpServiceProvs
lsmsFilterNPA-NXX
serviceProv
serviceProvLRN
serviceProvNetwork
serviceProv-NPA-NXX
serviceProvNPA-NXX-X
LSMS Network and Subscription Data Download					0x08
Classes:
lnpNetwork
lnpSubscriptions
SOA Network Data Download			0x20
Classes:
LnpNetwork
Query Outbound from the NPAC SMS					0x10
Classes:
All
SOA Notifications (only applicable for SOAs supporting a separate notification association)			0x40
Classes:
lnpNPAC-SMS
lnpSubscriptions
numberPoolBlockNPAC
subscriptionAudit
subscriptionVersionNPAC

The association functions specified upon association are stored. Then all subsequent operations performed by that associations are then validated against that data to verify that they are ‘legal’. All outbound messages from the NPAC are also validated against the association functions and if a service provider does not have the correct masking set, they will not receive the transmission. 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.

SOA Notifications have been separated out to support SOAs that wish to implement a separate SOA Channel for Notifications. Based on the Service Provider tunable (SOA Notification Channel Service Provider Tunable), this function may be included in a SOA association, even if the Service Provider does not bind with that function mask. This allows SOA notifications to be sent down a single SOA channel.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		43

Secure Association Establishment

5.2.1.9 Recovery Mode

The recovery mode flag is set to TRUE when a Local SMS or SOA is establishing a connection after a downtime. This flag indicates to the NPAC SMS to hold all current transactions until the Local SMS or SOA sends the Recovery Complete action. Once an association is established in recovery mode by a Local SMS, the Local SMS should request service provider, subscription and network downloads and notifications that occurred during downtime. Once an association is established in recovery mode by a SOA, the SOA should request service provider and network downloads and notifications that occurred during downtime. After these steps are complete, the Local SMS or SOA should submit the Recovery Complete action. The NPAC SMS will respond to the recovery complete action, send all updates that occurred since association establishment and then normal processing will resume. See Appendix B, Section 7.1.

Service Provider Local SMS and SOA systems recover data independently. SOA systems can recover their information before, after, or concurrently with an LSMS using the same Service Provider Id.

A service provider providing SOA services for associated service providers can recover notifications for the primary and each associated service provider id prior to issuing the Recovery Complete action.

Alternatively, Service Provider Local SMS and SOA systems can recover data using the SWIM method. Refer to section 5.3.4 (Recovery) for more information.

5.2.1.10 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. Before hashing and encryptions, character fields are ASCII format and integer fields are 32 bit big endian. Encryption is done using RSA encryption using the key from the key list specified. Validation of this field ensures data integrity and non-repudiation of data. The following is additional information about how the information should be represented for digital signature encoding:

Field	Format	Contents
SystemID	ASCII
SystemType	Integer	e.g. local-sms = 1
UserId	ASCII
cmipDepartureTime	ASCII	“YYYYMMDDHHMMSS.OZ” format
sequenceNumber	Integer

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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		44

Secure Association Establishment

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.

When the SOA or LSMS initiate an association with the NPAC the NSAP and P-selector values will be validated to ensure that they are valid for the service provider initiating the association. 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 “9999.”

• 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 “9999”.

• The listId of 1.

• The keyId of 32.

• The current Local SMS GMT time in the cmipDepartureTime.

• A sequence number of 0.

• 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 LSMSUnit of Query 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:

• Ensure the systemId is present and valid for the association.

• Ensure the sequence number is 0.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		45

Secure Association Establishment

• Ensure 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)” {“soa-andlocal-sms(2)” value is to be removed from a future version of the IIS}.

If validation of the AARQ PDU fails then an A-ABORT will be issued by the NPAC SMS with an error of access denied. 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. Should either side of the interface change its listId/keyId values, both sides of the interface must mark the previously used keyId as used.

When the Local SMS receives the association response it validates the data received. The data is validated as follows:

• Ensure the systemId is present and valid for the association. (Note: the userId field is not required for Local SMS and NPAC SMS associations).

• Ensure the sequence number is 0.

• Ensure 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. If validation is successful then a 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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		46

Secure Association Establishment

following is an example of the information exchanged in the CMIP PDUs and the processing involved. Assume for the example:

• A SOA is making an association with the NPAC SMS.

• The SOA system provides SOA functionality for another Service Provider.

• The SOA systemId is “9999” for the primary Service Provider Id and is “8888” for an associated Service Provider 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 SOA 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 “8888.”

• 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 SOA), starts a tunable timer (with a default value of 2 minutes). If the timer expires before the M-GET CMISE service response is received then the SOA will regenerate the sequenceNumber, cmipDepartureTime and signature and resend the request. The SOA should resend a default of 3 times and abort the association if no response is received. If a response is received after the timeout period, it should be discarded. If an error message is received on a retry request, it should be evaluated to see if the request was processed or the error was received for other reasons. For example, an error of “duplicateObjectInstance” for an M-CREATE request most likely indicates a successful create.

When the NPAC SMS receives the M-GET request it validates the data received. The data is validated as follows:

• Ensure the systemId is present and valid for the association. For the SOA the systemId can be the primary or associated Service Provider Id depending on the requestor.

• Ensure the sequence number is the next sequence number expected. (In this case 1).

• Ensure the cmipDepartureTime is within 5 minutes of the current NPAC SMS time.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		47

Secure Association Establishment

• 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 back an M-GET Response to the SOA.

Since CMIP notifications (M-EVENT-REPORT) do not have access control fields, all notifications defined contain the access control information in the notification definition. ObjectCreation, ObjectDeletion, and AttributeValueChange should use the “information” attribute, which is an ANY DEFINED BY to contain the access control field. The values and authentication for the notification access control fields are the same as above. For range ObjectCreation and AttributeValueChange notifications the access control would not be placed in the information attribute but rather in the access control attribute defined. This would allow for the access control information to only be present once in the range notifications.

When the NPAC sends a notification, the destination service provider is uniquely identified in the distinguishedName of the M-EVENT-REPORT. The lnpLocalSMS-Name attribute value(2.17) is appended to the service provider’s id and is used to populate the value of the first element of the EventReportArgument’s managedObjectInstance distinguishedName. This allows primary service providers to distinguish notifications destined for themselves and for each secondary service provider.

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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		48

Secure Association Establishment

5.3 Association Management and Recovery

5.3.1 Establishing Associations

5.3.1.1 NpacAssociationUserInfo

The following structure will be used to report the status of a login attempt or the current state of the NPAC SMS:

NpacAssociationUserInfo ::= SEQUENCE {

error-code [0] IMPLICIT ErrorCode,

error-text [1] IMPLICIT GraphicString(SIZE(1..80))

 }

ErrorCode ::= ENUMERATED

 {

success (0),

access-denied (1)

retry-same-host (2)

try-other-host (3)

 }

Bind Requests and Responses

For AARQ (M-Bind requests) the NPAC SMS will be ignoring the CMIPUserInfo userInfo field. The SMASEUserInfo will be ignored by the NPAC SMS.

In order to validate a successful login, the AARE (M-Bind response) from the NPAC SMS will contain the NpacAssociationUserInfo as the “userInfo” field of the CMIPUserInfo that is contained on the AARE. The ErrorCode will be set to “success”.

The following structure will be used for CMIPUserInfo:

CMIPUserInfo ::= 2:9:1:1:4
—{joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1)
abstractSyntax(4)}

CMIPUserInfo ::= SEQUENCE {

protocolVersion [0] IMPLICIT ProtocolVersion
DEFAULT {version1-cmip-assoc},
functionalUnits [1] IMPLICIT FunctionalUnits DEFAULT {},
accessControl   [2] EXTERNAL OPTIONAL
userInfo            [3] EXTERNAL OPTIONAL

 }

5.3.1.2 Unbind Requests and Responses

The NPAC SMS will never be issuing the RLRQ (M-Unbind request), but will respond to them from the SOA or Local SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		49

Secure Association Establishment

5.3.1.3 Aborts

For unsuccessful logon attempts or situations where the NPAC SMS application must abort all associations, the ABRT CMIPAbortInfo structure’s “userInfo” will contain the NpacAssociationUserInfo structure. The ErrorCode will be set to one of the enumeration values.

The following structure will be used for CMIPAbortInfo:

CMIPAbortInfo ::= 2:9:1:1:4
—{joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1)
abstractSyntax(4)}

CMIPAbortInfo ::= SEQUENCE {

abortSource [0] IMPLICIT CMIPAbortSource,
userInfo [1] EXTERNAL OPTIONAL

 }

5.3.1.4 NPAC SMS Failover 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 ABRT and 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 ABRT and 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 ABRT and error code of TRY_OTHER_HOST. The secondary NPAC SMS will be responding by denying association requests with an ABRT and 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.5 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 ABRT and the ABRT is from the NPAC Application
{

switch (error code)
{

case ACCESS_DENIED
find out what is causing the error and fix it

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		50

Secure Association Establishment

     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”

     }
}
else
{

if the response was an ABRT and from the PROVIDER (not application)

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 abort an association at any time. Only the SOA and Local SMS can perform an RLRQ request. Once a scheduled outage has arrived, the NPAC SMS will abort associations (error code of “Try Other Host” or “Retry Same Host” depending on the type of outage).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		51

Secure Association Establishment

5.3.3	Error Handling
5.3.3.1	NPAC SMS Error Handling

The NPAC SMS will issue errors to the Local SMS and SOA interfaces based upon the definitions and mappings in Appendix A. The NPAC SMS expects the SOA and Local SMS to support the same error definitions when both issuing (with the exception of a sending processingFailure as defined in ILL 130) and receiving error responses for the operations each interface supports.

The NPAC SMS will attempt to interpret an error returned from a SOA or Local SMS. The NPAC SMS will log the error. If the request is not resent and the error response was returned from a Local SMS and related to a subscription version broadcast (M-CREATE or Create Action, M-DELETE, M-SET), a broadcast failure will be noted for the service provider on the subscription version. If a service provider does not have an active Local SMS association at the time of a broadcast, the broadcast will be automatically failed for the service provider.

The Local SMS and SOA are expected to recover themselves with the NPAC SMS when their association is reestablished. Thus it is the responsibility of the Local SMS and SOA to request the necessary data to rectify the failed transmission of M-EVENT-REPORTs, network data updates and non-broadcast oriented subscription version updates.

If the NPAC SMS sends a request to a Local SMS or SOA and receives no response from the CMISE service within the tunable period, the NPAC SMS will resend the message according to the tunable retry periods for the specific message type. If a response is received after the timeout period, it will be discarded. If the NPAC SMS receives no response, the NPAC SMS will assume the association is down and abort the connection. The Local SMS and SOA systems should assume the same behavior with the NPAC SMS.

5.3.3.2 Processing Failure Error

The NPAC SMS will use the Service Provider profile flags (SOA Action Application Level Errors Indicator, SOA Non-Action Application Level Errors Indicator, LSMS Action Application Level Errors Indicator, and LSMS Non-Action Application Level Errors Indicator) to determine the handling of Processing Failure errors. When they are not supported:

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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		52

Secure Association Establishment

!;

ASN.1 Definition

LnpSpecificInfo ::= GraphicString(SIZE(1..256))

When the Service Provider profile flags (SOA Application Level M-ACTION Errors Indicator, SOA Non-Action Application Level Errors Indicator, LSMS Application Level Errors M-ACTION Indicator, and LSMS Non-Action Application Level Errors) are supported, the Processing Failure error will contain an lnpSpecificErrorCode instead of lnpSpecificInfo.

5.3.3.3 NPAC SMS Detailed Error Codes

The NPAC SMS will issue detailed error codes to the supporting SOA and Local SMS interfaces based upon the definitions and mappings in Appendix A. The Service Provider profile flags (SOA Application Level Errors Indicator, LSMS Application Level Errors Indicator) will indicate whether application level errors are supported across the SOA/LSMS interfaces. When they are supported:

• The SOA/LSMS will utilize ACTIONs that support detailed error codes (e.g., M-ACTION subscriptionVersionActivateWithErrorCode), as defined in Exhibit 10. The SOA/LSMS may still utilize ACTIONs that do not support detailed error codes.

• All other CMIP messages (e.g., M-CREATE serviceProvNPA-NXX) will be supported through a processingFailure response that will contain the detailed error code, instead of the other CMIP standard errors.

This allows all messages to be covered for the detailed error codes for SOA/LSMS interfaces that support this features.

For SOA/LSMS interfaces that do not support this feature, an ACTION that supports error codes will result in a no-such-action error response.

5.3.4 Recovery

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 recover and resynchronize themselves with the NPAC SMS. One association should be established for recovery and no other associations should be established in normal mode until recovery is complete.

During the recovery processing, other messages may be generated at the NPAC SMS that are intended for the recovering SOA or LSMS. These messages are queued on the NPAC SMS until the SOA or LSMS finishes the recovery process and sends an lnpRecoveryComplete action to the NPAC SMS. Additionally, during the recovery process, the “x by y” retry functionality (where “x” is the number of attempts, and “y” is the interval in number of minutes in between attempts) continues on the NPAC SMS, but message sending is suspended to the SOA or LSMS, and the retry attempts counter is not decremented, as long as the SOA or LSMS is still in recovery mode. Therefore, a Subscription Version could stay in a “sending” status for a period of time longer than expected, since the retry logic will not transition the status to “partial failure” or “failed” as long as a Service Provider is in recovery mode.

While recovering subscription data, the NPAC SMS excludes Subscription Versions with a status of failed. The value in the Broadcast Timestamp field in each Subscription Version is used to determine whether or not a Subscription Version is included in the recovering LSMS’s requested criteria.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		53

Secure Association Establishment

The SOA or LSMS is capable of recovering data based on the association functions. The SOA recovers service provider, network data and notification data using the network data management association function (networkDataMgmt). The LSMS recovers notifications and subscription data using the data download association function (dataDownload), and recovers service provider and network data using the network data management association function (networkDataMgmt).

Service Provider and Notification recovery requests can only be sent to the NPAC when the SOA/LSMS is in recovery mode, otherwise an error message is returned.

NPAC data may be recovered in three ways, ‘time-based’, ‘record-based’, or ‘Send What I Missed (SWIM)-based’criteria. Based on the type of data being recovered, additional criteria may also be specified. The table below show the type of data that can be recovered, and the criteria that may be used for each type.

Data Type	Criteria	Additional Criteria
Network Data	Time Based	Time Range (consisting of Start time, End time)
	Record-Based	NPA-NXX range
		all NPA-NXX data
		NPA-NXX-X range
		all NPA-NXX-X data
		LRN range
		all LRN data
		all network data
	SWIM	conditional Action ID (indicating receipt of previous response for <Network> data)
Service Provider Data	Time Based	Time Range (consisting of Start time, End time)
	Record Based	Service Provider ID
		All Service Providers
	SWIM	conditional Action ID (indicating receipt of previous response for <Service Provider> data)
Subscription Data	Time-Based	Time Range (consisting of Start time, End time)
	Record-Based	TN
		TN range
	SWIM	conditional Action ID (indicating receipt of previous response for <Subscription> data)
Number Pool Block Data	Time-Based	Time Range (consisting of Start time, End time)
	Record-Based	NPA-NXX-X

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		54

Secure Association Establishment

Data Type	Criteria	Additional Criteria
		NPA-NXX-X range
	SWIM	conditional Action ID (indicating receipt of previous response for <Number Pool Block> data)
Notification Data	Time-Based	Time Range (consisting of Start time, End time)
	Record-Based	Not Available
	SWIM	Time Range (consisting of Start time, End Time) is ignored in a SWIM recovery request Conditional Action ID (indicating receipt of previous response for <Notification> data)

‘Time-Based’ Recovery Requests

All ‘time-based’ recovery requests specifying time range criteria are limited to the NPAC SMS tunable, “Maximum Download Duration”. When the SOA or LSMS issues a recovery request (whether Service Provider, Network, Subscription, Number Pool Block, or Notification Data) with time-based criteria, the NPAC SMS will compare the time range indicated in the request to the “Maximum Download Duration” tunable.

For service providers that do not support linked replies, Subscription data ‘time-based’ recovery requests specifying time range criteria are also limited to the number of TNs specified in the Service Provider specific tunable, “Maximum TN Download in Recovery Request”. Therefore, a valid request will fall within both the duration and quantity tunable values.

For service providers that do not support linked replies, Notification data ‘time-based’ recovery requests specifying time range criteria are also limited to the number of notifications specified in the NPAC SMS tunable, “Maximum Number of Download Notifications”. Therefore, a valid request will fall within both the duration and quantity tunable values.

For service providers that do not support linked replies, for all types of ‘time-based’ recovery requests, where the tunable value is exceeded, an appropriate error message is issued over the interface from the NPAC SMS to the originating system. This applies to both duration overages (“Maximum Download Duration”), and number of record overages (“Maximum TN Download in Recovery Request” for subscription data, and “Maximum Number of Download Notifications” for notification data).

‘Record-Based’ Recovery Requests

For service providers that do not support linked replies, all ‘record-based’ recovery requests specifying other criteria (for example, TN/TN range, NPA-NXX/NPA-NXX range) are limited by the number of records specified in the NPAC SMS tunable, “Maximum Number of Download Records”. When the SOA or LSMS issues a network data recovery request or the LSMS issues a subscription version data recovery request, using ‘record-based’ criteria, the NPAC SMS will compare the records indicated in the request to the “Maximum Number of Download Records” tunable. If the number of records exceeds this tunable value, an appropriate error message is issued over the interface from the NPAC SMS to the originating system.

‘SWIM-Based’ Recovery Requests

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		55

Secure Association Establishment

‘SWIM-based’ recovery requests allow for the recovery of service provider, network, subscription, number pool block, and notification data where the NPAC SMS replies to the originating SOA/LSMS with the missed data, by using linked replies. The NPAC SMS will keep track of messages destined for a SOA/LSMS that were NOT successfully responded to by the SOA/LSMS, when the service provider system supports SWIM recovery (SP Profile Flags, SOA SWIM Indicator = TRUE and LSMS SWIM Indicator = TRUE). Missed messages will be stored based on the limits of the SOA SWIM Maximum and LSMS SWIM Maximum tunables. SWIM based recovery requests can only be sent to the NPAC when the SOA/LSMS is in recovery mode, otherwise an error message is returned.

During SWIM based recovery, the SOA/LSMS issue recovery requests for each type of data, and the NPAC SMS will issue recovery responses based on the SP Profile flags for ranges, notification types and EDR for the missed messages and limit the responses by the respective Linked Reply Blocking Factor and Maximum Linked Recovered Object tunables for each data type. Each response from the NPAC SMS will contain a status and ACTION_ID. The status will be one of the following:

• Success

An NPAC SMS response that includes a status of Success indicates that SWIM recovery for the data type specified can be completed in either a single reply (with a status of Success and an ACTION_ID) or multiple linked replies (each with a status of Success and the same ACTION_ID in each reply, except for the last linked reply which will be empty – indicating the end of the linked reply data). In this case the Service Provider system must issue an M-EVENT-REPORT notification including the ACTION_ID in order for the NPAC SMS to clear the SWIM list for this data type and continue the recovery processing.

• Failed

An NPAC SMS response that includes a status of Failed indicates the NPAC failed to process the recovery request. An ACTION_ID is included, however the Service Provider system does not need to issue an M-EVENT-REPORT notification. The Service Provider system should re-start the recovery process with a new recovery request.

• No-Data-Selected

An NPAC SMS response that includes a status of No-Data-Selected indicates there isn’t SWIM data for the requested data type to recover. The response will include an ACTION_ID and the Service Provider system must issue an M-EVENT-REPORT notification including the ACTION_ID to continue the recovery processing.

• Swim-More-Data

An NPAC SMS response that includes a status of Swim-More-Data indicates that the SWIM recovery for the data type specified includes an amount of data greater than the Linked Reply Maximum and requires subsequent download request in order to recover all the data on the SWIM list.

When the Service Provider system receives an NPAC SMS ACTION response with linked replies that include an ACTION_ID and status of Swim-More-Data in each of the replies, the Service Provider system should issue a subsequent recovery request including this ACTION_ID. The NPAC SMS will issue an ACTION Response for the next set of data and clear the SWIM list for the (linked reply) data already downloaded and processed. This subsequent ACTION response from the NPAC SMS will include a new ACTION_ID (the same in each of the linked replies for this response) and a status of either Swim-More-Data in each reply or Success in each reply followed by an empty reply. The Service Provider system and the NPAC SMS

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		56

Secure Association Establishment

will continue this message exchange until the NPAC SMS ACTION Response indicates a status of Success (for each linked reply in that response).

After the Service Provider system receives an ACTION Response from the NPAC SMS indicating a status of Success and an ACTION_ID, the Service Provider system must issue an M-EVENT-REPORT notification including the most recent ACTION_ID in order for the NPAC SMS to clear this last set of (linked reply) data that was downloaded and processed, from the SWIM list for this data type and continue the recovery processing.

After the Service Provider system receives an ACTION Response from the NPAC SMS indicating a status of either Success or No-Data-Selected and an ACTION_ID, the Service Provider system must issue an M-EVENT-REPORT notification including the most recent ACTION_ID. The M-EVENT-REPORT reply from the NPAC SMS will contain one of the following responses:

• Success

An NPAC SMS M-EVENT-REPORT reply that includes a status of Success indicates that the recovery request has been completed for this data type and if there was data downloaded, that data has been cleared from the SWIM list.

• Failed With an Error Code

An NPAC SMS M-EVENT-REPORT reply that includes a status of Failed with an Error Code indicates that the recovery request failed and the Service Provider system should repeat recovery for that data type.

• Failed With an Error Code and a Stop-Date (timestamp)

An NPAC SMS M-EVENT-REPORT reply that includes a status of Failed with an Error Code and a stop-date (timestamp) indicates that the SWIM Maximum has been exceeded and the Service Provider’s SWIM indicator was changed from ON to OFF as of the time in the stop-date timestamp. The stop-date (timestamp), also indicates the time of the last SWIM entry onto the SWIM list. In this situation the Service Provider should perform further, ‘time-based’ recovery based upon the stop-date timestamp in order to recover all potentially missed messages for each data type they support. The Service Provider system may complete SWIM recovery for each data type and then request further time-based recovery for each data type:

For example:

SWIM (SP Data) – SWIM (Network Data) — SWIM (Subscription Data) –

SWIM (NPB Data) – SWIM (Notification Data)

– time-based (SP Data) – time-based (Network Data) – time-base (Subscription Data) – time-base (NPB Data) – time-based (Notification Data)

OR upon performing SWIM recovery and receiving the stop-date timestamp they may immediately perform time-based recovery for that same data type then SWIM based recovery for the next data type followed by time-based recovery for the same data type:

For example:

SWIM (SP Data) – time-based (SP Data) – SWIM (Network Data)

- time-based (Network Data)

etc.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		57

Secure Association Establishment

Service Providers can continue to use the existing recovery mechanism/messages to recover data between the SOA/LSMS and the NPAC, using the ‘time-based’ or ‘record-based’ methods. However, if the Service Provider supports SWIM recovery, it is important that they first recover using the SWIM criteria. When the Service Provider supports SWIM recovery, their SWIM list is not “cleared” until successful SWIM recovery occurs, thus recovering by either time-based or record-based criterion first and SWIM subsequently may cause data integrity issues.

Upon completion of recovery, the SOA/LSMS should issue an lnpRecoveryComplete message indicating the end of the missed data, and processing between the SOA/LSMS and NPAC SMS will resume normal mode.

5.3.4.1 Local SMS Recovery

To recover, 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 service provider, network, subscription and number pool block data downloads and the notifications that occurred during downtime. Once this is complete, the Local SMS should issue the lnpRecoveryComplete action to turn off the recoveryMode flag. After the NPAC SMS responds to the lnpRecovery Complete action it will send to the LSMS any other messages that have occurred since the association was established.

5.3.4.2 SOA Recovery

To recover, the SOA starts by setting the recoveryMode flag of the access control parameter. This flag signals the NPAC SMS to hold all data updates to this SOA. The SOA should then request the service provider, network data downloads and notifications that occurred during downtime. Once this is complete, the SOA should issue the lnpRecoveryComplete action to turn off the recoveryMode flag. After the NPAC SMS responds to the lnpRecovery Complete action it will send to the SOA any other messages that have occurred since the association was established.

5.3.4.3 Linked Action Replies during Recovery

Linked Reply functionality applies to Service Providers that have their SOA Linked Replies Indicator set to TRUE, or their Local SMS Linked Replies Indicator set to TRUE.

For service provider that support linked replies the Maximum TN Download in Recovery Request, the Maximum Number of Download Notifications and Maximum Number of Download Records tunables do not apply to recovery processing.

Linked replies will be returned as the response to an lnpDownload action request for network data if the number of messages returned exceeds the “Network Data Linked Reply Blocking Factor” tunable but is less than the “Network Data Maximum Linked Recovered Objects” tunable. If the number of network data objects to be returned exceeds the “Network Data Maximum Linked Recovered Objects” tunable, a “criteria-too-large” error will be returned to the requesting SOA/LSMS.

Linked replies will be returned as the response to an lnpDownload action request for subscription data if the number of objects returned exceeds the “Subscription

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		58

Secure Association Establishment

Data Linked Reply Blocking Factor” tunable but is less than the “Subscription Data Maximum Linked Recovered Objects” tunable. If the number of subscription data objects be returned exceeds the “Subscription Data Maximum Linked Recovered Objects” tunable, a “criteria-too-large” error will be returned to the requesting LSMS.

Linked replies will be returned as the response to an lnpDownload action request for Number Pool Block data if the number of objects returned exceeds the “Number Pool Block Data Linked Reply Blocking Factor” tunable but is less than the “ Number Pool Block Data Maximum Linked Recovered Objects” tunable. If the number of Number Pool Block data objects be returned exceeds the “ Number Pool Block Data Maximum Linked Recovered Objects” tunable, a “criteria-too-large” error will be returned to the requesting LSMS.

Linked replies will be returned as the response to an lnpNotificationRecovery action request for notification data if the number of notifications returned exceeds the “Notification Data Linked Reply Blocking Factor” tunable but is less than the “Notification Data Maximum Linked Recovered Notifications” tunable. If the number of notifications to be returned exceeds the “Notification Data Maximum Linked Recovered Notifications” tunable, a “criteria-too-large” error will be returned to the requesting SOA/LSMS.

As an example, a Service Provider’s SOA was down, and is now performing notification recovery. During the downtime, 90 notifications were issued. Assuming the Notification Blocking Factor is set to 50 notifications, the recovering SOA would receive data from the NPAC SMS in the form of three linked replies. The first reply would contain 50 notifications, the second reply would contain 40 notifications, and the third reply would be empty (this is an indication that the NPAC SMS is finished sending data for this recovery request). In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor, the M-ACTION response will be a normal response (i.e., non-linked response) and will not be a linked reply.

Below are the tunables that specify the download size:

Download Criteria	Tunable Name
Network data download request maximum linked reply size	Network Data Linked Replies Blocking Factor
Subscription download request maximum linked reply size	Subscription Data Linked Replies Blocking Factor
Number Pool Block download request maximum linked reply size	Number Pool Block Data Linked Replies Blocking Factor
Notification download request maximum linked reply size	Notification Data Linked Replies Blocking Factor
Total number of network data objects returned for a single download request	Network Data Maximum Linked Recovered Objects
Total number of subscription data objects returned for a single download request	Subscription Data Maximum Linked Recovered Objects
Total number of Number Pool Block data objects returned for a single download request	Number Pool Block Data Maximum Linked Recovered Objects
Total number of notification data notifications returned for a single download request	Notification Data Maximum Linked Recovered Objects

Linked replies will be returned as the response to an action request from the recovering SOA/LSMS. The entire operation is considered complete once all

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		59

Secure Association Establishment

linked replies and the final empty reply are returned as the response to the original request. Timeout processing is expected to start when the initial request is sent by the recovering SOA/LSMS, and terminate upon receipt of the final empty reply by the recovering SOA/LSMS.

5.4 Congestion Handling

The following sections define NPAC SMS behavior when in congestion and the NPAC handling of Local SMS and SOA congestion. The recommendation for Congestion Control follows the “Flow Control” mechanism and is described in OSI Communication Reference Model (ISO/IEC 7498). The two types of flow control defined are:

1.	Peer Flow Control
2.	Inter-Layer Flow Control

Peer Flow Control can be used when two peer layers of the OSI Stack talk to each other. The most common form of Peer Flow Control is the sliding window protocol. This protocol is implemented by TCP. This is the flow control approach used by the NPAC SMS.

5.4.1 NPAC SMS Congestion

Once the number of incoming messages to be queued to the NPAC SMS is exceeded at the transport layer, TCP/IP, an indication will be sent to the sender from the transport layer, TCP/IP, that congestion is occurring. Upon clearing of the congestion situation, the transport layer, TCP/IP will indicate to the sender that congestion has been cleared. As the receiver, the NPAC SMS application will not be aware that it is congested. The NPAC SMS application will be continually processing the information being sent as quickly as possible. Only the sender will be aware that the NPAC SMS is congested due to the fact that it can not send any more information to the NPAC SMS via the transport layer, TCP/IP. Implementation of functionality to handle NPAC congestion situations is at the discretion of SOA and LSMS vendors.

5.4.2 NPAC Handling of Local SMS and SOA Congestion

The NPAC SMS application must be able to handle congestion when attempting to send out a message to a SOA or LSMS system. When receiving indications of congestion via the transport layer from a SOA or LSMS the NPAC SMS application stops dispatching messages for the SPID (primary or associated) and SOA or LSMS interface that returned congestion. Note: If a SOA system returns congestion it will not affect the LSMS for the same service provider and vise versa. When the NPAC SMS stops dispatching messages to a congested SOA or LSMS, the retry attempts and retry timer values and the behavior associated with them apply to the messages not dispatched. The NPAC will abort the SOA or LSMS association once the retry attempts are exhausted. Any unacknowledged messages at the NPAC SMS application layer will be handled as failures as they are when an association is aborted today, for example for security reasons.

Once the NPAC SMS gets an indication via the transport layer that a SOA or LSMS system that was previously congested is ready to receive information, the NPAC SMS resumes sending of messages to that system. Note that the NPAC SMS will use the sequence number for the message it sends first that was the sequence number on the message that was sent when congestion indication was received. This is done since the SOA or LSMS system did not receive this message. If the sequence number were incremented this would cause the SOA or LSMS to abort the association due to the sequence number value being larger than expected. SOA and LSMSs should use

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		60

Secure Association Establishment

the same sequence number as well when communicating with the NPAC to prevent the NPAC from aborting the association due to the sequence number value being larger than expected.

5.4.3 Out-Bound Flow Control

Under normal conditions the NPAC SMS sends messages to the associated SOA/LSMS and the SOA/LSMS is able to keep up with the NPAC, and Flow Control is not encountered. However, under load conditions, the SOA/LSMS is not able to keep up with the messages sent from the NPAC SMS and Flow Control may be encountered.

For a SOA/LSMS that is currently in a normal state (not in Flow Control), the NPAC SMS monitors the number of outstanding, non-responsive messages sent to that system. If the number of outstanding, non-responsive messages is less than the Flow Control Upper Threshold (tunable value), NPAC sends the current message it is handling, and continues with normal processing. If the number of outstanding, non-responsive messages is equal to the Flow Control Upper Threshold tunable, the NPAC sends the current message it is handling, and sets the Flow Control flag to TRUE. In this situation Flow Control is encountered.

During Flow Control the NPAC SMS verifies the Flow Control flag setting for the destination SOA/LSMS to determine if it’s OK to send each message. If the flag is FALSE, the message is sent; if the flag is TRUE the message is held/queued. In a Flow Control state, the NPAC SMS monitors the number of outstanding, non-responsive messages sent to that SOA/LSMS. If the number of outstanding, non-responsive messages is greater than the Flow Control Lower Threshold, no action is taken. When the number of outstanding, non-responsive messages is less than or equal to the Flow Control Lower Threshold (tunable value), the NPAC SMS resumes sending messages (whether queued or normal). A SOA/LSMS that is in a Flow Control state will have outstanding, non-responsive messages. For all outstanding, non-responsive messages that were sent, NPAC response timers and abort behavior will apply. For all messages NOT sent but held because the Flow Control flag is set to TRUE, NPAC response timers and abort behavior will NOT apply.

Flow Control is implemented on the NPAC SMS side of the CMIP interface and it is optionally implemented on the SOA/LSMS. The implementation of Flow Control by the sending system is independent of any implementation of Flow Control by the receiving system and is applicable on a per association basis. Flow Control applies to both normal mode and recovery mode and is applicable for service provider, network, number pool block, subscription version and notification data.

5.5 Abort Processing Behavior

The NPAC exchanges messages with the SOA/LSMS. For every request from the NPAC, a response is required from the SOA/LSMS. A SOA/LSMS that fails to respond to a message is subject to Abort Processing Behavior (APB).

The NPAC sends messages to the associated SOA/LSMS. For every message sent, abort behavior is initiated, and a Roll-Up Activity (RAT) timer is started. The initial abort timer is based on existing retry functionality. The RAT timer is either the Roll-Up Activity-Single (RAT Single) tunable value or the Rollup Activity Timer Expire SVRange (RAT Range) tunable value. The secondary abort timer is the Abort Processing Behavior Upper Threshold tunable window. The NPAC allows a SOA/LSMS to fall behind in processing messages. However, the limit is defined by the Abort Processing Behavior Upper Threshold tunable window, upon which when this value is reached the association is aborted.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		61

Secure Association Establishment

The NPAC SMS “rolls-up” downloaded data (e.g. SV activate to LSMSs) to reflect the status of porting activity. Abort behavior and roll-up behavior are separate items, but often confused because both can happen at the same time when a timer expires.

During message exchange between the NPAC SMS and the SOA/LSMS the response from the SOA/LSMS is one or more of the options below, based on the tunable settings:

• All SOAs/LSMSs respond to the NPAC SMS message before the end of the retry window and RAT timer expiration.

o In this instance the NPAC SMS expires the RAT timer for that event and with a successful response, the NPAC SMS considers the responding SOA/LSMS as “successful” to the request (e.g. the SPID is not placed on the Failed-SP List).

• All SOAs/LSMSs do NOT respond to the NPAC SMS before the end of the retry window (e.g. end of the “X by Y” window).

o The retry timer has expired based on the applicable retry value. The NPAC SMS determines if any messages/responses were received from this SOA/LSMS during the retry window.

§ If at least one message/response is received from the SOA/LSMS, processing continues.

• All SOAs/LSMSs do NOT respond to the NPAC SMS before the end of the RAT timer expiration. The RAT timer has expired based on the applicable value (either single or range).

o The NPAC SMS performs “roll-up” activities for all messages sent to the SOAs/LSMSs on this event (status is set, Failed-SP List(s) is updated appropriately and notifications are sent to respective SOAs).

• SOA/LSMS responds to the NPAC SMS AFTER the expiration of the RAT timer.

o The NPAC SMS updates status/Failed-SP List, and sends notifications to respective SOAs.

• SOA/LSMS does NOT respond to the NPAC SMS before the end of the secondary abort (Abort Processing Behavior Upper Threshold tunable) window.

o The NPAC SMS aborts the association to the SOA/LSMS and the SOA/LSMS must re-associated to the NPAC SMS.

o The SOA/LSMS goes through recovery processing (recovery based on SOA/LSMS linked replies indicator) and the NPAC SMS updates the status/Failed-SP List, and sends notifications to the SOAs.

Abort processing behavior applies to both normal and recovery modes. Service provider, network, number pool block, subscription version and notification messages are subject to Abort processing behavior.

5.6 Single Association for SOA/LSMS

A SOA/LSMS system may connect to the NPAC SMS with one association for the same function (same bit mask). The NPAC SMS will abort any previous associations that use that same function.

5.7 Separate SOA Channel for Notifications

A SOA system may connect to the NPAC SMS with multiple SOA channels (i.e., associations) for different functions (different bit masks), specifically request/response

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		62

Secure Association Establishment

data versus notification data. The NPAC SMS will distribute transactions across these SOA associations based on functionality (different bit masks). This allows for additional throughput for the SOA as a result of two associations.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		63

GDMO Definitions

6 GDMO Definitions

[Graphic Omitted: 6]

The latest version of the GDMO interface definitions (lnp.mo_v_3_3_1_2005_10_13.txt) is available on the NPAC website (www.npac.com, under the documents section).

The current interface messaging can use one of the following two sets of message files found on the NPAC website:

1. The v_3_3_1, 10/13/05 ASN.1, 10/13/05 GDMO, and NANC-399-XML.txt.

2. The v_3_3_0, 5/27/05 ASN.1, and 5/27/05 GDMO.

Either set is valid when interfacing with the NPAC. The 10/13/05 version contains minor behavior comment changes, as well NANC 399 SVType and OptionalData fields. However, NANC 399 fields are currently inactive in each NPAC Region.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		64

General ASN.1 Definitions

7 General ASN.1 Definitions

[Graphic Omitted: 7]

The latest version of the LNP ASN.1 Object Identifier definitions (lnp.asn_v_3_3_1_2005_10_13.txt) is available on the NPAC website (www.npac.com, under the documents section).

The current interface messaging can use one of the following two sets of message files found on the NPAC website:

1. The v_3_3_1, 10/13/05 ASN.1, 10/13/05 GDMO, and NANC-399-XML.txt.

2. The v_3_3_0, 5/27/05 ASN.1, and 5/27/05 GDMO.

Either set is valid when interfacing with the NPAC. The 10/13/05 version contains minor behavior comment changes, as well NANC 399 SVType and OptionalData fields. However, NANC 399 fields are currently inactive in each NPAC Region.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		65

LNP XML Schema

8 LNP XML Schema

[Graphic Omitted: 8]

The latest version of the LNP XML schema (NANC-399-XML.txt) is available on the NPAC website (www.npac.com, under the documents section).

The current interface messaging can use one of the following two sets of message files found on the NPAC website:

1. The v_3_3_1, 10/13/05 ASN.1, 10/13/05 GDMO, and NANC-399-XML.txt.

2. The v_3_3_0, 5/27/05 ASN.1, and 5/27/05 GDMO.

Either set is valid when interfacing with the NPAC. The 10/13/05 version contains minor behavior comment changes, as the well NANC399 SV Type and OptionalData fields. However, NANC 399 fields are currently inactive in each NPAC Region

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		66

Subscription Version Status

9 Subscription Version Status

[Graphic Omitted: 9]

[Graphic Omitted: Version Creation – Version Death]

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
1	Conflict to Canceled	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 calendar days.
		SOA to NPAC SMS Interface or NPAC Operations Interface — NPAC Personnel	The old Service Provider User (or NPAC personnel acting on behalf of the Service Provider) sends a cancellation request for a Subscription Version created by that Service Provider with a status of conflict that has not been concurred by the other new Service Provider.
2	Conflict to Cancel Pending	NPAC Operations Interface — NPAC Personnel	User cancels a Subscription Version in conflict or cancels a Subscription Version that was created by or concurred to by both Service Providers.
		SOA to NPAC SMS Interface	User sends a cancellation request for a Subscription Version that was created by or concurred to by both Service Providers.
3	Cancel Pending to Conflict	NPAC Operations Interface — NPAC Personnel	User sets a Subscription Version with a status of cancel pending to conflict.
		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 new Service Provider within a tunable timeframe.
4	Conflict to Pending	NPAC Operations Interface — NPAC Personnel and SOA to NPAC SMS Interface — Old Service Provider	User removes a Subscription Version from conflict.
		SOA to NPAC SMS Interface — New Service Provider	New Service Provider User removes a Subscription Version from conflict. This action can only occur if a tunable number of hours have elapsed since the Subscription Version was placed in conflict.
5	Pending to Conflict	NPAC Operations Interface — NPAC Personnel	1.    User sets a Subscription Version with a status of pending to 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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		67

Subscription Version Status

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
		SOA to NPAC SMS Interface — Old Service Provider	Old Service Provider sends a Subscription Version creation or modification request for a Subscription Version with a status of pending, which revokes the old Service Provider’s authorization for transfer of service. This action can only be taken once, and must be taken a tunable number of hours prior to the new Service Provider due date.
6	Pending to Canceled	NPAC Operations Interface — NPAC Personnel	User cancels a Subscription Version with a status of pending that has not been concurred by both service providers.
		SOA to NPAC SMS Interface	Service Provider User sends a cancellation request for a Subscription Version created by that Service Provider with a status of pending that has not been concurred by the other Service Provider.
		NPAC SMS Internal	1.    NPAC SMS automatically sets a pending Subscription Version to canceled 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 canceled if an activation request is not received a tunable amount of time after new Service Provider due date.
7	Pending to Cancel Pending	NPAC Operations Interface — NPAC Personnel	User cancels a Subscription Version with a status of pending that has been created/concurred by both Service Providers.
		SOA to NPAC SMS Interface	Service Provider User sends a cancellation request for a Subscription Version with a status of pending that has been concurred by the other Service Provider.
8	Cancel Pending to Canceled	NPAC SMS Internal	NPAC SMS automatically sets a cancel pending Subscription Version to canceled after receiving cancel pending acknowledgment from the concurring Service Provider, or the final cancellation concurrence window has expired without cancel concurrence from the old Service Provider.
9	Creation - Set to Conflict	NPAC Operations Interface — NPAC Personnel	User creates a Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.
		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.
10	Creation - Set to Pending	NPAC Operations Interface — 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 # 9, Creation — Set to Conflict, NPAC Operations Interface.
		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 # 9, Creation — Set to Conflict, SOA to NPAC SMS Interface.
11	Disconnect Pending to Sending	NPAC SMS Internal	NPAC SMS automatically sets a deferred disconnect pending Subscription Version to sending after the effective release date is reached.
12	Cancel Pending to Pending	SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface	Service Provider User sends an un-do cancel-pending request for a Subscription Version with a status of cancel-pending for which the same Service Provider previously issued a cancel request.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		68

Subscription Version Status

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
13	Pending to Sending	NPAC Operations Interface — NPAC Personnel	User activates a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.
		SOA to NPAC SMS Interface — New Service Provider	New Service Provider User sends an activation message for a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.
14	Sending to Failed	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from sending to failed after all Local SMSs fail Subscription Version activation after the tunable retry period expires.
15	Failed to Sending	NPAC Operations Interface — NPAC Personnel	User re-sends a failed Subscription Version.
16	Partially Failed to Sending	NPAC Operations Interface — NPAC Personnel	User re-sends a partial failure Subscription Version.
17	Sending to Partially Failed	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 after the tunable retry period expires.
18	Sending to Old	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. Disconnects that fail on one or more, but not all, Local SMSs will also be set to old.
19	Sending to Active	NPAC SMS Internal	1.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version activation is successful in all of the Local SMSs.
			2.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version modification is successfully broadcast to any of the Local SMSs after all have responded.
			3.    NPAC SMS automatically sets a sending Subscription Version to active after a failure to all Local SMSs on a disconnect.
20	Active to Sending	NPAC Operations Interface — NPAC Personnel	User disconnects an active Subscription Version and does not supply an effective release date, or User modifies an active Subscription Version or resends a failed disconnect or modify.
		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, or User modifies an active Subscription Version.
21	Active to Old	NPAC SMS Internal	NPAC SMS automatically sets the currently active Subscription Version to old once a currently active subscription version is superceded by a pending subscription version, due to the fact that the current version is set to old when an activate occurs. The new pending version is set to sending and then to active, partially failed, or old. On a disconnect the sending state occurs before the old.
22	Disconnect Pending to Active	NPAC Operations Interface — NPAC Personnel	User cancels a Subscription Version with a disconnect pending status.
		SOA to NPAC SMS Interface — New Service Provider	User sends a cancellation request for a disconnect pending Subscription Version.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		69

Subscription Version Status

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
23	Active to Disconnect Pending	NPAC Operations Interface — NPAC Personnel	User disconnects an active Subscription Version and supplies a future effective release date.
		SOA to NPAC SMS Interface — Current Service Provider	User sends a disconnect request for an active Subscription Version and supplies a future effective release date.
24	Old to Sending	NPA Operations Interface – NPAC Personnel	User re-sends a partial failure of a disconnect or partial failure or failure of a port-to-original Subscription Version.
25	Old to Old	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from old to old after one or more previously failed Local SMSs successfully disconnect a Subscription Version, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
26	Partially Failed to Active	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from partial failure to active after all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
27	Partially Failed to Partially Failed	NPAC SMS Internal	NPAC SMS automatically sets a Subscription Version from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		70

Number Pool Block Status

10 Number Pool Block Status

[Graphic Omitted: 10]

[Graphic Omitted: Number Pool Block Flow]

In the following table, the reference to “Number Pool Block” data when broadcasting to an LSMS is based on that Service Provider’s EDR Indicator (i.e., Number Pool Block object or Subscription Versions with LNP Type of POOL).

Number Pool Block Version Status Interaction Descriptions
#	Interaction Name	Type	Description
1	Creation - Set to Sending	NPAC SMS Internal	NPAC SMS creates a Number Pool Block for the Block Holder Service Provider.
		NPAC Operations Interface — NPAC Personnel	User sends a Number Pool Block creation request for the Block Holder Service Provider.
		SOA to NPAC SMS Interface — Block Holder Service Provider	The Service Provider User sends a Number Pool Block creation request for itself (the Block Holder Service Provider).
2	Sending to Partial Failure	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from sending to partial failure after one or more, but not all, of the Local SMSs fail the Number Pool Block activation after the tunable retry period expires.
3	Partial Failure to Sending	NPAC Operations Interface — NPAC Personnel	User re-sends a partial failure Number Pool Block.
4	Sending to Failed	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from sending to failed after all Local SMSs fail Number Pool Block activation after the tunable retry period expires.
5	Failed to Sending	NPAC Operations Interface — NPAC Personnel	User re-sends a failed Number Pool Block.
6	Sending to Active	NPAC SMS Internal	1. NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block activation is successful in all of the Local SMSs.
			2. NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block modification is broadcast to all of the Local SMSs and either all have responded or retries have been exhausted.
			3. NPAC SMS automatically sets a sending Number Pool Block to active after a failure to all Local SMSs on a de-pool.
7	Active to Sending	NPAC Operations Interface — NPAC Personnel	1. User de-pools an active Number Pool Block. 2. User modifies an active Number Pool Block.
			3. User resends a failed de-pool or modify Number Pool Block.
		SOA to NPAC SMS Interface — Block Holder Service Provider	User modifies an active Number Pool Block.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		71

Number Pool Block Status

Number Pool Block Version Status Interaction Descriptions
#	Interaction Name	Type	Description
8	Sending to Old	NPAC SMS Internal	1. NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool to all Local SMSs successfully completes.
			2. NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool that fails on one or more, but not all Local SMSs.
9	Old to Sending	NPA Operations Interface – NPAC Personnel	User re-sends a partial failure of a de-pool.
10	Partial Failure to Partial Failure	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
11	Partial Failure to Active	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from partial failure to active after all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.
12	Old to Old	NPAC SMS Internal	NPAC SMS automatically sets a Number Pool Block from old to old after one or more previously failed Local SMSs successfully de-pools a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3: © 1997 — 2006 NeuStar, Inc.		72

NPAC SMS
INTEROPERABLE INTERFACE SPECIFICATION

APPENDICES A AND B

NANC Version 3.3.2a

Prepared for:
The North American Numbering Council (NANC)

March 9, 2006

Release 3.3: © 1997 — 2006 NeuStar, Inc.

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.

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.

Table Of Contents

Table Of Contents

Introduction	1
A.1 CMISE Primitive Errors	2
A.2 CMISE Primitive Error Descriptions	2
A.3 CMIP Error Mapping to NPAC SMS Errors	4
B.1 Overview	23
B.2 Audit Scenarios	24
B.2.1 SOA Initiated Audit	24
B.2.1.1 SOA Initiated Audit (continued)	25
B.2.2 SOA Initiated Audit Cancellation by the SOA	26
B.2.3 SOA Initiated Audit Cancellation by the NPAC	27
B.2.4 NPAC Initiated Audit	28
B.2.5 NPAC Initiated Audit Cancellation by the NPAC	30
B.2.6 Audit Query on the NPAC	31
B.2.7 SOA Audit Create for Subscription Versions within a Number Pool Block (previously NNP flow 6.1)	32
B.2.7.1 SOA Creates and NPAC SMS Starts Audit (previously NNP flow 6.1.1)	32
B.2.7.2 NPAC SMS Performs Audit Comparisons for a SOA initiated Audit including a Number Pool Block (previously NNP flow 6.1.2)	34
B.2.7.3 NPAC SMS Reports Audit Results (previously NNP flow 6.1.3)	35
B.2.8 NPAC SMS Audit Create for Subscription Versions Within a Number Pool Block (previously NNP flow 6.2)	36
B.2.8.1 NPAC SMS Creates and Starts Audit (previously NNP flow 6.2.1)	36
B.2.8.2 NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block (previously NNP flow 6.2.2)	37
B.3 Service Provider Scenarios	38
B.3.1 Service Provider Creation by the NPAC	38
B.3.2 Service Provider Deletion by the NPAC	39
B.3.3 Service Provider Modification by the NPAC	40
B.3.4 Service Provider Modification by the Local SMS	41
B.3.5 Service Provider Modification by the SOA	42
B.3.6 Service Provider Query by the Local SMS	43
B.3.7 Service Provider Query by the SOA	44
B.4 Service Provider Network Data Scenarios	45
B.4.1 NPA-NXX Scenarios	45
B.4.1.1 NPA-NXX Creation by the NPAC	45
B.4.1.2 NPA-NXX Deletion by the NPAC	46
B.4.1.3 NPA-NXX Creation by the Local SMS	47
B.4.1.4 NPA-NXX Creation by the SOA	48
B.4.1.5 NPA-NXX Deletion by the Local SMS	49
B.4.1.6 NPA-NXX Deletion by SOA	50
B.4.1.7 NPA-NXX Query by the Local SMS	51
B.4.1.8 NPA-NXX Query by the SOA	52
B.4.2 LRN Scenarios	53
B.4.2.1 LRN Creation by the NPAC	53
B.4.2.2 LRN Creation by the SOA	54
B.4.2.3 LRN Deletion by the SOA	55

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.	i

Table Of Contents

B.4.2.4 LRN Query by the SOA	56
B.4.2.5 LRN Deletion by the NPAC	57
B.4.2.6 LRN Creation by the Local SMS	58
B.4.2.7 LRN Deletion by the Local SMS	59
B.4.2.8 LRN Query by the Local SMS	60
B.4.2.9 Network Data Download	61
B.4.2.10 Scoped/Filtered GET of Network Data	62
B.4.2.11 Scoped/Filtered GET of Network Data from SOA	63
B.4.3 Service Provider NPA-NXX-X	64
B.4.3.1 Service Provider NPA-NXX-X Create by NPAC SMS (previously NNP flow 1.1)	64
B.4.3.1.1 Service Provider NPA-NXX-X Create by NPAC SMS (continued)	66
B.4.3.2 Service Provider NPA-NXX-X Modification by NPAC SMS (previously NNP flow 1.2)	67
B.4.3.3 Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence (previously NNP flow 1.3)	68
B.4.3.4 Service Provider NPA NXX X Query by SOA or LSMS (previously NNP flow 1.4)	69
B.4.4 Number Pool Block	70
B.4.4.1 Number Pool Block Create/Activate by SOA (previously NNP flow 2.1)	70
B.4.4.2 Number Pool Block Create by NPAC SMS (previously NNP flow 2.2)	73
B.4.4.3 Number Pool Block Create Broadcast Successful to Local SMS (previously NNP flow 2.3.1)	75
B.4.4.4 Number Pool Block Create: Successful Broadcast (previously NNP flow 2.3.2)	76
B.4.4.5 Number Pool Block Create Broadcast to Local SMS: Failure (previously NNP flow 2.4)	77
B.4.4.6 Number Pool Block Create Broadcast to Local SMS: Partial Failure (previously NNP flow 2.5.1)	78
B.4.4.7 Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates (previously NNP flow 2.5.2)	79
B.4.4.8 Number Pool Block Create Resend Broadcast (previously NNP flow 2.6)	80
B.4.4.9 Number Pool Block Create Successful Resend Updates (previously NNP flow 2.7)	81
B.4.4.10 Number Pool Block Create Failed Resend NPAC SMS Updates (previously NNP flow 2.8)	82
B.4.4.11 Number Pool Block Create Partial Failure Resend NPAC SMS Updates (previously NNP flow 2.9)	83
B.4.4.12 Number Pool Block Modify by NPAC SMS (previously NNP flow 2.10)	84
B.4.4.13 Number Pool Block Modify by Block Holder SOA (previously NNP flow 2.11)	86
B.4.4.14 Number Pool Block Modify Successful Broadcast to Local SMS Success (previously NNP flow 2.12.1)	88
B.4.4.15 Number Pool Block Modify Successful Broadcast NPAC SMS Updates (previously NNP flow 2.12.2)	89
B.4.4.16 Number Pool Block Modify Broadcast to Local SMS Failure (previously NNP flow 2.13)	90
B.4.4.17 Number Pool Block Modify Partial Failure Broadcast to Local SMS (previously NNP flow 2.14.1)	91
B.4.4.18 Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.14.2)	92
B.4.4.19 Number Pool Block Modify Resend Broadcast (previously NNP flow 2.15)	93
B.4.4.20 Number Pool Block Modify Successful Resend Updates (previously NNP flow 2.16)	94
B.4.4.21 Number Pool Block Modify Failure Resend Updates (previously NNP flow 2.17)	95
B.4.4.22 Number Pool Block Modification of SOA Origination Indicator (previously NNP flow 2.18)	96
B.4.4.23 Number Pool Block De Pool by NPAC SMS (previously NNP flow 2.19)	97
B.4.4.24 Number Pool Block De Pool Successful Broadcast of Subscription Version and Number Pool Block Deletes (previously NNP flow 2.20.1)	98
B.4.4.25 Number Pool Block De Pool Broadcast Successful NPA-NXX-X Updates (previously NNP flow 2.20.2)	99
B.4.4.26 Number Pool Block De Pool Broadcast to Local SMS Failure (previously NNP flow 2.21)	100
B.4.4.27 Number Pool Block De Pool Partial Failure Broadcast to Local SMS of Subscription Versions and Number Pool Block (previously NNP flow 2.22.1)	101
B.4.4.28 Number Pool Block De Pool Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.22.2)	102
B.4.4.29 Number Pool Block De Pool Resend Broadcast (previously NNP flow 2.23)	103
B.4.4.30 Number Pool Block De Pool Successful Resend Updates (previously NNP flow 2.24)	104

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.	ii

Table Of Contents

B.4.4.31 Number Pool Block De Pool Resend Failure Updates (previously NNP flow 2.25)		105
B.4.4.32 Number Pool Block De Pool Resend Partial Failure Updates (previously NNP flow 2.26)		106
B.4.4.33 Number Pool Block Query by SOA or LSMS (previously NNP flow 2.27)		107
B.5 SubscriptionVersion Flow Scenarios		108
B.5.1 SubscriptionVersion Create Scenarios		108
B.5.1.1 Subscription Version Create by the Initial SOA (Old Service Provider)		109
B.5.1.1.1 Subscription Version Create by the Initial SOA (Old Service Provider) (continued)		111
B.5.1.2 SubscriptionVersion Create by the Initial SOA (New Service Provider)		112
B.5.1.2.1 Subscription Version Create by the Initial SOA (New Service Provider) (continued)		114
B.5.1.3 SubscriptionVersion Create by Second SOA (New Service Provider)		115
B.5.1.4 SubscriptionVersion Create by Second SOA (Old Service Provider) with Authorization to Port		117
B.5.1.5 SubscriptionVersion Activated by New Service Provider SOA		119
B.5.1.6 Active SubscriptionVersion Create on Local SMS		120
B.5.1.6.1 Active Subscription Version Create on Local SMS Using Create Action		121
B.5.1.6.2 SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window		122
B.5.1.6.3 SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window		123
B.5.1.6.4 Subscription Version Create: Failure to Receive Response from New SOA		124
B.5.1.6.5 SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window		125
B.5.1.7 SubscriptionVersionCreate M CREATE Failure to Local SMS		127
B.5.1.8 SubscriptionVersion M CREATE: Partial Failure to Local SMS		128
B.5.1.9 Create Subscription Version: Resend Successful to Local SMS Action		129
B.5.1.10 Subscription Version: Resend Failure to Local SMS		130
B.5.1.11 SubscriptionVersion Create for Intra Service Provider Port		131
B.5.1.12 SubscriptionVersion for Inter and Intra Service Provider Port-to-Original: Successful		134
B.5.1.12.1 Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)		135
B.5.1.12.2 Intra-Service Provider Subscription Version Port-to-Original: Successful (continued)		136
B.5.1.13 SubscriptionVersion for Inter and Intra Service Provider Port-to-Original: All LSMSs Fail	137
B.5.1.13.1 Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)		138
B.5.1.13.2 Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)		139
B.5.1.14 SubscriptionVersion for Inter and Intra Service Provider Port-to-Original: Partial Failure		140
B.5.1.14.1 Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)		141
B.5.1.14.2 Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)		142
B.5.1.15 SubscriptionVersion Port-to-Original: Resend		143
B.5.1.15.1 Subscription Version Port-to-Original: Resend (continued)		144
B.5.1.16 SubscriptionVersion Port-to-Original: Resend Failure to Local SMS		145
B.5.1.16.1 SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)		146
B.5.1.17 Port-to-Original Subscription Version Flows for Pooled TNs		147
B.5.1.17.1 Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA (previously NNP flow 3.1.1)		147
B.5.1.17.2 Successful Broadcast of Port-to-Original Activation Request for a Pooled TN (previously NNP flow 3.1.2)		149
B.5.1.17.3 Successful Broadcast Complete NPAC SMS Updates for a Port-to-Original Request for a Pooled TN (previously NNP flow 3.1.3)		150
B.5.1.17.4 Subscription Version Create Port-to-Original of a Pool TN: Failure Broadcast to All Local SMSs (previously NNP flow 3.2.1)		151
B.5.1.17.5 Updates to NPAC SMS after Failure of Port-to-Original Broadcast for a Pooled TN (previously NNP flow 3.2.2)		152
B.5.1.17.6 Port-to-Original Activation Partial Failure Broadcast of a Pooled TN (previously NNP flow 3.3.1)		153
B.5.1.17.7 Partial Failure Broadcast Complete NPAC SMS Updates of a Port-to-Original for a Pooled TN (previously NNP flow 3.3.2)		154

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.	iii

Table Of Contents

B.5.1.17.8 Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN (previously NNP flow 3.4.1)	155
B.5.1.17.9 Successful Resend Broadcast of a Port-to-Original of a Pooled TN (previously NNP flow 3.4.2)	156
B.5.1.17.10 Updates to NPAC SMS after Successful Resend of Port to Original Request of a Pooled TN (previously NNP flow 3.4.3)	157
B.5.1.17.11 Subscription Version Create Port-to-Original of a Pool TN: Resend Failure to Local SMS (previously NNP flow 3.5)	158
B.5.1.17.12 Subscription Version Create Port-to-Original of a Pool TN: Resend Partial Failure to Local SMS (previously NNP flow 3.6)	160
B.5.1.17.13 Subscription Version Port-to-Original of a Pool TN – Creation Prior to NPA-NXX-X Effective Date (previously NNP flow 3.7)	162
B.5.1.18 SubscriptionVersion Inter-Service Provider Create by either SOA (Old or New Service Provider) with a Due Date which is Prior to the NPA NXX Effective Date – Error	163
B.5.2 Modify Scenarios	164
B.5.2.1 SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA	164
B.5.2.2 SubscriptionVersion Modify Active: Failure to Local SMS	166
B.5.2.3 SubscriptionVersion Modify Prior to Activate Using M-ACTION	167
B.5.2.4 SubscriptionVersion Modify Prior to Activate Using M-SET	169
B.5.2.5 Subscription Version Modify Active: Resend Successful to Local SMS	171
B.5.2.6 Subscription Version Modify Active: Resend Failure to Local SMS	172
B.5.2.7 SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA	173
B.5.3 Cancel Scenarios	174
B.5.3.1 SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred	174
B.5.3.1.1 Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)	175
B.5.3.2 SubscriptionVersionCancel: No Acknowledgment from a SOA	176
B.5.3.3 Subscription Version Cancels With Only One Create Action Received	178
B.5.3.4 Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison	179
B.5.3.5 Un Do Cancel Pending Subscription Version Request	180
B.5.4 Disconnect Scenarios	181
B.5.4.1 SubscriptionVersion Immediate Disconnect	181
B.5.4.1.1 SubscriptionVersion Immediate Disconnect (continued)	182
B.5.4.2 SubscriptionVersion Disconnect With Effective Release Date	183
B.5.4.3 SubscriptionVersion Disconnect: Failure to Local SMS	184
B.5.4.4 SubscriptionVersion Disconnect: Partial Failure to Local SMS	185
B.5.4.5 Subscription Version Disconnect: Resend Successful to Local SMS	186
B.5.4.6 Subscription Version Disconnect: Resend Failure to Local SMS	187
B.5.4.7 Disconnect Subscription Version Scenarios for TNs that are part of a Number Pool Block	188
B.5.4.7.1 SOA Initiates Successful Disconnect Request of Ported Pooled TN (previously NNP flow 4.1.1)	188
B.5.4.7.2 Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation (previously NNP flow 4.1.2)	189
B.5.4.7.3 Subscription Version Disconnect With Effective Release Date (replace/update existing flow B.5.4.2 with this flow here – NNP flow 4.2)	190
B.5.4.7.4 Subscription Version Disconnect of a Ported Pooled TN After Block Activation: Failure to Local SMS (previously NNP flow 4.3.1)	191
B.5.4.7.5 Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates (previously NNP flow 4.3.2)	192
B.5.4.7.6 Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS (previously NNP flow 4.4.1)	193
B.5.4.7.7 Subscription Version Disconnect of a Ported Pooled TN Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.4.2)	194

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.	iv

Table Of Contents

B.5.4.7.8 Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS (previously NNP flow 4.5.1)	195
B.5.4.7.9 Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates (previously NNP flow 4.5.2)	196
B.5.4.7.10 Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS (previously NNP flow 4.6.1)	197
B.5.4.7.11 Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates (previously NNP flow 4.6.2)	198
B.5.4.7.12 Subscription Version Disconnect of a Ported Pooled TN: Resend Partial Failure to Local SMS (previously NNP flow 4.7.1)	199
B.5.4.7.13 Subscription Version Disconnect of a Ported Pooled TN Resend Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.7.2)	199
B.5.4.7.14 Subscription Version Immediate Disconnect of a Contaminated Pooled TN Prior to Block Activation (after Effective Date) (previously NNP flow 4.8)	201
B.5.5 Conflict Scenarios	202
B.5.5.1 SubscriptionVersion Conflict by the NPAC SMS	202
B.5.5.1.1 Subscription Version Conflict Resolution by the NPAC SMS (continued)	203
B.5.5.2 Subscription Version Conflict Removal by the New Service Provider SOA	204
B.5.5.3 SubscriptionVersion Conflict: No Conflict Resolution	205
B.5.5.3.1 Subscription Version Conflict: No Conflict Resolution (continued)	206
B.5.5.4 Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)	207
B.5.5.5 Subscription Version Conflict Removal by the Old Service Provider SOA	209
B.5.6 SubscriptionVersion Query	210
B.5.6.1 Subscription Data Download	212
B.6 LSMS Filter NPA-NXX Scenarios	213
B.6.1 1smsFilterNPA-NXX Creation by the Local SMS	213
B.6.2 1smsFilterNPA-NXX Deletion by the Local SMS	214
B.6.3 1smsFilterNPA-NXX Query by the Local SMS	215
B.6.4 1smsFilterNPA-NXX Creation by the SOA	216
B.6.5 1smsFilterNPA-NXX Deletion by the SOA	217
B.6.6 1smsFilterNPA-NXX Query by the SOA	218
B.7 Local SMS and SOA Recovery	219
B.7.1 Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS (previously NNP flow 5.2)	220
B.7.1.1 Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM	222
B.7.2 Sequencing of Events on Initialization/Resynchronization of EDR Local SMS (previously NNP flow 5.1)	225
B.7.2.1 Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM	227
B.7.3 Sequencing of Events on Initialization/Resynchronization of SOA	231
B.7.3.1 Sequencing of Events on Initialization/Resynchronization of SOA using SWIM	233
B.8 Miscellaneous	236
B.8.1 SOA/Local SMS Notification of Scheduled NPAC Downtime	236
B.8.2 NPA-NXX Split	237
B.8.2.1 NPA-NXX Split that contains a block of pooled TNs Part 1 (previously NNP flow 7)	238
B.8.2.2 NPA-NXX Split that contains a block of pooled TNs Part 2 (previously NNP flow 7)	239
B.8.3 Mass Update	241
B.8.3.1 Mass Update for a range of TNs that contains a Number Pool Block (previously NNP flow 8)	242
B.8.4 Application Level Heartbeat Requests	243
B.8.4.1 NPAC initiated Application Level Heartbeat Request to local system	243
B.8.4.2 Local system initiated Application Level Heartbeat request	244

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.	v

Introduction

Introduction

This document contains the appendices for the IIS document. The appendices are in a separate document from the body of the IIS due to the large size of the document.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		1

Appendix A: Errors

Appendix A. Errors

[Graphic Omitted: Appendix A]

This section will be updated to accommodate the errors associated with ILL 130.

A.1 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 Appendix B.

Exhibit 1. 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, noSuchEventType
M-GET	accessDenied, classInstanceConflict, complexityLimitation, getListError, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported
M-SET	accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported, setListError
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, noSuchReferenceObject
M-DELETE	accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported

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

• The modify of the subscription version will cause a mass update.

• The version selected for a disconnect is not active.

     duplicateManagedObjectInstance

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		2

Appendix A: Errors

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.

Exhibit 2. processingFailure Errors

processingFailure Errors
	Error ID	Description
0	lnpSpecificInfo (GraphicString)	Invalid CLASS DPC value.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		3

Appendix A: Errors

     resourceLimitation

The operation was not processed due to a resource limitation.

     synchronizationNotSupported

The type of synchronization specified is not supported.

A.3 CMIP Error Mapping to NPAC SMS Errors

The following exhibit provides a mapping of errors generated in the NPAC SMS, to the CMIP error that is sent to a SOA/LSMS. CMIP errors are defined as follows:
accessDenied

Implies the service provider cannot perform the given task.

     duplicateObjectInstance

The object already exists.

     invalidArgumentValue

Represents invalidArgumentValue for an M-ACTION response, and invalidAttributeValue for M-CREATE and M-SET responses.

     noSuchObjectInstance

The requested object does not exist.

     processingFailure

The processing failed for the reason given.

The CMIP errors listed in the table should be used as a general guideline. Due to interaction of the different request types (M-ACTION, M-CREATE, M-SET, M-DELETE) and the internal handling of errors, some messages may be delivered to the SOA/LSMS using a different CMIP error than those listed in the table.

Exhibit 3 CMIP Error Mapping to NPAC SMS Errors

SMS Error	Error Description	CMIP Error
0	No error	processingFailure_er
1	No error, used to signal multi pass events that the processing is complete.	processingFailure_er
2	No error, used to signal multi pass events that this is the first pass in processing.	processingFailure_er
100	Timer expected event that was missing, timer will be removed	processingFailure_er
101	Timer could not post event to queue due to database error	processingFailure_er
102	System call failed, PLEASE specify call in additional text.	processingFailure_er
103	operator new failed	processingFailure_er
104	Exception w/descriptive text thrown	processingFailure_er
105	Unknown Exception	processingFailure_er
106	Unable to access CurrentEvent	processingFailure_er
107	Unable to access Events Manager	processingFailure_er
108	Could not open a directory	processingFailure_er
200	Timer expected event that was missing, timer will be removed	accessDenied_er
201	Timer could not post event to queue due to database error	accessDenied_er
202	System call failed, PLEASE specify call in additional text.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		4

Appendix A: Errors

SMS Error	Error Description	CMIP Error
203	Operator new failed	processingFailure_er
204	Exception w/descriptive text thrown	processingFailure_er
205	Unknown Exception	accessDenied_er
206	Unable to access CurrentEvent	accessDenied_er
207	Unable to access Events Manager	accessDenied_er
208	Could not open a directory	accessDenied_er
209	Event retry limit reached	processingFailure_er
210	Can’t open a file	processingFailure_er
211	Event failed, unknown reason	processingFailure_er
212	Event failed, loaded with unknown reason	processingFailure_er
213	Event failed, sms engine couldn’t acquire lock	processingFailure_er
214	Array bounds exception	processingFailure_er
215	Event missing expected attribute	processingFailure_er
216	Array bounds error	processingFailure_er
2000	Required data for TN field(s) missing.	invalidAttributeValue_er
2001	Required due date entry missing from the subscription version.	invalidAttributeValue_er
2002	Required Customer Disconnect Date missing from the subscription version.	invalidAttributeValue_er
2003	Required New Service Provider ID missing from the subscription version.	invalidAttributeValue_er
2004	Required Old Service Provider ID missing from the subscription version.	invalidAttributeValue_er
2005	Required LRN missing.	invalidAttributeValue_er
2006	Required CLASS DPC missing.	invalidAttributeValue_er
2007	Required CLASS SSN missing.	invalidAttributeValue_er
2008	Required CNAM DPC missing.	invalidAttributeValue_er
2009	Required CNAM SSN missing.	invalidAttributeValue_er
2010	Required ISVM DPC missing.	invalidAttributeValue_er
2011	Required ISVM SSN missing.	invalidAttributeValue_er
2012	Required LIDB DPC missing.	invalidAttributeValue_er
2013	Required LIDB SSN missing.	invalidAttributeValue_er
2014	Required value for Date is missing from Network Data.	invalidAttributeValue_er
2015	Required value for Time is missing from Network Data.	invalidAttributeValue_er
2016	Required value for NPAC Customer Name is missing.	invalidAttributeValue_er
2017	Required value for NPAC Customer Id is missing.	invalidAttributeValue_er
2018	Required value for Transmission Media is missing from Network Data.	accessDenied_er
2019	Required value for NPAC Customer Type is missing from NPAC Customer.	invalidAttributeValue_er
2020	Required value for Allowable Functions is missing from NPAC Customer.	accessDenied_er
2021	Required value for Download is missing from NPAC Customer.	accessDenied_er
2022	Required value for Maximum Query is missing from NPAC Customer.	accessDenied_er
2023	Required value for Contact Name is missing from NPAC Customer.	processingFailure_er
2024	Required value for Address Line 1 is missing from NPAC Customer.	processingFailure_er
2025	Required value for NPAC Customer City is missing from NPAC Customer.	processingFailure_er
2026	Required value for Repair Center City is missing from NPAC Customer.	processingFailure_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		5

Appendix A: Errors

SMS Error	Error Description	CMIP Error
2027	Required value for NPAC Customer State is missing from NPAC Customer.	processingFailure_er
2028	Required value for Repair Center State is missing from NPAC Customer.	processingFailure_er
2029	Required value for NPAC Customer Zip Code is missing from NPAC Customer.	processingFailure_er
2030	Required value for Repair Center Zip Code is missing from NPAC Customer.	processingFailure_er
2031	Required value for Pager is missing from NPAC Customer.	processingFailure_er
2032	Required value for Pager PIN is missing from NPAC Customer.	processingFailure_er
2033	Required value for Fax is missing from NPAC Customer.	processingFailure_er
2034	Required value for Email is missing from NPAC Customer.	processingFailure_er
2035	Required value for NSAP is missing from NPAC Customer.	processingFailure_er
2036	Required value for TSAP is missing from NPAC Customer.	processingFailure_er
2037	Required value for SSAP is missing from NPAC Customer.	processingFailure_er
2038	Required value for PSAP is missing from NPAC Customer.	processingFailure_er
2039	Required value for IP is missing from NPAC Customer.	invalidAttributeValue_er
2040	Invalid value for CLASS DPC entered.	invalidAttributeValue_er
2041	Invalid value for CLASS SSN entered.	invalidAttributeValue_er
2042	Invalid value for CNAM DPC entered.	invalidAttributeValue_er
2043	Invalid value for CNAM SSN entered.	invalidAttributeValue_er
2044	Invalid value for ISVM DPC entered.	invalidAttributeValue_er
2045	Invalid value for ISVM SSN entered.	invalidAttributeValue_er
2046	Invalid value for LIDB DPC entered.	invalidAttributeValue_er
2047	Invalid value for LIDB SSN entered.	invalidAttributeValue_er
2048	TN NPA contains invalid data.	invalidAttributeValue_er
2049	TN NXX contains invalid data.	invalidAttributeValue_er
2050	TN extension field contains invalid data.	invalidAttributeValue_er
2051	Month field contains invalid data.	invalidAttributeValue_er
2052	Day field contains invalid data.	invalidAttributeValue_er
2053	Year field contains invalid data.	invalidAttributeValue_er
2054	TN range `through’ field (ending extension value) contains invalid data.	invalidAttributeValue_er
2055	The entered due date and time must be greater than or equal to today’s date and time.	invalidAttributeValue_er
2056	Billing Service Provider ID contains invalid data.	invalidAttributeValue_er
2057	End User Location Value contains invalid data.	invalidAttributeValue_er
2058	End User Location Type contains invalid data.	invalidAttributeValue_er
2059	Invalid value for Time entered.	invalidAttributeValue_er
2060	Invalid value for NPAC Customer Name entered.	invalidAttributeValue_er
2061	Invalid value for NPAC Customer Id entered.	invalidAttributeValue_er
2062	Invalid value for LRN entered.	invalidAttributeValue_er
2063	Invalid value for Transmission Media entered.	invalidAttributeValue_er
2064	Invalid value for NPAC Customer Type entered.	invalidAttributeValue_er
2065	Invalid value for Allowable Functions entered.	invalidAttributeValue_er
2066	Invalid value for Download entered.	invalidAttributeValue_er
2067	Invalid value for Maximum Query entered.	invalidAttributeValue_er
2068	Invalid value for Contact Name entered.	processingFailure_er
2069	Invalid value for Address Line 1 entered.	processingFailure_er
2070	Invalid value for Address Line 2 entered.	processingFailure_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		6

Appendix A: Errors

SMS Error	Error Description	CMIP Error
2071	Invalid value for City entered.	processingFailure_er
2072	Invalid value for State entered.	processingFailure_er
2073	Invalid value for Zip Code entered.	processingFailure_er
2074	Invalid value for Pager entered.	processingFailure_er
2075	Invalid value for Pager PIN entered.	processingFailure_er
2076	Invalid value for Fax entered.	processingFailure_er
2077	Invalid value for Email entered.	processingFailure_er
2078	Invalid value for NSAP entered.	processingFailure_er
2079	Invalid value for TSAP entered.	processingFailure_er
2080	Invalid value for SSAP entered.	processingFailure_er
2081	Invalid value for PSAP entered.	processingFailure_er
2082	Invalid value for IP entered.	invalidAttributeValue_er
2083	Identical values must be entered into both PASSWORD fields.	accessDenied_er
2084	Password field must be non null.	invalidAttributeValue_er
2085	Password must consist of at least 6 case sensitive alphanumeric characters including at least 1 alphabetic and 1 numeric or punctuation character.	invalidAttributeValue_er
2086	Password may not contain the associated userid.	invalidAttributeValue_er
2087	Input attribute not recognized	accessDenied_er
2088	Required value for contact type is missing from NPAC Customer.	processingFailure_er
2089	Required data for TN field(s) missing from contact list	processingFailure_er
2090	PDP Start Date cannot be modified while split is in progress	invalidAttributeValue_er
2091	Modify disconnect SVs must be in ‘disconnect pending’ state.	accessDenied_er
2092	unnecessary optional field if old spid	invalidAttributeValue_er
2093	unnecessary sv_type if old spid	invalidAttributeValue_er
2094	unnecessary optional field if pto	invalidAttributeValue_er
2095	unnecessary sv_type if pto	invalidAttributeValue_er
2096	optional field is not valid	invalidAttributeValue_er
2097	sv_type is not valid	invalidAttributeValue_er
2098	spid supplied an optional field it does not support	invalidAttributeValue_er
2099	spid supports sv_type but fails to provide	missingAttributeValue
2100	optional field is not known	invalidAttributeValue_er
2101	unnecessary optional field	invalidAttributeValue_er
2102	unnecessary sv_type	invalidAttributeValue_er
2103	spid supplied sv_type it does not support	invalidAttributeValue_er
2105	SP must support linked reply for SWIM recovery	accessDenied_er
2106	SP requesting SWIM recovery does not support SWIM	accessDenied_er
2107	Action ID not valid	invalidAttributeValue_er
2108	Required service provider type is not supplied	invalidAttributeValue_er
2109	Service provider type is not valid	invalidAttributeValue_er
2110	SP is not allowed to modify service provider type	accessDenied_er
2111	Service provider type is not consistent with its name	invalidAttributeValue_er
2112	new SP can not resolve conflict with cause code of 50 or 51	accessDenied_er
2113	SV in wrong status for undo cancel operation	noSuchObjectInstance
2114	SV in wrong new status for undo cancel operation	invalidAttributeValue_er
2115	Undo cancel originator SP has not canceled the SV	accessDenied_er
2116	Missing input data for undo cancel operation	invalidAttributeValue_er
2117	SP exceeded LSMS or SOA SWIM recovery limit	processingFailure_er
2118	Undo Cancel Not Supported In This Region.	accessDenied_er
2119	SP Does Not Support SPID Recovery.	accessDenied_er
3000	Value entered for system tunable is out of range.	accessDenied_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		7

Appendix A: Errors

SMS Error	Error Description	CMIP Error
3001	You entered an invalid logon name or password.	invalidAttributeValue_er
3002	The User Group and User Level have conflicting access levels.	accessDenied_er
3003	Non unique userid was entered for this user.	invalidAttributeValue_er
3004	Your password has expired.	accessDenied_er
3005	New password must differ from old passwords	accessDenied_er
3006	System was unable to add user	accessDenied_er
3007	Not all user data needed was provided	invalidAttributeValue_er
3008	Operation referenced a user that does not exist.	invalidAttributeValue_er
3009	Update of a tunable failed or tunable is missing.	accessDenied_er
3010	Unable to load holiday collection from DB.	processingFailure_er
3011	Unable to add a holiday to the collection	accessDenied_er
3012	Unable to delete a holiday from the collection	accessDenied_er
3013	Unable to find a holiday in the collection	accessDenied_er
3014	Event has incorrect subtype	invalidAttributeValue_er
3015	End time is before start time	invalidAttributeValue_er
3016	Start time is before now	invalidAttributeValue_er
3017	Tunable already exists	duplicateManagedObjectInstance
3018	Tunable doesn’t exist and must in order to be modified	noSuchObjectInstance
3019	Tunable has invalid value	invalidAttributeValue_er
3500	Password will expire in <x> days.	accessDenied_er
3501	The user about to be deleted is currently logged on to the system.	accessDenied_er
3502	This action will affect the entire NPAC SMS.	accessDenied_er
3503	Your password has expired.	accessDenied_er
3504	The NPAC is not accepting logins at this time	processingFailure_er
4000	Key List creation failure.	accessDenied_er
4001	Mismatch of hash values for key in key list.	processingFailure_er
4002	Failure calculating checksum for key list.	accessDenied_er
4003	No keys available for this NPAC Customer in any active key list.	accessDenied_er
4004	Non unique keys found in key list.	invalidAttributeValue_er
4005	No active key list available for this NPAC Customer.	accessDenied_er
4006	Invalid Key File Format.	invalidAttributeValue_er
4007	Key List generation is already in progress.	accessDenied_er
4008	Illegal key list state change failure	accessDenied_er
4009	Missing required data in key management event	invalidAttributeValue_er
4010	Key File event failed to process correctly	accessDenied_er
4011	New key specified by service provider is not usable	accessDenied_er
4012	Failure reading key file, invalid key data or list id.	invalidAttributeValue_er
4013	Failure reading keys from key list in database.	processingFailure_er
4500	There are fewer than 100 keys remaining for this Service Provider.	invalidAttributeValue_er
4750	No match found in the database for the search criteria.	noSuchObjectInstance
5000	Item being added already exists in the database.	duplicateManagedObjectInstance
5001	One or more subscriptions will be affected by change. Change is denied.	accessDenied_er
5002	One or more LRNs will be affected by change. Change/Delete is denied.	accessDenied_er
5003	One or more NPA-NXXs will be affected by change. Change/Delete is denied.	accessDenied_er
5004	Subscriptions in either partial failed or sending state are associated with the change. Change/Delete is denied.	accessDenied_er
5005	GTT data is not equivalent across TN range specified. Modify the TN range.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		8

Appendix A: Errors

SMS Error	Error Description	CMIP Error
5006	Bulk Download-invalid criteria specified	processingFailure_er
5007	Bulk Download-file error	processingFailure_er
5008	Resync Data invalid criteria specified	invalidAttributeValue_er
5009	LrnId is required if no customer id, on delete lrn action.	invalidAttributeValue_er
5010	The requested LRN does not exist in the NPAC SMS system.	noSuchObjectInstance
5011	No network data match for search criteria in database.	noSuchObjectInstance
5012	Requestor doesn’t own item being deleted.	accessDenied_er
5014	Resync Data-Maximum records reached or exceeded.	accessDenied_er
5015	Npa required for delete if no NpaNxxId.	invalidAttributeValue_er
5016	Nxx required for delete if no NpaNxxId.	invalidAttributeValue_er
5017	Lrn required for delete if no lrnId.	invalidAttributeValue_er
5018	NpaNxx Accept-invalid or missing npa	invalidAttributeValue_er
5019	NpaNxx Accept-invalid or missing nxx	invalidAttributeValue_er
5020	NpaNxx Accept-invalid or missing customer id	invalidAttributeValue_er
5021	NpaNxx Accept-invalid or missing accepted id	invalidAttributeValue_er
5022	CustomerId and name passed in do not match those in database.	invalidAttributeValue_er
5024	Ending npa/nxx doesn’t exist in database.	invalidAttributeValue_er
5027	Npa required for npa split.	invalidAttributeValue_er
5028	New Npa required for npa split.	invalidAttributeValue_er
5031	PDP Start required for npa split.	invalidAttributeValue_er
5032	PDP End required for npa split.	invalidAttributeValue_er
5033	Resync Type required for resync.	invalidAttributeValue_er
5034	Resync Start TS required for resync.	invalidAttributeValue_er
5035	Npa required for resync of type npa range.	invalidAttributeValue_er
5036	Ending Npa required for resync of type npa range.	invalidAttributeValue_er
5037	Nxx required for resync of type npa range.	invalidAttributeValue_er
5038	Ending Nxx required for resync of type npa range.	invalidAttributeValue_er
5039	Lrn required for resync of type lrn range.	invalidAttributeValue_er
5040	End Lrn required for resync of type lrn range.	invalidAttributeValue_er
5041	No NpaNxx is available from the NPANXX::SelectRandom() method.	invalidAttributeValue_er
5042	Request failed on previous npaNxx.	processingFailure_er
5043	Request failed on previous lrn.	processingFailure_er
5044	There are no npanxx’s in the specified range	invalidAttributeValue_er
5045	Supplied customer id does not match any npanxx’s in range	invalidAttributeValue_er
5046	Resync rollup failed	accessDenied_er
5047	Resync returned zero records	accessDenied_er
5048	Resync time range exceeds duration tunable	accessDenied_er
5050	Active SVs found for the new NPA NXX.	invalidAttributeValue_er
5051	Invalid Permissive Dialing Period Date entered.	invalidAttributeValue_er
5052	NPA NXX Already involved in another split.	invalidAttributeValue_er
5053	Missing required data: NXX List.	invalidAttributeValue_er
5054	Missing required data: NPA Split Id.	invalidAttributeValue_er
5055	Permissive Dialing Period End Date must be after now.	invalidAttributeValue_er
5056	Missing required data: PDP End Date and/or Nxx List.	invalidAttributeValue_er
5057	Permissive Dialing Period Start Date must be after now.	invalidAttributeValue_er
5058	PDP Start date must be before PDP End date.	invalidAttributeValue_er
5059	PDP Start value must equal Effective timestamp of each new NPA NXX involved in the split.	invalidAttributeValue_er
5060	New and old NPA NXX records must be owned by same SP.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		9

Appendix A: Errors

SMS Error	Error Description	CMIP Error
5061	Cannot Delete a split after the start of PDP.	invalidAttributeValue_er
5062	The NPA-NXX is currently involved in a split.	invalidAttributeValue_er
5070	FAILURE attempting to update NPA-NXX.	accessDenied_er
5071	FAILURE attempting to delete NPA_SPLIT_LOG records.	accessDenied_er
5072	FAILURE attempting to delete NPA_SPLIT records.	accessDenied_er
5073	Delete denied due to associated NPA-NXX-Xs.	invalidAttributeValue_er
5074	Block action denied due to spid not owning lrn.	invalidAttributeValue_er
5075	Create block failed due to too many tns in block.	invalidAttributeValue_er
5076	Create block failed due to tns already in another block.	invalidAttributeValue_er
5077	NPA-NXX-X action denied due to effective date before NpaNxx effective ts.	invalidAttributeValue_er
5078	Block id is required for block modify.	invalidAttributeValue_er
5079	Lrn or GTT Data is required for block modify.	invalidAttributeValue_er
5080	Block does not exist in database.	invalidAttributeValue_er
5081	NPA-NXX-X delete denied due to non active block.	accessDenied_er
5082	Customer delete denied due to associated NPA-NXX-Xs.	invalidAttributeValue_er
5083	BlockId does not exist in the NPAC system.	invalidAttributeValue_er
5084	The TUNA_MAXIMUM_BLOCK_RANGE value for querying blocks is missing.	invalidAttributeValue_er
5085	Blocks found: exceed maximum query limit.	processingFailure_er
5086	Block Holder cannot equal the code holder.	invalidAttributeValue_er
5087	The NpaNxxAcceptId does not exist in the NpaNxxAcceptTable.	invalidAttributeValue_er
5088	NPA-NXX-X action denied: effective date is before NPA-NXX live timestamp.	accessDenied_er
5089	SV action denied because due date is before NPA-NXX live timestamp.	accessDenied_er
5090	NetworkNotificationRecoveryAction time range is invalid	invalidAttributeValue_er
5091	NetworkNotificationRecoveryAction time range exceeds tunable	accessDenied_er
5092	NPA-NXX-X delete denied due to associated failed LSMS entries.	accessDenied_er
5093	Pending like with active pooled SVs and Pending like PTO SVs exist.	accessDenied_er
5094	Cannot delete NPA-NXX-X using new Npa for a scheduled split.	accessDenied_er
5095	The NPA-NXX-X-ID is required.	invalidAttributeValue_er
5096	No matching NPA-NXX-X exists in the database.	noSuchObjectInstance
5097	The NPA-NXX-X is required.	missingAttributeValue
5098	The SOA Origination Indicator is required.	missingAttributeValue
5099	A scheduled create block event is required.	missingAttributeValue
5100	The number of business days between the NPA-NXX-X’s creation date and effective date does not meet the minimum tunable value.	accessDenied_er
5101	Block Create request is before NPA-NXX-X’s effective date.	invalidAttributeValue_er
5102	A pending/conflict/cancel pending/failed PTO SV exists.	accessDenied_er
5103	LIDB SSN is not allowed.	invalidAttributeValue_er
5104	LIDB DPC is not allowed.	invalidAttributeValue_er
5105	ISVM SSN is not allowed.	invalidAttributeValue_er
5106	ISVM DPC is not allowed.	invalidAttributeValue_er
5107	CNAM SSN is not allowed.	invalidAttributeValue_er
5108	CNAM DPC is not allowed.	invalidAttributeValue_er
5109	CLASS SSN is not allowed.	invalidAttributeValue_er
5110	CLASS DPC is not allowed.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		10

Appendix A: Errors

SMS Error	Error Description	CMIP Error
5111	LRN is not allowed.	invalidAttributeValue_er
5112	A pooled block already exists.	accessDenied_er
5113	Cannot modify an NPA-NXX-X using the new Npa of a scheduled split.	accessDenied_er
5114	Cannot create an NPA-NXX-X using the new Npa of a scheduled split.	accessDenied_er
5115	Effective date is not allowed.	invalidAttributeValue_er
5116	An NPA-NXX-X exists for the new Npa.	accessDenied_er
5117	PDP Start, PDP End, or NXX List must be supplied in modify request.	invalidAttributeValue_er
5118	New NPA-NXX already exists.	invalidAttributeValue_er
5119	PDP Start Date cannot be changed if pending SVs exist in new NPA-NXX	invalidAttributeValue_er
5120	At least one of old and new NPA-NXX must exist.	invalidAttributeValue_er
5121	PDP Start date cannot change after PDP Start.	invalidAttributeValue_er
5122	An SV exists in both the old and new NPA-NXX.	invalidAttributeValue_er
5123	A DashX exists in the new NPA-NXX.	invalidAttributeValue_er
5124	Cannot create LISP PTO with scheduled block creation.	accessDenied_er
5125	Deferred disconnect timer is firing, modify denied.	accessDenied_er
5126	LRN specified for SV is in a different LATA from TN.	invalidAttributeValue_er
5127	LRN specified for Block is in a different LATA from DashX.	invalidAttributeValue_er
5128	SPID migration file open error.	invalidAttributeValue_er
5129	LATA ID Not Found in the LATA File.	invalidAttributeValue_er
5130	LATA File Access Error.	invalidAttributeValue_er
5131	Notification recovered exceeded max tunable for sp supports linked reply.	accessDenied_er
5132	BDD response file invalid	invalidAttributeValue_er
5133	Processing BDD response file failed	accessDenied_er
5134	Consistency check failed for network item (i.e. LRN, NPANXX, and DashX)	accessDenied_er
5135	NPA-NXX not valid for this region.	invalidAttributeValue_er
5500	One or more subscriptions will be affected by change. Require user acknowledgment to proceed.	accessDenied_er
6000	Item being added already exists in the database.	invalidAttributeValue_er
6001	One or more subscriptions will be affected by change. Change is denied.	accessDenied_er
6002	One or more npa nxxs are associated with this customer, Delete is denied.	accessDenied_er
6003	One or more lrns are associated with this customer, Delete is denied.	accessDenied_er
6004	NPAC Customer ID cannot be modified.	invalidAttributeValue_er
6005	The NPAC Customer being modified does not exist in the database.	noSuchObjectInstance
6006	The NPAC Customer being deleted does not exist in the database, or has already been deleted.	noSuchObjectInstance
6007	Invalid contact type for NPAC Customer	processingFailure_er
6008	The contact info array is missing from the Customer.	invalidAttributeValue_er
6009	The network address list array is missing from the Customer.	invalidAttributeValue_er
6010	The network address type is missing from the Customer.	processingFailure_er
6011	The npac customer contact is missing from the Customer.	processingFailure_er
6012	The billing contact is missing from the Customer.	processingFailure_er
6013	The security contact is missing from the Customer.	processingFailure_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		11

Appendix A: Errors

SMS Error	Error Description	CMIP Error
6014	The repair contact is missing from the Customer.	processingFailure_er
6015	At least one network address is required for Customer.	invalidAttributeValue_er
6016	Required value for Contact Name is missing from Billing Contact.	processingFailure_er
6017	Required value for Address Line 1 is missing from Billing Contact.	processingFailure_er
6018	Required value for NPAC Customer City is missing from Billing Contact.	processingFailure_er
6019	Required value for NPAC Customer State is missing from Billing Contact.	processingFailure_er
6020	Required value for NPAC Customer Zip Code is missing from Billing Contact.	processingFailure_er
6021	Required value for Contact Name is missing from Repair Contact.	processingFailure_er
6022	Required value for Address Line 1 is missing from Repair Contact.	processingFailure_er
6023	Required value for Contact Name is missing from Security Contact.	processingFailure_er
6024	Required value for Address Line 1 is missing from Security Contact.	processingFailure_er
6025	Required value for NPAC Customer City is missing from Security Contact.	processingFailure_er
6026	Required value for NPAC Customer State is missing from Security Contact.	processingFailure_er
6027	Required value for NPAC Customer Zip Code is missing from Security Contact.	processingFailure_er
6028	Event subtype not recognized	invalidAttributeValue_er
6029	Invalid operation for this NPAC Customer	accessDenied_er
6030	SP User cannot modify Customer Name on modify.	invalidAttributeValue_er
6031	SP User cannot modify allowable functions mask on modify.	invalidAttributeValue_er
6032	Required value for country is missing from contact data.	processingFailure_er
6033	SP block indicator must be only attribute on event	invalidAttributeValue_er
6034	LTI Only Customer attribute missing from event	invalidAttributeValue_er
6035	SP can not modify sp block indicator flag	invalidAttributeValue_er
6036	Customer cannot be deleted if associated with primary or secondary customer	invalidAttributeValue_er
6037	Active customer to modify or delete does not exist	accessDenied_er
6038	Customer cannot be modified to LTI User if associated customers exist.	invalidAttributeValue_er
6039	Customer Request denied due to duplicate Network Address PSAP.	invalidAttributeValue_er
6040	Customer does not exist and cannot be added as a Secondary Customer.	noSuchObjectInstance
6041	This customer must be removed from all router config lists before it can be deleted.	accessDenied_er
6500	One or more subscriptions will be affected by change. Require user acknowledgment to proceed.	invalidAttributeValue_er
6750	No match found in the database for the search criteria.	noSuchObjectInstance
6751	<x> Subscriptions found: exceed maximum query limit.	invalidAttributeValue_er
6752	No subscription versions found for the given input search criteria.	noSuchObjectInstance
6753	Warning Primary Customer has no SOA Functionality Set.	invalidAttributeValue_er
6754	Warning Secondary Customer has no SOA Functionality Set.	invalidAttributeValue_er
7000	The NPA NXX for this operation does not exist in the NPAC SMS system.	noSuchObjectInstance

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		12

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7001	Service Provider ID does not exist in the NPAC SMS system.	invalidAttributeValue_er
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	accessDenied_er
7003	This Service Provider has already issued a create for the subscription version.	duplicateManagedObjectInstance
7004	The entered LRN is not associated with the New Service Provider in the NPAC SMS system.	invalidAttributeValue_er
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.	accessDenied_er
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.	accessDenied_er
7007	The Old Service Provider ID input data does not match the old Service Provider ID in an existing pending subscription version for this TN.	accessDenied_er
7008	Releasing a subscription version for an Intra-Service Provider port does not apply.	accessDenied_er
7009	The Old Service Provider ID must match the New Service Provider ID for an Intra-Service Port.	invalidAttributeValue_er
7010	The New and Old Service Provider Due Dates must match.	invalidAttributeValue_er
7011	An active subscription version must exist for an Intra SP port.	accessDenied_er
7012	A subscription version with sending status cannot be modified.	accessDenied_er
7013	A subscription version with failed status cannot be modified.	accessDenied_er
7014	A subscription version with partial failure status cannot be modified.	accessDenied_er
7015	A subscription version with canceled status cannot be modified.	accessDenied_er
7016	A subscription version with old status cannot be modified.	accessDenied_er
7017	A subscription version with disconnect pending status cannot be modified.	accessDenied_er
7018	A subscription version with cancel pending status cannot be modified.	accessDenied_er
7019	A subscription version must be in pending status to be activated.	accessDenied_er
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.	accessDenied_er
7021	The Service Provider originating the modification request is not the current Service Provider.	accessDenied_er
7022	The subscription version cannot be put in conflict because its current status is not pending, or cancel pending.	accessDenied_er
7023	The subscription version cannot be disconnected because there is no current subscription version in active status.	accessDenied_er
7024	This active subscription version cannot be disconnected until a sending subscription version successfully completes.	accessDenied_er
7025	This active subscription version cannot be disconnected until a failed or partial failure subscription version is re-sent and successfully completes.	accessDenied_er
7026	The subscription version cannot be canceled because its current status is not pending, conflict or disconnect pending.	accessDenied_er
7027	The subscription version cannot be resent because its current status is not partial failure, failure, disconnect pending, old or active.	accessDenied_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		13

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7028	Active subscription version may not be modified because a related subscription version for this TN has been activated.	accessDenied_er
7029	Pending subscription version may not be activated until a related subscription version in sending status becomes active.	accessDenied_er
7030	Deferred disconnect request is not allowed because a pending subscription version exists for this TN.	accessDenied_er
7031	This subscription version may not be activated because authorization for transfer of service has not been received from the New SP.	accessDenied_er
7032	The due date of a subscription version with active status cannot be modified.	invalidAttributeValue_er
7033	Porting To Original must be false for inter service ports.	invalidAttributeValue_er
7034	Required Port Type is missing from input data.	invalidAttributeValue_er
7035	Required TN data (NPA) is missing from input data.	invalidAttributeValue_er
7036	Required TN data (NXX) is missing from input data.	invalidAttributeValue_er
7037	Required TN data (starting station) is missing from input data.	invalidAttributeValue_er
7038	Required TN data (ending station) is missing from input data.	invalidAttributeValue_er
7039	Required Old Service Provider Authorization Flag missing from the subscription version.	invalidAttributeValue_er
7040	Required Porting To Original Flag is missing from input data.	invalidAttributeValue_er
7041	NPAC SMS allows only one of pending, cancel pending, conflict, disconnect pending, failed or partial failure Subscription Version per TN.	invalidAttributeValue_er
7043	LIDB SSN is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7044	LIDB SSN is not allowed for old service provider input.	invalidAttributeValue_er
7045	LIDB DPC is not allowed for old service provider input.	invalidAttributeValue_er
7046	LIDB DPC is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7047	ISVM SSN is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7048	ISVM SSN is not allowed for old service provider input.	invalidAttributeValue_er
7049	ISVM DPC is not allowed for old service provider input.	invalidAttributeValue_er
7050	ISVM DPC is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7051	CNAM SSN is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7052	CNAM SSN is not allowed for old service provider input.	invalidAttributeValue_er
7053	CNAM DPC is not allowed for old service provider input.	invalidAttributeValue_er
7054	CNAM DPC is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7055	CLASS SSN is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7056	CLASS SSN is not allowed for old service provider input.	invalidAttributeValue_er
7057	CLASS DPC is not allowed for old service provider input.	invalidAttributeValue_er
7058	CLASS DPC is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7059	LRN is not allowed for Porting-to-Original ports.	invalidAttributeValue_er
7060	LRN is not allowed for old service provider input.	invalidAttributeValue_er
7061	New Service Provider due date is not allowed for Old Service Provider input.	invalidAttributeValue_er
7062	Old Service Provider due date is not allowed for New Service Provider input.	invalidAttributeValue_er
7063	Old Service Provider Authorization Flag is not allowed for New Service Provider input.	invalidAttributeValue_er
7064	Old Service Provider Authorization Flag is not allowed for Intra-Service Ports.	invalidAttributeValue_er
7065	Billing Service Provider ID is not allowed for Old Service Provider input.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		14

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7066	End User Location is not allowed for Old Service Provider input.	invalidAttributeValue_er
7067	End User Location Type is not allowed for Old Service Provider input.	invalidAttributeValue_er
7068	Either the Ported Telephone Number or the Subscription Version ID is required to activate a subscription version.	invalidAttributeValue_er
7069	The Old Service Provider cannot modify an intra service port.	accessDenied_er
7070	Only the Current Service Provider can disconnect a subscription version.	accessDenied_er
7071	SV cannot be disconnected if it has failed list, or an active like, or pending like SV exists for that TN	accessDenied_er
7072	The subscription version cannot be removed from conflict because its current status is not conflict.	accessDenied_er
7073	Only the Current Service Provider can activate a subscription version.	invalidAttributeValue_er
7074	A pending subscription version cannot be activated before its npa_nxx’s effective date.	invalidAttributeValue_er
7075	NPAC SMS allows only one sending Subscription Version per TN.	accessDenied_er
7076	NPAC SMS allows only one active Subscription Version per TN.	accessDenied_er
7077	Request failed on previous subscription version.	processingFailure_er
7078	Required subscription version ID is missing from input data.	invalidAttributeValue_er
7079	Required TimerId is missing from input data.	accessDenied_er
7080	Required ConflictDate is missing from input data.	invalidAttributeValue_er
7081	Required PendingDate is missing from input data.	invalidAttributeValue_er
	The Service Provider requesting this cancel did not create the
7082	subscription version.	accessDenied_er
7083	There is no subscription version with the requested status.	invalidAttributeValue_er
7084	The subscription version status is required to modify a subscription version.	invalidAttributeValue_er
7085	The action ID field is required for LsmsSvNotifyResponseEvent event type.	processingFailure_er
7086	The old service provider cannot request conflict resolution.	accessDenied_er
7087	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.	invalidAttributeValue_er
7088	Active subscription versions cannot be modified via CMIP set.	accessDenied_er
7089	The Old Service Provider has already put this subscription version into conflict the maximum number of times.	accessDenied_er
7090	It is too close to the New Service Provider due date for the Old Service Provider to place the subscription version into conflict.	accessDenied_er
7091	This subscription version may not be activated because the Old Service Provider’s concurrence window has not yet expired.	accessDenied_er
7092	Required originating SPID is missing from input data.	invalidAttributeValue_er
7093	SV Notification SV_MODIFIED missing response.	invalidAttributeValue_er
7094	Either the Ported Telephone Number or the Subscription Version ID is required to modify a subscription version.	invalidAttributeValue_er
7095	Required Resync Type is missing from input data.	invalidAttributeValue_er
7096	Required Resync Start Timestamp is missing from input data.	invalidAttributeValue_er
7097	Either the Ported Telephone Number or the Subscription Version ID is required to cancel a subscription version.	invalidAttributeValue_er
7098	Either the Ported Telephone Number or the Subscription Version ID is required to resolve a conflicted subscription version.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		15

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7099	Either the Ported Telephone Number or the Subscription Version ID is required to disconnect a subscription version.	invalidAttributeValue_er
7100	Either the Ported Telephone Number or the Subscription Version ID is required to create a subscription version.	invalidAttributeValue_er
7101	The NPA-NXX of the TN has been split. The entered TN is the old NPA-NXX.	invalidAttributeValue_er
7102	Either the subscription version ID or TN is required for concurrence.	invalidAttributeValue_er
7104	The Status Change Cause Code is required if the authorization flag is false.	invalidAttributeValue_er
7105	The Status Change Cause Code cannot be set if the authorization flag is true.	invalidAttributeValue_er
7106	The Status Change Cause Code cannot be set if the new service provider is the originator.	invalidAttributeValue_er
7107	Invalid Status Change Cause Code.	invalidAttributeValue_er
7108	A pending subscription version cannot be activated before its due date.	invalidAttributeValue_er
7109	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.	invalidAttributeValue_er
7110	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.	accessDenied_er
7111	Porting To Original Flag is not allowed for old service provider input.	invalidAttributeValue_er
7112	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.	processingFailure_er
7113	LSMS did not respond in allotted time.	processingFailure_er
7114	Missing SV Tunable value.	invalidAttributeValue_er
7115	The Status Change Cause Code is required if the old service provider is the originator.	invalidAttributeValue_er
7116	The subscription version cannot be resent because it does not have a failed LSMS list.	accessDenied_er
7117	Either the due date or the authorization flag is required to modify a subscription version by the old Service Provider.	invalidAttributeValue_er
7118	On a modify by new/current Service Provider, one of the GTT input data fields, lrn, billing data, or due date is required.	invalidAttributeValue_er
7119	A Disconnect request for an active subscription version for this TN previously failed. This failure must be resolved before a create is allowed.	accessDenied_er
7120	The LNP Type input in the event does not match the LNP type of a pending SV for this TN.	invalidAttributeValue_er
7121	A subscription version with cancel pending status exists. A new one cannot be created for this TN.	accessDenied_er
7122	A pending subscription version for the TN exists.	accessDenied_er
7123	A subscription version with disconnect pending status exists. A new one cannot be created for this TN.	accessDenied_er
7124	The old authorization flag of a subscription version with active status cannot be modified.	invalidAttributeValue_er
7125	The change cause code of a subscription version with active status cannot be modified.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		16

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7126	A Failed subscription version for the TN exists. This failure must be resolved before a modify is allowed.	accessDenied_er
7127	There is no subscription version matching the query filter data.	noSuchObjectInstance
7128	The Service Provider requesting this modify did not create the subscription version.	accessDenied_er
7129	The Ending Station must be a number greater than the Starting Station.	invalidAttributeValue_er
7130	The LNP Type must be either LISP or LSPP.	accessDenied_er
7131	The Old Service Provider cannot cancel a disconnect pending subscription version.	accessDenied_er
7132	A subscription version with sending status exists. A new one cannot be created for this TN.	accessDenied_er
7133	The Service Provider requesting this conflict did not create the subscription version.	accessDenied_er
7134	Waiting on New SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.	accessDenied_er
7135	Waiting on Old SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.	accessDenied_er
7136	There must be an active SV for a porting to original port.	accessDenied_er
7137	The requested subscription version does not exist.	noSuchObjectInstance
7138	A subscription version with pending status exists. A new one cannot be created for this TN.	accessDenied_er
7139	The Service Provider requesting this conflict resolution did not create the subscription version.	accessDenied_er
7140	The Old Service Provider ID must not match the New Service Provider ID for an Inter Service Port.	invalidAttributeValue_er
7141	Subscription version must be in cancel pending state for concurrence.	accessDenied_er
7142	The action ID does not belong to originator.	processingFailure_er
7143	NPAC SMS allows only two sending Subscription Versions per tn for port to original.	accessDenied_er
7144	The change cause code of a subscription version cannot be modified if it is already set.	invalidAttributeValue_er
7145	NPAC SMS allows only three sending Subscription Versions per tn for port to original of sv in block.	accessDenied_er
7146	The user originating the Block request is not an NPAC Personnel user.	accessDenied_er
7148	The New Service Provider ID must match the Block Holder ID for a Block.	invalidAttributeValue_er
7149	Required BlockId is missing from input data.	invalidAttributeValue_er
7150	Old Service Provider due date is not allowed for a block creation.	invalidAttributeValue_er
7151	Old Service Provider ID is not allowed for a block.	invalidAttributeValue_er
7152	LRN is not allowed for a block.	invalidAttributeValue_er
7163	A pending subscription version exists for this NPA-NXX-X. A block cannot be created.	accessDenied_er
7164	New Service Provider due date is not allowed for a block.	invalidAttributeValue_er
7165	A block cannot be created before the NPA-NXX-X’s effective date.	accessDenied_er
7166	A block cannot be created before the NpaNxx’s effective date.	accessDenied_er
7167	A subscription version with LNP Type POOL cannot be activated.	accessDenied_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		17

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7168	Only NPAC Personnel may disconnect a pooled SV.	accessDenied_er
7169	Effective Release Date cannot be set for pooled SV disconnect.	invalidAttributeValue_er
7170	NPAC SMS allows only two sending Subscription Versions per tn for ports of SVs in a block.	accessDenied_er
7171	New Service Provider ID is not allowed for a block create.	invalidAttributeValue_er
7172	All TNs in the block range are currently ported.	accessDenied_er
7173	An old subscription version with a failed LSMS list exists. A new one cannot be created.	accessDenied_er
7174	The new SP for this Port To Original SV is not the donor of the NpaNxx.	accessDenied_er
7175	Time Range exceeds tunable value.	invalidAttributeValue_er
7176	Delete denied, tunable does not exist.	noSuchObjectInstance
7177	Create denied, tunable already exists.	duplicateManagedObjectInstance
7178	Modify denied, tunable does not exist.	noSuchObjectInstance
7179	WSMSC DPC required if SOA supports it.	invalidAttributeValue_er
7180	WSMSC SSN required if SOA supports it.	invalidAttributeValue_er
7181	WSMSC DPC not valid input for this action.	invalidAttributeValue_er
7182	WSMSC SSN not valid input for this action.	invalidAttributeValue_er
7183	Query expression required on mass update.	invalidAttributeValue_er
7184	Either subscription version ID, block ID, TN or all failures is required on resend.	invalidAttributeValue_er
7185	Cannot retrieve svs from temp table.	processingFailure_er
7186	The Event does not contain any data to process.	invalidAttributeValue_er
7187	Failure changing viewed indicator.	processingFailure_er
7188	Modify failed: the notification does not exist in the database.	invalidAttributeValue_er
7189	Either BlockId or NPA-NXX-X and status are required for block modify	invalidAttributeValue_er
7190	NPA-NX-X is required for block create	invalidAttributeValue_er
7191	Cannot create LISP, after dashX creation, before block is created	accessDenied_er
7192	Pending like svs exist with matching pto svs	accessDenied_er
7193	Non active non pooled svs exist	accessDenied_er
7194	Only npac personnel can create lisp with pending block creation	accessDenied_er
7195	New sp of lisp create must be code holder with pending block creation	accessDenied_er
7196	Cannot create lisp if active sv exists and pending block creation	accessDenied_er
7197	Cannot create lspp with pending block creation	accessDenied_er
7198	Cannot create sv if dashx has failed lsms list	accessDenied_er
7199	WSMSC DPC entered is invalid	invalidAttributeValue_er
7200	WSMSC SSN entered is invalid	invalidAttributeValue_er
7201	Can only modify pooled svs with block modify request	accessDenied_er
7202	Only npac personnel can modify the soa indicator	invalidAttributeValue_er
7203	Cannot modify pooled block if block has failed lsms list	accessDenied_er
7204	Cannot modify non active pooled svs	accessDenied_er
7205	Cannot activate lisp if active sv exists	accessDenied_er
7206	Cannot activate pto during dashx deletion.	accessDenied_er
7207	Cannot activate pto due to failed dashX deletion.	accessDenied_er
7208	Cannot cancel a pooled sv	accessDenied_er
7209	Cannot conflict a pooled sv	accessDenied_er
7210	Pending like SVs exist with no matching active SVs.	accessDenied_er
7211	Can only modify one pooled block at a time.	accessDenied_er
7212	Mass Update of pooled block must wholly encompass block.	accessDenied_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		18

Appendix A: Errors

SMS Error	Error Description	CMIP Error
7213	You cannot resend a pooled SV.	accessDenied_er
7214	No subscription versions found for the given input search criteria.	noSuchObjectInstance
7215	Subscriptions found exceed maximum query limit.	complexityLimitation
7216	Subscription version must be in pending or conflict state for create timeout.	accessDenied_er
7217	Subscription version must be in cancel pending state for cancel timeout.	accessDenied_er
7218	The old customer id on the create does not match the owner of the associated npa nxx.	accessDenied_er
7219	Found active like SV for block creation.	invalidAttributeValue_er
7220	A subscription version’s due date cannot be before its npa_nxx’s effective date.	invalidAttributeValue_er
7221	Status change cause code is not allowed on an LISP creation, modification, or set to conflict.	invalidAttributeValue_er
7222	Old due date is not allowed on an LISP creation or modification.	invalidAttributeValue_er
7223	A subscription version with failed status exists. A new one cannot be created for this TN.	accessDenied_er
7224	A subscription version with partial failed status exists. A new one cannot be created for this TN.	accessDenied_er
7225	Recovered objects found exceed maximum limit.	complexityLimitation
7226	An active subscription version with failed list can not be modified. This failure must be resolved before a modify is allowed.	accessDenied_er
7227	Old SP cant modify NewSPDueDate Or RoutingData.	accessDenied_er
7228	New SP cant modify OldSPDueDate, Authorization or CauseCode.	accessDenied_er
7500	The entered due date differs from the due date entered by the other Service Provider.	invalidAttributeValue_er
7751	Block successfully activated.	processingFailure_er
7752	Block successfully modified.	processingFailure_er
7753	Block successfully disconnected.	processingFailure_er
7754	Block activate partially failed.	processingFailure_er
7755	Block modify partially failed.	processingFailure_er
7756	Block disconnect partially failed.	processingFailure_er
7757	Block activate totally failed.	processingFailure_er
7758	Block modify totally failed.	processingFailure_er
7759	Block disconnect totally failed.	processingFailure_er
7760	Found Same TN for Old and New NPA at Start of PDP.	processingFailure_er
7761	No more than three related svs are allowed.	accessDenied_er
7762	With three related svs, one must be pooled in old, partial failed, failed or sending status.	accessDenied_er
7763	With three related svs, one must be pto.	accessDenied_er
7764	With three related svs, one must be non pto and non pooled.	accessDenied_er
7765	With two related svs, at least one must be non pto.	accessDenied_er
7766	With no related svs, the sv cannot be pto.	accessDenied_er
9000	Invalid date entered.	invalidAttributeValue_er
9001	Invalid time entered.	invalidAttributeValue_er
9002	Audit Profile name too long.	invalidAttributeValue_er
9003	Invalid TN data entered.	invalidAttributeValue_er
9004	Audit Profile name is not unique.	duplicateManagedObjectInstance
9005	No audits match the entered criteria.	invalidAttributeValue_er
9006	Could not cancel specified Audit(s)	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		19

Appendix A: Errors

SMS Error	Error Description	CMIP Error
9007	Audit validation failed.	invalidAttributeValue_er
9008	No LSMSs to audit.	invalidAttributeValue_er
9009	Need required event input data	invalidAttributeValue_er
9010	Failed to generate a unique name for a periodic audit.	invalidAttributeValue_er
9011	Failed to generate a discrepancy for an SV mismatch.	invalidAttributeValue_er
9012	Failed to issue query events.	invalidAttributeValue_er
9013	Starting Station > Ending Station Error	invalidAttributeValue_er
9014	CMIP bounced, which killed our query.	invalidAttributeValue_er
9015	We can’t use input data that conflicts with itself	invalidAttributeValue_er
9016	Failed to issue SP Notification events.	processingFailure_er
9017	Failed to retrieve allowable function mask	invalidAttributeValue_er
9018	Event Process failed	processingFailure_er
9019	Discrepancy created with invalid reason code.	invalidAttributeValue_er
9500	NPA does not exist in the NPAC SMS data.	invalidAttributeValue_er
9501	NPA NXX combination does not exist in the NPAC SMS data.	invalidAttributeValue_er
9750	No TNs found within the range entered.	noSuchObjectInstance
9751	No results have yet been reported for the selected audit.	invalidAttributeValue_er
10000	Invalid NPA data entered.	invalidAttributeValue_er
10001	Invalid NXX data entered.	invalidAttributeValue_er
10002	Invalid LRN data entered.	invalidAttributeValue_er
10003	Invalid range for NXXs (second must be greater than first).	invalidAttributeValue_er
10004	Invalid range for LRNs (second must be greater than first).	invalidAttributeValue_er
10005	Invalid printer name entered.	invalidAttributeValue_er
10006	Too many characters entered in printer field.	invalidAttributeValue_er
10007	Invalid TN entered in fax field.	processingFailure_er
10008	Too many characters entered in file name field.	invalidAttributeValue_er
10009	Invalid file name entered.	invalidAttributeValue_er
10010	No generated file name entered.	accessDenied_er
10011	No destination designated for report.	accessDenied_er
10012	Invalid date entered.	invalidAttributeValue_er
10013	Invalid parameters detected in Report Parameters.	invalidAttributeValue_er
10014	End date occurs before the start date.	invalidAttributeValue_er
10015	Requester does not have privileges to generate this report.	accessDenied_er
10016	Event missing customer ID	invalidAttributeValue_er
10017	No existing report or incorrect permissions	accessDenied_er
10018	Failure scanning existing report directory	accessDenied_er
10019	Failure opening existing report directory	accessDenied_er
10020	Failure retrieving originator information	accessDenied_er
10021	Failure printing report file	accessDenied_er
10022	Failure emailing report file	accessDenied_er
10023	Failure faxing report file	accessDenied_er
10024	Failure moving report file	accessDenied_er
10025	Failure renaming report file	accessDenied_er
10026	Failure running report	processingFailure_er
10750	No billing data exists for the entered criteria.	accessDenied_er
10751	Unknown report name for report id.	accessDenied_er
11000	Invalid date entered.	invalidAttributeValue_er
11001	Invalid printer name entered.	invalidAttributeValue_er
11002	Too many characters entered in printer field.	invalidAttributeValue_er
11003	Invalid TN entered in fax field.	processingFailure_er
11004	Too many characters entered in file name field.	invalidAttributeValue_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		20

Appendix A: Errors

SMS Error	Error Description	CMIP Error
11005	End date occurs before the start date.	invalidAttributeValue_er
11006	You cannot post date service element collection changes.	accessDenied_er
11007	Invalid file name entered.	invalidAttributeValue_er
11008	Incomplete Request Parameter Set.	accessDenied_er
11009	Invalid category for billing	invalidAttributeValue_er
11010	Invalid Multiplier Specified.	invalidAttributeValue_er
11011	Unable To Read Multiplier.	accessDenied_er
11500	Unable to connect to entered fax number.	accessDenied_er
12000	Oracle RDBMS has reported the following Database Server Error: ORA-nnnnn	accessDenied_er
12001	Oracle RDBMS has reported the following SQL Execution Error: ORA-nnnnn	accessDenied_er
	Oracle RDBMS has reported the following Stored Procedure/Trigger Error:
12002	ORA-nnnnn	accessDenied_er
12003	Oracle RDBMS has reported the following Database Networking (SQL*NET) Error: ORA-nnnnn	accessDenied_er
12004	Oracle RDBMS has reported the following Replication Server Error ORA-nnnnn	accessDenied_er
12005	Oracle RDBMS has reported the following Report Writer Error: ORA nnnnn	accessDenied_er
12006	Oracle RDBMS database has been disconnected.	accessDenied_er
12110	Dispatcher found bad event	accessDenied_er
12120	Corrupt data found	accessDenied_er
12140	Resource Failure	processingFailure_er
12150	Hard (non-retryable) Resource Failure	processingFailure_er
13000	Housekeeping error	invalidAttributeValue_er
13001	Housekeeping tuna value error	accessDenied_er
13002	Invalid event subtype	accessDenied_er
13003	Tunable Not Found	accessDenied_er
13004	InvalidPurgeAction	accessDenied_er
14000	CMIP:Access Denied Error	accessDenied_er
14001	CMIP:Class Instance Conflict	classInstanceConflict
14002	CMIP:Complexity Limitation	complexityLimitation
14003	CMIP:Duplicate Managed Object Instance	duplicateManagedObjectInstance
14004	CMIP:GetListError	getListError_er
14005	CMIP:Invalid Argument Value	invalidArgumentValue_er
14006	CMIP:Invalid Attribute Value	invalidAttributeValue_er
14007	CMIP:Invalid Filter	invalidFilter
14008	CMIP:Invalid Scope	invalidScope
14009	CMIP:No Such Action	noSuchAction_er
14010	CMIP:No Such Argument	noSuchArgument_er
14011	CMIP:No Such Attribute	noSuchAttribute_er
14012	CMIP:No Such Object Class	noSuchObjectClass
14013	CMIP:No Such Object Instance	noSuchObjectInstance
14014	CMIP:Resource Limitation	invalidAttributeValue_er
14015	CMIP:Synch Not Supported	syncNotSupported
14016	CMIP process restarted	processingFailure_er
14017	CMIP:Sap Create failure	processingFailure_er
14018	CMIP:Processing failure	processingFailure_er
14019	CMIP:Bind Error	processingFailure_er
14020	CMIP:Received Unexpected Message	processingFailure_er

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		21

Appendix A: Errors

SMS Error	Error Description	CMIP Error
14021	CMIP:Retrieve Attribute Failed	processingFailure_er
14022	CMIP:Invalid Data Type	processingFailure_er
14023	CMIP:Invalid Message Type	processingFailure_er
14024	CMIP:Invalid Attribute	noSuchAttribute_er
14025	CMIP:No Existing Event	noSuchEventType
14026	CMIP:SetListError	setListError_er
14027	CMIP:DeleteListError	processingFailure_er
14028	CMIP:Invalid Error Mapping	processingFailure_er
14029	CMIP:Invalid Object Instance	invalidObjectInstance
14030	CMIP:Missing Attribute Value	missingAttributeValue
14031	CMIP:Mistyped Operation	mistypedOperation
14032	CMIP:No Such Reference Object	noSuchReferenceObject
14033	CMIP:Operation Canceled	operationCancelled
14034	CMIP:No Such Invoke ID	noSuchInvokeId
14035	NPAC:Sending Abort	accessDenied_er
14036	NPAC:Received Abort	operationCancelled

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		22

Appendix B: Message Flow Diagrams

Appendix B. Flow Diagrams

[Graphic Omitted: Appendix B]

B.1 Overview

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

IMPORTANT NOTES

The order of messages in the message flows must be followed by the NPAC SMS SOA and LSMS systems with the exception of the return of the M-EVENT-REPORT confirmations.

The following is an example message flow diagram and legend for elements shown in the diagram.

[Graphic Omitted: an example message flow diagram and legend ]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		23

Appendix B: Message Flow Diagrams

Audit Scenarios

B.1.1 SOA Initiated Audit

[Graphic Omitted: SOA Initiated Audit]

In this scenario, the SOA initiates an audit to the NPAC SMS due to suspected subscription version discrepancies. This scenario applies to non-pooled subscription versions only.

Action is taken by SOA personnel to start an audit due to suspected network discrepancies.

1. The SOA sends a M-CREATE request to the NPAC SMS, requesting an audit. The SOA must specify the following attributes in the request:

subscriptionAuditName – unique English audit name

subscriptionAuditRequestingSP - the service provider requesting the audit

subscriptionAuditServiceProvIdRange - which service provider or all service providers for audit

subscriptionAuditTN-Range - TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.

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. Once the NPAC SMS creates the audit request object, it sends an M-CREATE response back to the SOA that initiated the request.

2.	NPAC SMS responds to M-CREATE.
3.	NPAC SMS sends M-EVENT-REPORT to the service provider SOA for the subscriptionAudit creation.
4.	The service provider SOA confirms the M-EVENT-REPORT.

NPAC SMS begins audit.

5.	NPAC SMS issues a scoped and filtered M-GET for the subscription versions in the audit, to all LSMSs accepting downloads for the NPA-NXX of the subscription version.
6.	Local SMS returns M-GET query data.

NPAC SMS performs the necessary comparisons of each subscription version object.

7.	If a discrepancy is found, NPAC SMS issues a subscriptionAudit-DiscrepancyRpt M-EVENT-REPORT.
8.	Service provider SOA confirms the M-EVENT-REPORT.

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

Flow Continues under B.2.1.1.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		24

Appendix B: Message Flow Diagrams

B.1.1.1 SOA Initiated Audit (continued)

[Graphic Omitted: SOA Initiated Audit (continued)]

1.	If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).
2.	The service provider SOA confirms the M-EVENT-REPORT.
3.	If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).
4.	The old service provider SOA confirms the M-EVENT-REPORT.

NPAC SMS has completed the audit comparisons and corrections.

5.	NPAC SMS issues the subscriptionAuditResults M-EVENT-REPORT to the service provider SOA.
6.	The Service provider SOA confirms the M-EVENT-REPORT.
7.	The NPAC SMS then sends an objectDeletion M-EVENT-REPORT to the SOA for the subscriptionAudit object.
8.	The service provider SOA confirms the M-EVENT-REPORT.
9.	The NPAC SMS issues a local M-DELETE request (housekeeping activity) for the subscriptionAudit object to/from the NPAC SMS. This will schedule the deletion of the subscriptionAudit object on the NPAC SMS. The M-DELETE does not occur until after the “Audit Log Retention Period” which defaults to 90 days.
10.	The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		25

Appendix B: Message Flow Diagrams

B.1.2 SOA Initiated Audit Cancellation by the SOA

The SOA cancels an audit that it initiated.

[Graphic Omitted: SOA Initiated Audit Cancellation by the SOA]

Action is taken by SOA personnel to cancel an audit previously initiated by the SOA.

1.	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.
2.	The NPAC SMS issues an M-DELETE Response.
3.	The NPAC SMS issues an M-EVENT-REPORT objectDeletion to the SOA.
4.	The SOA issues an M-EVENT-REPORT Confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		26

Appendix B: Message Flow Diagrams

B.1.3 SOA Initiated Audit Cancellation by the NPAC

The NPAC cancels an audit that was initiated by an SOA.

[Graphic Omitted: SOA Initiated Audit Cancellation by the NPAC]

Action is taken by NPAC personnel to cancel an audit previously initiated by an SOA.

1.	The NPAC SMS sends an objectDeletion M-EVENT-REPORT to the SOA that initiated the audit request.
2.	The SOA confirms the M-EVENT-REPORT
3.	The NPAC SMS issues a local M-DELETE request (housekeeping activity) to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.
4.	The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		27

Appendix B: Message Flow Diagrams

B.1.4 NPAC Initiated Audit

In this scenario, the NPAC SMS initiates an audit due to suspected subscription version discrepancies. This scenario applies to non-pooled subscription versions only.

[Graphic Omitted: NPAC Initiated Audit]

Action is taken by NPAC personnel to start an audit due to suspected network discrepancies.

1. The NPAC SMS does a Local M-CREATE request to itself for the subscriptionAudit object requesting an audit. The following attributes must be included in the request:

subscriptionAuditName – unique English audit name

subscriptionAuditServiceProvIdRange - which service provider or all service providers for audit

subscriptionAuditTN-Range - TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.

If these attributes are not specified, then the create will fail with a missingAttributesValue error. The following attributes may also be included the request:

subscriptionAuditAttributeList — subscription version attributes to be audited

subscriptionAuditTN-ActivationRange — time range of activation for subscription versions to be audited

2.	The NPAC SMS responds with an M-CREATE response indicating that the subscriptionAudit object was created successfully.
3.	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.
4.	The Local SMS responds to the M-GET request by returning the subscription data that satisfies the scope and filter data.

NPAC SMS performs the comparisons.

If any discrepancies are found, the NPAC SMS will perform the necessary fix to the Local SMS.

5. If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).

6. The old service provider SOA confirms the M-EVENT-REPORT.

7. If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		28

Appendix B: Message Flow Diagrams

8. The new service provider SOA confirms the M-EVENT-REPORT.

NPAC SMS completes the audit.

9. Issue a local M-DELETE request (housekeeping activity) for the subscriptionAudit object to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS. The M-DELETE does not occur until after the “Audit Log Retention Period” which defaults to 90 days.

10. The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		29

Appendix B: Message Flow Diagrams

B.1.5 NPAC Initiated Audit Cancellation by the NPAC

The NPAC SMS cancels an audit that it initiated.

[Graphic Omitted: NPAC Initiated Audit Cancellation by the NPAC]

Action is taken by NPAC personnel to cancel an audit previously initiated by the NPAC SMS.

1. Issue a local M-DELETE request (housekeeping activity) to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.

2. The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		30

Appendix B: Message Flow Diagrams

B.1.6 Audit Query on the NPAC

This scenario shows a service provider query on an existing audit that it initiated.

[Graphic Omitted: Audit Query on the NPAC]

The service provider SOA takes action to query an audit that it initiated.

1. Service provider SOA sends an M-GET request for a subscriptionAudit on the NPAC SMS.

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

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		31

Appendix B: Message Flow Diagrams

B.1.7 SOA Audit Create for Subscription Versions within a Number Pool Block (previously NNP flow 6.1)

In this scenario, the SOA initiates the audit of one or more subscription versions that are within the range of a number pool block. For non-EDR Local SMSs, this involves the subscription version objects. For EDR Local SMSs, this involves both subscription version objects and number pool block objects.

If discrepancies are found, the NPAC SMS will create, modify or delete subscription version and number pool objects, as necessary. The NPAC SMS will report to the SOA the discrepancies with subscription version identifiers. Thus, if a numberPoolBlock object is in error, the discrepancy will be reported as all TNs within the audit range that were also within the block range. However, in this case where an EDR Local SMS erroneously contains a Number Pool Block, the NPAC SMS will send a Number Pool Block delete to the Local SMS, but will not report any discrepancy back to the requesting SOA for this Local SMS if this was the only discrepancy. Subscription version discrepancies will be reported as usual.

B.1.7.1 SOA Creates and NPAC SMS Starts Audit (previously NNP flow 6.1.1)

[Graphic Omitted: SOA Creates and NPAC SMS Starts Audit ]

Action is taken by SOA personnel to start an audit due to suspected network discrepancies.

1. The SOA sends an M-CREATE request to the NPAC SMS requesting an audit. The SOA must specify the following attributes in the request:

subscriptionAuditName – unique English audit name

subscriptionAuditRequestingSP – the service provider requesting the audit

subscriptionAuditServiceProvIdRange – which service provider or all service providers for audit

subscriptionAuditTN-Range – TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.

If these attributes are not specified, then the create will fail with a missingAttributeValue 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.

2.	Once the NPAC SMS creates the audit request object, it sends an M-CREATE response back to the SOA that initiated the request.
3.	NPAC SMS sends M-EVENT-REPORT to the service provider SOA for the subscriptionAudit creation.
4.	The service provider SOA confirms the M-EVENT-REPORT.

NPAC SMS begins audit.

5. The NPAC SMS sends an M-GET request to the non-EDR Local SMS to retrieve the subscription data for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited.

6. The non-EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter data.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		32

Appendix B: Message Flow Diagrams

7. The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the number pool block for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the numberPoolBlock objects to be audited.

8. The EDR Local SMS responds to the M-GET request by returning the number pool object block requested.

9. The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the subscription version objects for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited. No subscription versions with a LNP type of ‘pool’ should exist.

10. The EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter criteria.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		33

Appendix B: Message Flow Diagrams

B.1.7.2 NPAC SMS Performs Audit Comparisons for a SOA initiated Audit including a Number Pool Block (previously NNP flow 6.1.2)

The SOA has sent in the audit request and the NPAC SMS had queried for the necessary data. The NPAC SMS now performs the necessary comparisons.

[Graphic Omitted: NPAC SMS Performs Audit Comparisons for a SOA initiated Audit including a
Number Pool Block]

The NPAC SMS performs object comparisons. The next 4 items apply to each discrepancy.

1.	If a discrepancy is found, NPAC SMS issues a subscriptionAudit-DiscrepancyRpt M-EVENT-REPORT.
2.	Service provider SOA confirms the M-EVENT-REPORT.
	NPAC SMS performs necessary operations to fix each discrepancy on Local SMS. If any subscription versions with a LNP type of ‘pool’ are returned by the EDR Local SMS, they will be deleted and discrepancies reported.
3.	If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of an activated subscription version, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus and a list of failed Local SMSs (minus any updated Local SMSs that no longer contains a discrepancy).
4.	The old service provider SOA confirms the M-EVENT-REPORT.
5.	If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of a subscription version, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the status and a list of failed Local SMSs (minus any updated Local SMSs that no longer contains a discrepancy).
6.	The current service provider SOA confirms the M-EVENT-REPORT.
7.	If any corrections were issued to any Local SMSs that changed the status or numberPoolBlockFailed-SP-List of a number pool block, either by correcting a number pool block or subscription version with LNP type equal to ‘pool’, the numberPoolBlockStatusAttributeValueChange will be sent to the block holder SOA if the numberPoolBlockSOA-Origination indicator is set to “TRUE”. The M-EVENT-REPORT will contain the numberPoolBlockStatus and numberPoolBlockFailed-SP-List.
8.	The block holder service provider confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		34

Appendix B: Message Flow Diagrams

B.1.7.3 NPAC SMS Reports Audit Results (previously NNP flow 6.1.3)

The NPAC SMS has completed the audit. It has reported and fixed all discrepancies found. It now sends the final results to the SOA.

[Graphic Omitted: NPAC SMS Reports Audit Results]

Audit comparisons and fixes are complete.

1.	NPAC SMS issues the subscriptionAuditResults M-EVENT-REPORT to the service provider SOA.
2.	The service provider SOA confirms the M-EVENT-REPORT.
3.	The NPAC SMS then sends an objectDeletion M-EVENT-REPORT to the SOA for the subscriptionAudit object.
4.	The service provider SOA confirms the M-EVENT-REPORT.
5.	The NPAC SMS issues a local M-DELETE request (housekeeping activity) for the subscriptionAudit object to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.
6.	The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		35

Appendix B: Message Flow Diagrams

B.1.8 NPAC SMS Audit Create for Subscription Versions Within a Number Pool Block (previously NNP flow 6.2)

In this scenario, the NPAC SMS initiates an audit due to suspected subscriber data discrepancies. For non-EDR Local SMSs, this involves the subscription version objects. For EDR Local SMSs, this involves both subscription version objects and number pool block objects.

If discrepancies are found, the NPAC SMS will create, modify or delete subscription version and number pool objects, as necessary.

B.1.8.1 NPAC SMS Creates and Starts Audit (previously NNP flow 6.2.1)

[Graphic Omitted: NPAC SMS Creates and Starts Audit]

Action is taken by NPAC personnel to start an audit due to suspected network discrepancies.

1. The NPAC SMS does a Local M-CREATE request for the subscriptionAudit object. The following attributes must be included in the request:

subscriptionAuditName – unique English audit name

subscriptionAuditServiceProvIdRange – which service provider or all service providers for audit

subscriptionAuditTN-Range – TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.

If these attributes are not specified, then the create will fail with a missingAttributeValue error. The following attributes may also be included the request:

subscriptionAuditAttributeList – subscription version attributes to be audited

subscriptionAuditTN-ActivationRange – time range of activation for subscription versions to be audited.

2. The NPAC SMS responds with an M-CREATE response indicating that the subscriptionAudit was created successfully.

NPAC SMS begins audit.

3. The NPAC SMS sends an M-GET request to the non-EDR Local SMS to retrieve the subscription data for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited.

4. The non-EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter data.

5. The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the number pool block for audit processing.

6. The EDR Local SMS responds to the M-GET request by returning the number pool object block requested.

7. The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the subscription version objects for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited. No subscription versions with a LNP type of ‘pool’ should exist.

8. The EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter criteria.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		36

Appendix B: Message Flow Diagrams

B.1.8.2 NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block (previously NNP flow 6.2.2)

The NPAC SMS has queried for the required data and now proceeds to perform the audit comparisons.

[Graphic Omitted: NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block ]

NPAC SMS performs object comparisons.

NPAC SMS performs necessary operations to each fix discrepancy on Local SMS. If any subscription versions with a LNP type of ‘pool’ are returned by the EDR Local SMS, they will be deleted and discrepancies reported.

1.

If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of an activated subscription version, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA with the subscriptionVersionStatus and a list of failed Local SMSs (minus any updated Local SMSs that no longer contain a discrepancy).

2.

The old service provider SOA confirms the M-EVENT-REPORT.

3.

If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of a subscription version, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the subscriptionVersionStatus and a list of failed Local SMSs (minus any updated Local SMSs that no longer contain a discrepancy).

4.

The current service provider SOA confirms the M-EVENT-REPORT.

5.

If any corrections were issued to any Local SMSs that changed the status or numberPoolBlockFailed-SP-List of a number pool block, either by correcting a number pool block or subscription version with LNP type equal to ‘pool’, the numberPoolBlockStatusAttributeValueChange will be sent to the block holder SOA if the numberPoolBlockSOA-Origination indicator is set to “TRUE”. The M-EVENT-REPORT will contain the numberPoolBlockStatus and numberPoolBlockFailed-SP-List.

6.

The block holder service provider confirms the M-EVENT-REPORT.

7. The NPAC SMS issues an M-DELETE request (housekeeping activity) to remove the subscriptionAudit object from the NPAC SMS.

8. The NPAC SMS response is received by the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		37

Appendix B: Message Flow Diagrams

B.2 Service Provider Scenarios

B.2.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: Service Provider Creation by the NPAC]

Action is taken by NPAC SMS personnel to create a new service provider.

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

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

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

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

5.	The NPAC SMS sends an M-CREATE request for the serviceProvNetwork object to each of the Local SMS(s).
6.	The Local SMS(s) will respond by sending an M-CREATE response back to the NPAC SMS.

7.	The NPAC SMS sends an M-CREATE request for the serviceProvNetwork object to each of the SOA(s).
8.	The SOA(s) will respond by sending an M-CREATE response back to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		38

Appendix B: Message Flow Diagrams

B.2.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: Service Provider Deletion by the NPAC]

Action is taken by NPAC SMS personnel to delete an existing service provider.

Check the database to see if the service provider has associated with it NPA-NXX data, LRN data, or subscription versions with status other than old or canceled. If so, deny the request.

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

2. The M-DELETE response is received on the NPAC SMS indicating whether the serviceProv object was deleted successfully.

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

4. The M-DELETE response is received on the NPAC SMS indicating whether the serviceProvNetwork object was deleted successfully.

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

6. The Local SMS(s) will respond by sending an M-DELETE response back to the NPAC SMS.

7.	If the serviceProvNetwork object was deleted, the NPAC SMS sends an M-DELETE request for the serviceProvNetwork object to each of the SOA(s).
8.	The SOA(s) will respond by sending an M-DELETE response back to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		39

Appendix B: Message Flow Diagrams

B.2.3 Service Provider Modification by the NPAC

In this scenario, the NPAC SMS modifies the LNP service provider data.

[Graphic Omitted: Service Provider Modification by the NPAC]

Action is taken by the NPAC personnel to modify data for an existing service provider.

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

2. 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. The M-SET response is received on the NPAC SMS indicating whether the serviceProv object was modified successfully.

If the serviceProvNetworkName or ServiceProviderType changed, perform the next 4 steps:

3. Issue a local M-SET request for the serviceProvNetwork object to/from the NPAC SMS. This will attempt to set the specified information on the NPAC SMS.

4. 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. The M-SET response is received on the NPAC SMS indicating whether the serviceProvNetwork object was modified successfully.

5. NPAC SMS performs an M-SET for the serviceProvNetwork to all the Local SMS(s) if the service provider name or service provider type changed.

6. The Local SMS(s) respond.

7.	NPAC SMS performs an M-SET for the service ProvNetwork to all the SOA(s) if the service provider name or service provider type changed.
8.	The SOA(s) respond.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		40

Appendix B: Message Flow Diagrams

B.2.4 Service Provider Modification by the Local SMS

In this scenario, the Local SMS modifies its own service provider data.

[Graphic Omitted: Service Provider Modification by the Local SMS]

Action is taken by the Local SMS personnel to modify their own service provider data.

1.	The Local SMS sends an M-SET request to the NPAC SMS to modify their service provider information.
	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.
	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.
2.	The NPAC SMS sends an M-SET response back to the Local SMS that initiated the request

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		41

Appendix B: Message Flow Diagrams

B.2.5 Service Provider Modification by the SOA

In this scenario, the SOA modifies its own service provider data.

[Graphic Omitted: Service Provider Modification by the SOA]

Action is taken by the SOA to modify their own service provider data.

1.	The SOA sends an M-SET request to the NPAC SMS to modify their service provider information.
	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 is returned.
	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.
2.	The NPAC SMS sends an M-SET response back to the SOA that initiated the request.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		42

Appendix B: Message Flow Diagrams

B.2.6 Service Provider Query by the Local SMS

In this scenario, the Local SMS queries their own service provider data.

[Graphic Omitted: Service Provider Query by the Local SMS]

Action is taken by the Local SMS personnel to query their own service provider data.

1.	The Local SMS sends an M-GET request to the NPAC SMS requesting their own service provider information.
	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.
2.	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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		43

Appendix B: Message Flow Diagrams

B.2.7 Service Provider Query by the SOA

In this scenario, the SOA queries their own service provider data.

[Graphic Omitted: Service Provider Query by the SOA]

Action is taken by the SOA or SOA personnel to query their own service provider data.

1.	The SOA sends an M-GET request to the NPAC SMS requesting their own service provider information.
	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.

2. The NPAC SMS sends an M-GET response containing the requested service provider information back to the SOA that initiated the request.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		44

Appendix B: Message Flow Diagrams

B.3 Service Provider Network Data Scenarios

B.3.1 NPA-NXX Scenarios

B.3.1.1 NPA-NXX Creation by the NPAC

In this scenario, NPAC SMS creates new NPA-NXX data for an LNP service provider.

[Graphic Omitted: NPA-NXX Creation by the NPAC]

Action is taken by the NPAC Personnel to create an NPA-NXX for a specified service provider.

1. The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvNPA-NXX object.

2. The NPAC SMS receives the M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

3. If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

4. The Local SMS(s) respond by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

5. If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

6. The SOA(s) respond by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		45

Appendix B: Message Flow Diagrams

B.3.1.2 NPA-NXX Deletion by the NPAC

In this scenario, NPAC SMS deletes an NPA-NXX for an LNP service provider.

[Graphic Omitted: NPA-NXX Deletion by the NPAC]

Action is taken by NPAC SMS personnel to delete an NPA-NXX for a specified service provider.

1.	The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvNPA-NXX object.
	Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” or “canceled.” Also, check if any NPA-NXX-Xs exist with this NPA-NXX. If so, respond with an error and terminate processing at this point.

2. The NPAC SMS receives the M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

3. If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

4. The Local SMS(s) responds by sending an M-DELETE response to the NPAC SMS indicating whether the serviceProvNPA-NXX object was deleted successfully.

5. If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

6. The SOA(s) responds by sending an M-DELETE response to the NPAC SMS indicating whether the serviceProvNPA-NXX object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		46

Appendix B: Message Flow Diagrams

B.3.1.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: NPA-NXX Creation by the Local SMS]

Action is taken by the Local SMS personnel to create an NPA-NXX available for porting in their own service provider network.

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

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

3. If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

4. The Local SMS(s) responds by sending an M-CREATE Response indicating whether the serviceProvNPA-NXX object was created successfully.

5. If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

6. The SOA(s) responds by sending an M-CREATE Response indicating whether the serviceProvNPA-NXX object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		47

Appendix B: Message Flow Diagrams

B.3.1.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: NPA-NXX Creation by the SOA]

Action is taken by the SOA personnel to create an NPA-NXX available for porting in their own service provider network.

1.	The SOA sends an M-CREATE request to the NPAC requesting that an NPA-NXX object be created for their own service provider network.
	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 is returned to the SOA that initiated the request.
2.	The NPAC SMS sends an M-CREATE response back to the SOA for the serviceProvNPA-NXX object.

3. If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

4. The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

5. If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

6. The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		48

Appendix B: Message Flow Diagrams

B.3.1.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: NPA-NXX Deletion by the Local SMS]

Action is taken by the Local SMS personnel to delete an NPA-NXX for their own service provider network data.

1.	The Local SMS sends an M-DELETE request to the NPAC SMS requesting that an NPA-NXX object be deleted for their own service provider.
	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.
	Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” without a Failed SP List or canceled.” Also, check if any NPA-NXX-Xs or Number Pool Blocks exist with this NPA-NXX. If so, terminate processing at this point.

2. The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

3. If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

4. The Local SMS(s) responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

5. If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

6. The SOA(s) responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		49

Appendix B: Message Flow Diagrams

B.3.1.6 NPA-NXX Deletion by SOA

In this scenario, the SOA deletes a new NPA-NXX for its own service provider network data.

[Graphic Omitted: NPA-NXX Deletion by SOA]

Action is taken by the SOA personnel to delete an NPA-NXX for their own service provider network data.

1.	The SOA sends an M-DELETE request to the NPAC SMS requesting that an NPA-NXX object be deleted for their own service provider.
	The NPAC SMS verifies that the service provider that owns the NPA-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.
	Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” or “canceled.” Also, check if any NPA-NXX-Xs or Number Pool Blocks exist with this NPA-NXX. If so, terminate processing at this point.

2. The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

3. If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

4. The Local SMS(s) respond by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.

5. If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.

6. The SOA(s) respond by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		50

Appendix B: Message Flow Diagrams

B.3.1.7 NPA-NXX Query by the Local SMS

In this scenario, the Local SMS queries for NPA-NXX data.

[Graphic Omitted: NPA-NXX Query by the Local SMS]

Action is taken by Local SMS personnel to query for a serviceProvNPA-NXX.

1. The Local SMS sends an M-GET request to the NPAC SMS for the serviceProvNPA-NXX object.

2. The NPAC SMS responds by sending an M-GET response containing the NPA-NXX data back to the Local SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		51

Appendix B: Message Flow Diagrams

B.3.1.8 NPA-NXX Query by the SOA

In this scenario, the SOA queries for NPA-NXX updates.

[Graphic Omitted: NPA-NXX Query by the SOA]

Action is taken by SOA personnel to query for a serviceProvNPA-NXX.

1. The SOA sends an M-GET request to the NPAC SMS for the serviceProvNPA-NXX object.

2. The NPAC SMS responds by sending an M-GET response containing the NPA-NXX data back to the SOA.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		52

Appendix B: Message Flow Diagrams

B.3.2 LRN Scenarios

B.3.2.1 LRN Creation by the NPAC

In this scenario, the NPAC SMS creates an LRN.

[Graphic Omitted: LRN Creation by the NPAC]

Action is taken by the NPAC personnel to create an LRN for an existing service provider.

1. The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvLRN object.

2. The NPAC SMS receives the M-CREATE response indicating whether the serviceProvLRN object was created successfully.

3. If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) for the serviceProvLRN object.

4. The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

5. If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) for the serviceProvLRN object.

6. The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		53

Appendix B: Message Flow Diagrams

B.3.2.2 LRN Creation by the SOA

In this scenario, the SOA creates an LRN for its own service provider network data.

[Graphic Omitted: LRN Creation by the SOA]

Action is taken by the SOA personnel to create an LRN for their own network data.

1.	The SOA sends an M-CREATE request to the NPAC SMS requesting that an LRN object be created for their own network data.
	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.

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

3. If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) for the serviceProvLRN object.

4. The Local SMS(s) respond by sending an M-CREATE response indicating whether the service provider LRN object was created successfully.

5. If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) for the serviceProvLRN object.

6. The SOA(s) respond by sending an M-CREATE response indicating whether the service provider LRN object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		54

Appendix B: Message Flow Diagrams

B.3.2.3 LRN Deletion by the SOA

In this scenario, the SOA deletes an LRN for their own service provider network data.

[Graphic Omitted: LRN Deletion by the SOA]

Action is taken by the SOA personnel to delete an LRN for their own network data.

1.	The SOA sends an M-DELETE request to the NPA requesting that an LRN object be deleted.
	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.
	Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” without a Failed SP List or “canceled.” Also, check if any Number Pool Blocks exist with this LRN. If so, an M-SET error response complexity limitation is returned.

2. The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

3. If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) for the serviceProvLRN object.

4. The Local SMS(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.

5. If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) for the serviceProvLRN object.

6. The SOA(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a	NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.	55

Appendix B: Message Flow Diagrams

B.3.2.4 LRN Query by the SOA

In this scenario, the SOA queries LRN data.

[Graphic Omitted: LRN Query by the SOA]

Action is taken by SOA personnel to an LRN for a specified service provider.

1.	The SOA sends an M-GET request to the NPAC SMS for the serviceProvLRN object.
2.	The NPAC SMS responds by sending an M-GET response containing the data back to the SOA.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		56

Appendix B: Message Flow Diagrams

B.3.2.5 LRN Deletion by the NPAC

In this scenario, the NPAC SMS deletes an LRN.

[Graphic Omitted: LRN Deletion by the NPAC]

Action is taken by the NPAC SMS personnel to delete an LRN for a service provider.

1.	The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvLRN object.
	Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” Also, check if any Number Pool Blocks exist with this LRN. If so, terminate processing at this point.

2. The NPAC SMS receives the M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

3. If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) for the serviceProvLRN object.

4. The Local SMS(s) responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

5. If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) for the serviceProvLRN object.

6. The SOA(s) responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		57

Appendix B: Message Flow Diagrams

B.3.2.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: LRN Creation by the Local SMS]

Action is taken by the Local SMS personnel to create an LRN for their own network data.

1.	The SMS sends an M-CREATE request to the NPAC requesting that an LRN object be created for their own network data.
	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.

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

3. If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) for the serviceProvLRN object.

4. The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

5. If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) for the serviceProvLRN object.

6. The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		58

Appendix B: Message Flow Diagrams

B.3.2.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: LRN Deletion by the Local SMS]

Action is taken by the Local SMS personnel to delete an LRN for their own network data.

1.	The Local SMS sends an M-DELETE request to the NPAC requesting that an LRN object be deleted.
	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.
	Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” Also, check if any Number Pool Blocks exist with this LRN. If so, an M-SET Error Response complexity limitation is returned.

2. The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.

3. If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) for the serviceProvLRN object.

4. The Local SMS(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.

5. If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) for the serviceProvLRN object.

6. The SOA(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		59

Appendix B: Message Flow Diagrams

B.3.2.8 LRN Query by the Local SMS

In this scenario, the Local SMS queries LRN data.

[Graphic Omitted: LRN Query by the Local SMS]

Action is taken by Local SMS personnel to query an LRN for a specified service provider.

1.	The Local SMS sends an M-GET request to the NPAC SMS for the serviceProvLRN object.
2.	The NPAC SMS responds by sending an M-GET response containing the data back to the Local SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		60

Appendix B: Message Flow Diagrams

B.3.2.9 Network Data Download

DELETED. This scenario is superceded by the text and flows in section B.7, Local SMS and SOA Recovery.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		61

Appendix B: Message Flow Diagrams

B.3.2.10 Scoped/Filtered GET of Network Data

This scenario shows a request for network data via a scoped/filtered M-GET. Scoping and filtering can be done from the serviceProvNetwork object.

[Graphic Omitted: Scoped/Filtered GET of Network Data]

Action is taken by the Local SMS personnel to request network data via a scoped/filtered M-GET request.

1. The Local SMS sends a scoped/filtered M-GET request to the NPAC SMS.

2. The NPAC SMS sends the first network data object (serviceProvNetwork) that passes the scope/filter criteria to the Local SMS that initiated the request.

3. The NPAC SMS sends continues to send to the Local SMS all network data objects (serviceProvNetwork) that pass the scope/filter criteria.

4. A final M-GET response is sent to the Local SMS that initiated the request once all scoped/filtered network objects have been returned, and will contain no data.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		62

Appendix B: Message Flow Diagrams

B.3.2.11 Scoped/Filtered GET of Network Data from SOA

This scenario shows a request for network data via a scoped/filtered M-GET. Scoping and filtering is done from serviceProvNetwork.

[Graphic Omitted: Scoped/Filtered GET of Network Data from SOA]

Action is taken by the SOA personnel to request network data via a scoped/filtered M-GET request.

1. The SOA sends a scoped/filtered M-GET request to the NPAC SMS.

2. The NPAC SMS sends the first network data object (serviceProvNetwork, serviceProvNPA-NXX, serviceProvLRN, serviceProvNPA-NXX-X) that passes the scope/filter criteria to the SOA that initiated the request.

3. The NPAC SMS continues to send to the SOA all network data objects object (serviceProvNetwork, serviceProvNPA-NXX, serviceProvLRN, serviceProvNPA-NXX-X) that pass the scope/filter criteria.

4. A final M-GET response is sent to the SOA that initiated the request once all scoped/filtered network objects have been returned, and will contain no data.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		63

Appendix B: Message Flow Diagrams

B.3.3 Service Provider NPA-NXX-X

This section contains the flows that demonstrate service provider NPA-NXX-X creation, modification, deletion and query.

B.3.3.1 Service Provider NPA-NXX-X Create by NPAC SMS (previously NNP flow 1.1)

In this scenario, the NPAC SMS creates the serviceProvNPA-NXX-X object at the request of the number pool administrator.

[Graphic Omitted: Service Provider NPA-NXX-X Create by NPAC SMS]

Action is taken by NPAC SMS personnel to create the serviceProvNPA-NXX-X object.

1. The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvNPA-NXX-X object. The NPAC SMS provides the following attributes:

serviceProvNPA-NXX-X-Value
serviceProvNPA-NXX-X-EffectiveTimeStamp
serviceProvID

The NPAC SMS validates the following:

• NPA-NXX of the serviceProvNPA-NXX-X-value is an existing NPA-NXX.

• The effective date is greater than or equal to the NPA-NXX Live TimeStamp.

• The effective date is greater than or equal to the current date.

• Verify no serviceProvNPA-NXX-X object exists with this NPA-NXX-X value.

• The service provider ID is an existing service provider.

	The NPAC SMS rejects the request if any subscriptionVersionNPAC objects exist with a status of pending, conflict, cancel-pending or failed for a TN specified by the serviceProvNPA-NXX-X-value and an active subscriptionVersionNPAC object does not exist for that TN or the subscription version is a Port-To-Original request.
2.	The NPAC SMS receives the M-CREATE request and sets the serviceProvNPA-NXX-X-ID, serviceProvNPA-NXX-X-CreationTimeStamp and serviceProvNPA-NXX-X-ModifiedTimeStamp. The NPAC SMS then issues a response indicating whether the serviceProvNPA-NXX-X object was successfully created.
3.	The NPAC SMS sends an M-CREATE request for the serviceProvNPA-NXX-X object to all Local SMSs who support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX. The following attributes are sent in the M-CREATE:

serviceProvNPA-NXX-X-ID
serviceProvNPA-NXX-X-Value
serviceProvNPA-NXX-X-CreationTimeStamp
serviceProvNPA-NXX-X-EffectiveTimeStamp
serviceProvNPA-NXX-X-ModifiedTimeStamp
serviceProvNPA-NXX-X-DownloadReason

4. The Local SMS responds by sending the M-CREATE response indicating whether the serviceProvNPA-NXX-X object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		64

Appendix B: Message Flow Diagrams

5. At the same time as step 3, the NPAC SMS sends an M-CREATE request for the serviceProvNPA-NXX-X object to all SOAs who support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX. The following attributes are sent in the M-CREATE:

serviceProvNPA-NXX-X-ID
serviceProvNPA-NXX-X-Value
serviceProvNPA-NXX-X-CreationTimeStamp
serviceProvNPA-NXX-X-EffectiveTimeStamp
serviceProvNPA-NXX-X-ModifiedTimeStamp
serviceProvNPA-NXX-X-DownloadReason

6. The SOA responds by sending the M-CREATE response indicating whether the serviceProvNPA-NXX-X object was created successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		65

Appendix B: Message Flow Diagrams

B.3.3.1.1 Service Provider NPA-NXX-X Create by NPAC SMS (continued)

[Graphic Omitted: Service Provider NPA-NXX-X Create by NPAC SMS (continued)]

	NPAC SMS decides if this NPA-NXX-X Create is the first use of the NPA-NXX.
1.	If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the accepting Local SMSs.
2.	The Local SMS confirms the M-EVENT-REPORT.
3.	The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the Current Service Provider SOA.
4.	The SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		66

Appendix B: Message Flow Diagrams

B.3.3.2 Service Provider NPA-NXX-X Modification by NPAC SMS (previously NNP flow 1.2)

In this scenario, the NPAC SMS modifies the serviceProvNPA-NXX-X object at the request of the number pool administrator.

[Graphic Omitted: Service Provider NPA-NXX-X Modification by NPAC SMS]

Action is taken by NPAC SMS personnel to initiate a modification to the serviceProvNPA-NXX-X object.

1. NPAC SMS sends the M-SET request to itself to update the following attributes:

serviceProvNPA-NXX-X-EffectiveTimeStamp
serviceProvNPA-NXX-X-ModifiedTimeStamp

2. NPAC SMS responds indicating whether the modification was successful. The update request will fail if the effective timestamp is less than the NPA-NXX Live TimeStamp or if the current date is greater than or equal to the object’s current effective timestamp.

3. NPAC SMS sends the M-SET request to update the serviceProvNPA-NXX-X to all Local SMS that support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.

4.	At the same time as step 3, NPAC SMS sends the M-SET request to update the serviceProvNPA-NXX-X to all SOAs that support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.
5.	Local SMS respond to the M-SET indicating whether the modification was successful.
6.	SOA respond to the M-SET indicating whether the modification was successful.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		67

Appendix B: Message Flow Diagrams

B.3.3.3 Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence (previously NNP flow 1.3)

In this scenario, the NPAC SMS deletes the serviceProvNPA-NXX-X object at the request of the number pool administrator. This deletion takes place prior to the effective date or after the effective date, but prior to the number pool block object being created for the NPA-NXX-X value.

[Graphic Omitted: Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence]

Action is taken by NPAC SMS personnel to delete a serviceProvNPA-NXX-X object.

1. The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvNPA-NXX-X object.

2. The NPAC SMS receives the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was successfully deleted.

3. The NPAC SMS sends the M-DELETE request to all Local SMS for the serviceProvNPA-NXX-X object who support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.

4. At the same time as step 3, the NPAC SMS sends the M-DELETE request to all SOAs for the serviceProvNPA-NXX-X object who support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.

5. The Local SMS responds by sending the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was deleted successfully.

6. The SOA responds by sending the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was deleted successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		68

Appendix B: Message Flow Diagrams

B.3.3.4 Service Provider NPA-NXX-X Query by SOA or LSMS (previously NNP flow 1.4)

In this scenario, the service provider queries the NPAC SMS for one or more serviceProvNPA-NXX-X objects from the SOA or Local SMS.

[Graphic Omitted: Service Provider NPA-NXX-X Query by SOA or LSMS]

Service provider personnel take action to query the NPAC SMS for one or more serviceProvNPA-NXX-X objects.

1. SOA or Local SMS sends an M-GET for a single serviceProvNPA-NXX-X object by serviceProvNPA-NXX-X-ID or a scope and filtered M-GET for one or more serviceProvNPA-NXX-X objects.

2. If the NPAC SMS finds one or more serviceProvNPA-NXX-X objects that match the input criteria, the NPAC SMS responds with the single or linked reply of serviceProvNPA-NXX-X object(s). Otherwise it returns an empty result.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		69

Appendix B: Message Flow Diagrams

B.3.4 Number Pool Block

This section contains the flows that demonstrate number pool block creation, modification and deletion.

B.3.4.1 Number Pool Block Create/Activate by SOA (previously NNP flow 2.1)

In this scenario, the block holder service provider sends in the M-ACTION for the number pool block to be created.

[Graphic Omitted: Number Pool Block Create/Activate by SOA]

Action is taken by the block holder service provider SOA to create a number pool block.

1. The block holder service provider SOA sends the M-ACTION numberPoolBlock-Create to the NPAC SMS. The block holder service provider must provide the following attributes:

numberPoolBlockNPA-NXX-X
numberPoolBlockLRN
numberPoolBlockSPID
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN

If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes must be included:

numberPoolBlockWSMSC-DPC
numberPoolBlockWSMSC-SSN

If the indicator is not set in the service provider’s profile, the WSMSC data cannot be included.

If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes must be included:

numberPoolBlockSVType

If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may optionally be included:

alternativeSPID

The NPAC SMS verifies the following and returns the indicated error if the condition fails:

• The serviceProvNPA-NXX-X object exists for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is ‘no-npa-nxx-x-found’.

• The service provider associated with the SOA is equal to the numberPoolBlockSPID and is owner of the corresponding serviceProvNPA-NXX-X object. If the condition fails, error returned is ‘soa-not-authorized’.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		70

Appendix B: Message Flow Diagrams

• All attributes are valid. If the condition fails, error returned is ‘invalid-data-values’.

• A numberPoolBlockNPAC object does not already exist or one exists with a status of ‘old’ with an empty list of failed service providers for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is ‘number-pool-block-already-exists’.

• The current date is greater than or equal to the serviceProvNPA-NXX-X-EffectiveTimeStamp of the corresponding serviceProvNPA-NXX-X object. If the condition fails, error returned is ‘prior-to-effective-date’.

• There are no subscription version objects within the given TN range with a status of pending, conflict, cancel-pending or failed (“pending-like”) and no active subscription version for that TN. If the condition fails, error returned is ‘invalid-subscription-versions’.

	Any other error will be returned as “failed”. If an error is found, the NPAC SMS returns the M-ACTION reply with the error. No further processing occurs.
2.	If the request is valid, the NPAC SMS creates the numberPoolBlockNPAC object. The numberPoolBlockSOA-Origination indicator is set to TRUE. The numberPoolBlockActivationTimeStamp, numberPoolBlockCreationTimeStamp, numberPoolBlockBroadcastTimeStamp and numberPoolBlockModifiedTimeStamp are set. The numberPoolBlockStatus is set to “sending”.
3.	The NPAC SMS responds to the M-CREATE.
4.	If the request is valid, the NPAC SMS will create the corresponding subscriptionVersionNPAC object(s). If an active, partial-failure, sending or disconnect-pending (“active-like”) subscription version exists within the block’s TN range, no new subscription version will be created for that TN. For the subscription versions created, the subscriptionLNPType will be set to ‘pool’, subscriptionVersionStatus will be set to “sending” and the subscriptionModifiedTimeStamp, subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionCreationTimeStamp will be set.
5.	The NPAC SMS will respond with the M-CREATE response.
6.	NPAC SMS responds to the M-ACTION.
7.	NPAC SMS sends the M-EVENT-REPORT objectCreation for the numberPoolBlockNPAC to the SOA. The following attributes will be sent in the objectCreation notification:

numberPoolBlockId
numberPoolBlockSOA-Origination
numberPoolBlockCreationTimeStamp
numberPoolBlockStatus
numberPoolBlockNPA-NXX-X
numberPoolBlockSPID
numberPoolBlockLRN
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN

If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes will be included:

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		71

Appendix B: Message Flow Diagrams

numberPoolBlockWSMSC-DPC
numberPoolBlockWSMSC-SSN

If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes will be included:

numberPoolBlockSVType

If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may optionally be included:

alternativeSPID

8. The block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		72

Appendix B: Message Flow Diagrams

B.3.4.2 Number Pool Block Create by NPAC SMS (previously NNP flow 2.2)

In this scenario, the NPAC SMS creates the number pool block on or after the effective date of the serviceProvNPA-NXX-X object. Since the SOA does not send in the creation request, all notifications (M-EVENT-REPORTs) to the SOA will be suppressed.

[Graphic Omitted: Number Pool Block Create by NPAC SMS]

Action is taken by the NPAC SMS to create a number pool block.

1. NPAC SMS personnel create the numberPoolBlockNPAC on the NPAC SMS for a service provider block holder using the M-ACTION, numberPoolBlock-Create. The following attributes are required:

numberPoolBlockNPA-NXX-X
numberPoolBlockSPID
numberPoolBlockLRN
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN

If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile, the following attributes must be provided:

numberPoolBlockWSMSC-DPC
numberPoolBlockWSMSC-SSN

If the indicator is not set, the request will be rejected.

If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes must be included:

numberPoolBlockSVType

If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may optionally be included:

alternativeSPID

The NPAC SMS verifies the following and returns the indicated error if the condition fails:

• The serviceProvNPA-NXX-X object exists for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is no-npa-nxx-x-found.

• All attributes are valid. If the condition fails, error returned is invalid-data-values.

• A numberPoolBlockNPAC object does not already exist or one exists with a status of ‘old’ with an empty list of failed service providers for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is number-pool-block-already-exists.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		73

Appendix B: Message Flow Diagrams

• The current date is greater than or equal to the serviceProvNPA-NXX-X-EffectiveTimeStamp of the corresponding serviceProvNPA-NXX-X object. If the condition fails, error returned is prior-to-effective-date.

• There are no subscription version objects within the given TN range with a status of pending, conflict, cancel-pending or failed (“pending-like”) and no active subscription version for that TN. If the condition fails, error returned is invalid-subscription-versions.

	Any other error will be returned as “failed”. If an error is found, the NPAC SMS returns the M-ACTION reply with the error. No further processing occurs.
2.	The NPAC SMS creates the numberPoolBlockNPAC object. The numberPoolBlockSOA-Origination indicator is set to FALSE. The numberPoolBlockCreationTimeStamp, numberPoolBlockActivationTimeStamp, numberPoolBlockBroadcastTimeStamp and numberPoolBlockModifiedTimeStamp are set. The numberPoolBlockStatus is set to “sending”.
3.	NPAC SMS responds to the M-CREATE.
4.	The NPAC SMS creates the corresponding subscriptionVersionNPAC object.(s). If an active, partial-failure, sending or disconnect-pending (“active-like”) subscription version exists within the block’s TN range, no new subscription version will be created for that TN. For the subscription version created, the subscriptionLNPType will be set to ‘pool’, the subscriptionVersionStatus will be set to “sending” and the subscriptionModifiedTimeStamp, subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionCreationTimeStamp will be set.
5.	NPAC SMS responds to the M-CREATE.
6.	NPAC SMS responds to the M-ACTION.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		74

Appendix B: Message Flow Diagrams

B.3.4.3 Number Pool Block Create Broadcast Successful to Local SMS (previously NNP flow 2.3.1)

In this scenario, the number pool block and corresponding subscription versions have been created on the NPAC SMS. The NPAC SMS now begins to broadcast the subscriptionVersions and numberPoolBlock data to the Local SMSs.

[Graphic Omitted: Number Pool Block Create Broadcast Successful to Local SMS]

1. NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the non-EDR Local SMS, if it is accepting downloads for the NPA-NXX of the subscription versions. This action contains all data required to create the subscription versions with the subscriptionLNPType of ‘pool’.

2. At the same time as step 1, the NPAC SMS sends the M-CREATE for the numberPoolBlock to the EDR Local SMS.

3. The non-EDR Local SMS verifies the action is valid and returns the M-ACTION reply. If the non-EDR Local SMS does not respond to the M-ACTION request, the NPAC SMS will retry the request a tunable amount of times.

4. The EDR Local SMS sends to the NPAC SMS the results of the M-CREATE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.

5.	The non-EDR Local SMS proceeds to execute all the creates specified by the action. The non-EDR Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the subscription version creates.
6.	NPAC SMS confirms the M-EVENT-REPORT.

The NPAC SMS now waits for all the subscriptionVersionLocalSMS-ActionResults M-EVENT-REPORTs a tunable amount of time (default 1 hour).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		75

Appendix B: Message Flow Diagrams

B.3.4.4 Number Pool Block Create: Successful Broadcast (previously NNP flow 2.3.2)

In this scenario, the NPAC SMS has just completed the successful broadcast of a numberPoolBlock and corresponding subscriptionVersions.

[Graphic Omitted: Number Pool Block Create: Successful Broadcast]

1.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		76

Appendix B: Message Flow Diagrams

B.3.4.5 Number Pool Block Create Broadcast to Local SMS: Failure (previously NNP flow 2.4)

In this scenario, the NPAC SMS has a numberPoolBlock and corresponding subscriptionVersions in ‘sending’ state for creation to the Local SMSs and no Local SMS will respond successfully to the broadcast.

[Graphic Omitted: Number Pool Block Create Broadcast to Local SMS: Failure]

1. NPAC SMS sends the M-ACTION subscriptionVersionLocalSMS-Create request to all the non-EDR Local SMSs.

2. At the same time as step 1, NPAC SMS sends the M-CREATE numberPoolBlock request to all the EDR Local SMSs.

NPAC SMS waits for all the responses.

NPAC SMS retries any Local SMS who does not respond.

NPAC SMS receives no responses or receives errors in response to the create requests from all Local SMSs (EDR and non-EDR).

3.	NPAC SMS sets each subscriptionVersionNPAC’s subscriptionVersionStatus to ‘failed’. The subscriptionFailed-SP-List gets updated with the failed service providers and the subscriptionModifiedTimeStamp gets set.
4.	NPAC SMS responds to the M-SET.

5.	NPAC SMS sets the numberPoolBlock’s numberPoolBlockStatus to ‘failed’. The numberPoolBlockFailed-SP-List gets updated with the failed service providers, both EDR and non-EDR, and the subscriptionModifiedTimeStamp gets set.
6.	NPAC SMS responds to the M-SET.

7.	If the numberPoolBlock’s SOA Origination indicator is set to ‘true’, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, for the numberPoolBlock with the numberPoolBlockStatus set to ‘failed’ and the numberPoolBlockFailed-SP-List to the block holder SOA.
8.	The SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		77

Appendix B: Message Flow Diagrams

B.3.4.6 Number Pool Block Create Broadcast to Local SMS: Partial Failure (previously NNP flow 2.5.1)

In this scenario, the NPAC SMS has a numberPoolBlock and corresponding subscriptionVersions in ‘sending’ state for creation to the Local SMSs and some but not all Local SMS will respond successfully to the broadcast resulting in a state of “partial-failure” for one or more of the subscription versions and the number pool block.

[Graphic Omitted: Number Pool Block Create Broadcast to Local SMS: Partial Failure]

1. NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the non-EDR Local SMS, if it is accepting downloads for the NPA-NXX of the subscription versions. This action contains all data required to create the subscription versions with the subscriptionLNPType of ‘pool’.

2. At the same time as step 1, NPAC SMS sends the M-CREATE for the numberPoolBlock to the EDR Local SMS.

3. The non-EDR Local SMS verifies the action is valid and returns an acknowledgment. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-ACTION request a tunable amount of times.

4. The EDR Local SMS sends to the NPAC SMS the results of the M-CREATE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.

5.	The non-EDR Local SMS proceeds to execute all the creates specified by the action. The non-EDR Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the creates.
6.	NPAC SMS confirms the M-EVENT-REPORT.

The NPAC SMS now waits for all the subscriptionVersionLocalSMS-ActionResults M-EVENT-REPORTs responses a tunable amount of time (default 1 hour).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		78

Appendix B: Message Flow Diagrams

B.3.4.7 Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates (previously NNP flow 2.5.2)

All retries have been exhausted and the time for the subscriptionVersionLocalSMS-CreateResults to be received has expired for a broadcast of a number pool block create.

[Graphic Omitted: Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates]

NPAC SMS receives a successful response to the create request from at least one, but not all, Local SMSs (EDR and non-EDR).

The NPAC SMS must now set the numberPoolBlock to partial-failure and subscriptionVersion objects to partial-failure or active depending upon which Local SMSs failed the request. If an EDR Local SMS failed, the numberPoolBlock and ALL subscriptionVersions broadcast will be set to partial-failure. If a non-EDR Local SMS failed all the creates, the numberPoolBlock and ALL subscriptionVersion broadcast will be set to partial-failure. If a non-EDR Local SMS fails only some of the subscriptionVersion creates, the numberPoolBlock will be set to partial-failure along with the subscriptionVersions the non-EDR Local SMS failed. The other subscription versions may be set to ‘active’ if all EDR Local SMSs were successful and all other non-EDR Local SMSs were successful for those subscription versions.

The numberPoolBlockFailed-SP-List on the number pool block object contains all the service providers who failed to receive either the number pool block or any of the subscription versions. The subscriptionFailed-SP-List on each subscription version object contains only those service providers who failed to receive that subscription version or the number pool block object.

The partial-failure status will be removed from both objects when all subscriptionVersions and numberPoolBlocks are successfully resent or recovered.

1.	NPAC SMS issues an M-SET to the subscriptionVersionNPAC(s) setting the subscriptionVersionStatus to ‘partially-failed’ or ‘active’ and setting the subscriptionFailed-SP-List to the list of failed service providers. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS issues an M-SET to the numberPoolBlockNPAC setting the numberPoolBlockStatus to ‘partially-failed’ and setting the numberPoolBlockFailed-SP-List to the list of failed service providers. The numberPoolBlockModifiedTimeStamp is also set.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the block holder SOA the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, with the numberPoolBlockStatus set to ‘partially-failed’ and the numberPoolBlockFailed-SP-List.
6.	The block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		79

Appendix B: Message Flow Diagrams

B.3.4.8 Number Pool Block Create Resend Broadcast (previously NNP flow 2.6)

In this scenario, the NPAC SMS has a number pool block and corresponding subscription versions with LNP type of ‘pool’ in a failed or partially-failed state. The NPAC SMS will resend the requests to the Local SMSs.

[Graphic Omitted: Number Pool Block Create Resend Broadcast]

Action is taken by the NPAC SMS personnel to resend a previously failed activation of a number pool block and corresponding subscription versions.

1.	NPAC SMS issues the M-SET to modify the numberPoolBlockStatus to ‘sending’ on the number pool block object. The numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp also get set.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS issues the M-SET to modify the subscriptionVersionStatus to ‘sending’ on the subscription version object. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp also get set.
4.	NPAC SMS responds to the M-SET.

5. NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the non-EDR Local SMS if it had previously failed the create request. This action contains all data to create the subscription versions with LNP type of ‘pool’. If the create is for a single subscription version, the M-CREATE will be sent. A mixture of both actions and single creates is possible depending upon the subscription versions that need to be created.

6. At the same time as step 5, the NPAC SMS sends the M-CREATE for the numberPoolBlock to the EDR Local SMS if it had previously failed the create request.

7. The non-EDR Local SMS verifies the action is valid and returns the M-ACTION reply. If the non-EDR Local SMS does not respond to the M-ACTION request, the NPAC SMS will retry the request a tunable number of times.

8. The EDR Local SMS sends to the NPAC SMS the results of the M-CREATE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.

9.	The non-EDR Local SMS proceeds to execute all the creates specified by the action. The non-EDR Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the subscription version creates.
10.	NPAC SMS confirms the M-EVENT-REPORT.

The NPAC SMS now waits for all the subscriptionVersionLocalSMS-CreateResults M-EVENT-REPORTs a tunable amount of time (default 1 hour).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		80

Appendix B: Message Flow Diagrams

B.3.4.9 Number Pool Block Create Successful Resend Updates (previously NNP flow 2.7)

In this scenario, the NPAC SMS has successfully re-sent the creation of a number pool block and corresponding subscription versions. The NPAC SMS now updates the state of the objects on the NPAC SMS.

[Graphic Omitted: Number Pool Block Create Successful Resend Updates]

1.	NPAC SMS updates the numberPoolBlockNPAC by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		81

Appendix B: Message Flow Diagrams

B.3.4.10 Number Pool Block Create Failed Resend NPAC SMS Updates (previously NNP flow 2.8)

In this scenario, the NPAC SMS has unsuccessfully resent the creation of a number pool block and corresponding subscription versions and the status is still failed for the objects. The NPAC SMS now updates the state of the objects on the NPAC SMS.

[Graphic Omitted: Number Pool Block Create Failed Resend NPAC SMS Updates]

1.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus back to ‘failed’, updating the numberPoolBlockFailed-SP-List with the failed service providers who failed the subscription version and number pool block download and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus back to ‘failed’, updating the subscriptionFailed-SP-List with the failed service providers who failed either the number pool block or subscription version create and setting the subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘failed’ and the numberPoolBlockFailed-SP-List.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		82

Appendix B: Message Flow Diagrams

B.3.4.11 Number Pool Block Create Partial-Failure Resend NPAC SMS Updates (previously NNP flow 2.9)

In this scenario, the NPAC SMS has unsuccessfully re-sent the creation of a number pool block and corresponding subscription versions and the status is now partial-failure for the objects. The NPAC SMS now updates the state of the objects on the NPAC SMS.

[Graphic Omitted: Number Pool Block Create Partial-Failure Resend NPAC SMS Updates]

1.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘partial-failure’, updating the numberPoolBlockFailed-SP-List with the failed service providers who failed the number pool block or subscription version create and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS updates each of the subscriptionVersionNPAC that was broadcasted by setting the subscriptionVersionStatus to ‘partial-failure’ or ‘active’, updating the subscriptionFailed-SP-List with the failed service providers who failed the number pool block or subscription version create and setting the subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘partial-failure’ and the failed service provider list.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		83

Appendix B: Message Flow Diagrams

B.3.4.12 Number Pool Block Modify by NPAC SMS (previously NNP flow 2.10)

This scenario shows the modification of a number pool block object by NPAC Personnel at the request of the block holder service provider.

[Graphic Omitted: Number Pool Block Modify by NPAC SMS]

Action is taken by NPAC personnel to modify the data on a number pool block.

1. NPAC SMS issues the M-SET to modify attribute data on a single numberPoolBlock. The following attributes can be modified:

numberPoolBlockLRN
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN
numberPoolBlockSOA-Origination

If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile, the following attributes may be updated:

numberPoolBlockWSMSC-DPC

numberPoolBlockWSMSC-SSN

If the indicator is not set, the request will be rejected..

If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:

numberPoolBlockSVType

If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:

alternativeSPID

	In addition, the numberPoolBlockStatus gets set to ‘sending’ and the numberPoolBlockBroadcastTimeStamp and numberPoolBlockModifiedTimeStamp get set to the current date and time.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to modify the attribute data on the corresponding subscriptionVersionNPAC object(s). Only the following attributes can be modified:

subscriptionLRN

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		84

Appendix B: Message Flow Diagrams

subscriptionCLASS-DPC
subscriptionCLASS-SSN
subscriptionCNAM-DPC
subscriptionCNAM-SSN
subscriptionISVM-DPC
subscriptionISVM-SSN
subscriptionLIDB-DPC
subscriptionLIDB-SSN
subscriptionWSMSC-DPC
subscriptionWSMSC-SSN
subscriptionSOA-Origination
subscriptionSVType
subscriptionAlternativeSPID

	In addition, the NPAC SMS sets the subscriptionVersionStatus to ‘sending’ and the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp get set to the current date and time.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, attribute value change, to the block holder SOA. The attribute value change would include any of the following attributes that were updated:

numberPoolBlockLRN
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN
numberPoolBlockSOA-Origination

The following attributes will be sent if they are updated and the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile:

numberPoolBlockWSMSC-DPC
numberPoolBlockWSMSC-SSN

The following attributes will be sent if they are updated and the “SOA Supports SV Type Indicator” is set in the service provider’s profile:

numberPoolBlockSVType

The following attributes will be sent if they are updated and the “SOA Supports Alternative SPID” is set in the service provider’s profile:

numberPoolBlockAlternativeSPID

6. Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		85

Appendix B: Message Flow Diagrams

B.3.4.13 Number Pool Block Modify by Block Holder SOA (previously NNP flow 2.11)

This scenario shows the modification of a number pool block object by the block holder SOA Personnel.

[Graphic Omitted: Number Pool Block Modify by Block Holder SOA]

1. Block holder SOA issues the M-SET by either directing the request to a specific number pool block or issuing a scope and filtered request specifying the numberPoolBlockNPA-NXX-X and numberPoolBlockStatus to modify attribute data on the numberPoolBlock. The following attributes can be modified:

numberPoolBlockLRN
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN

If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile, the following attributes may be updated:

numberPoolBlockWSMSC-DPC
numberPoolBlockWSMSC-SSN

If the indicator is not set, the request will be rejected..

If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:

numberPoolBlockSVType

If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:

alternativeSPID

     In addition, the numberPoolBlockStatus gets set to ‘sending’ and the numberPoolBlockBroadcastTimeStamp gets set.

2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to modify the attribute data on the corresponding subscriptionVersionNPAC object(s). Only the following attributes can be modified:

subscriptionLRN
subscriptionCLASS-DPC
subscriptionCLASS-SSN
subscriptionCNAM-DPC
subscriptionCNAM-SSN

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		86

Appendix B: Message Flow Diagrams

subscriptionISVM-DPC
subscriptionISVM-SSN
subscriptionLIDB-DPC
subscriptionLIDB-SSN
subscriptionWSMSC-DPC
subscriptionWSMSC-SSN
subscriptionSVType
subscriptionAlternativeSPID

	In addition, the NPAC SMS sets the subscriptionVersionStatus to ‘sending’.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, attribute value change, to the block holder SOA. The attribute value change would include any of the following attributes that were updated:

numberPoolBlockLRN
numberPoolBlockCLASS-DPC
numberPoolBlockCLASS-SSN
numberPoolBlockCNAM-DPC
numberPoolBlockCNAM-SSN
numberPoolBlockISVM-DPC
numberPoolBlockISVM-SSN
numberPoolBlockLIDB-DPC
numberPoolBlockLIDB-SSN

If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes will be sent if they were updated:

numberPoolBlockWSMSC-DPC
numberPoolBlockWSMSC-SSN

The following attributes will be sent if they are updated and the “SOA Supports SV Type Indicator” is set in the service provider’s profile:

numberPoolBlockSVType

The following attributes will be sent if they are updated and the “SOA Supports Alternative SPID” is set in the service provider’s profile:

numberPoolBlockAlternativeSPID

6. Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		87

Appendix B: Message Flow Diagrams

B.3.4.14 Number Pool Block Modify Successful Broadcast to Local SMS Success (previously NNP flow 2.12.1)

In this scenario, the NPAC SMS has made a modification to a number pool block object and is about to broadcast the data to the Local SMS.

[Graphic Omitted: Number Pool Block Modify Successful Broadcast to Local SMS Success]

The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.

1. NPAC SMS sends the M-SET for the updated attributes on the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX.

2.	At the same time, the NPAC SMS sends the M-SET for the updated attributes on the number pool block object to the EDR Local SMS.
3.	Non-EDR Local SMS responds to the M-SET.
4.	EDR Local SMS responds to the M-SET.

As soon as 1 successful response is received to either M-SET, the status of the subscriptionVersionNPAC and numberPoolBlockNPAC object goes to ‘active’.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		88

Appendix B: Message Flow Diagrams

B.3.4.15 Number Pool Block Modify Successful Broadcast NPAC SMS Updates (previously NNP flow 2.12.2)

In this scenario, the NPAC SMS has received successful M-SET responses from all the Local SMS for the numberPoolBlock and corresponding subscriptionVersions.

[Graphic Omitted: Number Pool Block Modify Successful Broadcast NPAC SMS Updates]

As soon as the first successful response is received, the NPAC SMS sets the status of the subscriptionVersionNPAC objects and numberPoolBlockNPAC object to ‘active’. The numberPoolBlockStatusAttributeValueChange, however, is not sent out until all replies have been received or the retries have been exhausted.

1.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to active.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		89

Appendix B: Message Flow Diagrams

B.3.4.16 Number Pool Block Modify Broadcast to Local SMS Failure (previously NNP flow 2.13)

NPAC SMS has a numberPoolBlock and corresponding subscriptionVersion in ‘sending’ state for modifications. In this scenario, no Local SMSs will respond successfully to the M-SET requests.

[Graphic Omitted: Number Pool Block Modify Broadcast to Local SMS Failure]

1. NPAC SMS sends the M-SET with the modifications for the subscriptionVersion to the non-EDR Local SMS.

2. At the same time as step 1, NPAC SMS sends the M-SET with the modifications for the numberPoolBlock to the EDR Local SMS.

NPAC SMS waits for a response from all Local SMSs.

NPAC SMS retries any Local SMS that has not responded.

No response or an error is received from all the Local SMSs (EDR and non-EDR).

3.	NPAC SMS returns the subscriptionVersionStatus to ‘active’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.

5.	NPAC SMS returns the numberPoolBlockStatus to ‘active’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers. The numberPoolBlockModifiedTimeStamp also gets set.
6.	NPAC SMS responds to the M-SET.

7.	If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the block holder SOA the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, with the numberPoolBlockStatus set to active and the numberPoolBlockFailed-SP-List.
8.	SOA confirms M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		90

Appendix B: Message Flow Diagrams

B.3.4.17 Number Pool Block Modify Partial Failure Broadcast to Local SMS (previously NNP flow 2.14.1)

In this scenario, the NPAC SMS has a numberPoolBlock and corresponding subscriptionVersion object(s) in a state of ‘sending’ for a modification to the Local SMS. The broadcast, however, will result in a partial-failure state for both the numberPoolBlock and corresponding subscriptionVersions.

[Graphic Omitted: Number Pool Block Modify Partial Failure Broadcast to Local SMS]

The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.

1. NPAC SMS sends the M-SET for the updated attributes on the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX.

2.	At the same time as step 1, NPAC SMS sends the M-SET for the updated attributes on the number pool block object to the EDR Local SMS who are accepting downloads for the NPA-NXX.
3.	Non-EDR Local SMS responds successfully to the M-SET.
4.	EDR Local SMS responds successfully to the M-SET.

NPAC SMS waits for a response from all Local SMSs.

NPAC SMS retries any Local SMS that has not responded.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		91

Appendix B: Message Flow Diagrams

B.3.4.18 Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.14.2)

The NPAC SMS has attempted to broadcast the number pool block modification to the Local SMSs. However, at least 1, but not all Local SMSs have responded successfully to the M-SETs.

[Graphic Omitted: Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates]

Once the first successful M-SET response is received, the NPAC SMS sets the status to ‘active’ for the numberPoolBlock and subscriptionVersion objects. Once all retries are exhausted, the NPAC SMS sets the numberPoolBlockFailed-SP-List and sends the status attribute value change.

The numberPoolBlockSP-List on the number pool block object contains all the service providers who failed to receive either the number pool block or any of the subscription versions. The subscriptionFailed-SP-List on the subscription version object contains only those service providers who failed to receive that subscription version or the number pool block object.

1.	NPAC SMS updates the subscriptionVersionNPACs with a LNP type set to ‘pool’ that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and updating the subscriptionFailed-SP-List to the list of failed service providers. The subscriptionModifiedTimeStamp is set to the current date and time.
2.	NPAC SMS responds to the M-SET.

3.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockFailed-SP-List to the list of currently failed service providers. It also sets the numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.

5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’ and the numberPoolBlockFailed-SP-List.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		92

Appendix B: Message Flow Diagrams

B.3.4.19 Number Pool Block Modify Resend Broadcast (previously NNP flow 2.15)

In this scenario, the NPAC SMS must resend a previously failed modification to a number pool block and corresponding subscription versions of type ‘pool’.

[Graphic Omitted: Number Pool Block Modify Resend Broadcast]

Action is taken by the NPAC SMS personnel to resend a previously failed modification of a number pool block and corresponding subscription versions with a LNP type of ‘pool’.

1.	NPAC SMS issues the M-SET to modify the numberPoolBlockStatus to ‘sending’ on the number pool block object. The numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp also get set.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to modify the subscriptionVersionStatus to ‘sending’ on the subscription version object. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp also get set.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues the M-SET for the subscription versions to the non-EDR Local SMS if it had previously failed the modify request and if it is accepting downloads for the NPA-NXX.
6.	At the same time as step 5, the NPAC SMS sends the M-SET for the numberPoolBlock to the EDR Local SMS if it had previously failed the modify request and if it is accepting downloads for the NPA-NXX.
7.	The non-EDR Local SMS sends to the NPAC SMS the results of the M-SET. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-SET request a tunable amount of times.
8.	The EDR Local SMS sends to the NPAC SMS the results of the M-SET. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-SET request a tunable amount of times.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		93

Appendix B: Message Flow Diagrams

B.3.4.20 Number Pool Block Modify Successful Resend Updates (previously NNP flow 2.16)

In this scenario, the NPAC SMS has received all successful responses to the modify request for a number pool block and corresponding subscription version with LNP type equal to ‘pool’.

[Graphic Omitted: Number Pool Block Modify Successful Resend Updates]

1.	NPAC SMS updates the numberPoolBlockNPAC by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		94

Appendix B: Message Flow Diagrams

B.3.4.21 Number Pool Block Modify Failure Resend Updates (previously NNP flow 2.17)

In this scenario, the NPAC SMS has not received all successful responses to the modify request for a number pool block and corresponding subscription version with LNP type equal to ‘pool’.

[Graphic Omitted: Number Pool Block Modify Failure Resend Updates]

1.	NPAC SMS updates the numberPoolBlockNPAC by setting the numberPoolBlockStatus back to ‘active’, updating the numberPoolBlockFailed-SP-List with the failed service providers who failed the subscription version and number pool block download and setting the numberPoolBlockModifiedTimeStamp to the current date and time.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS updates each of the subscriptionVersionNPAC that was broadcasted by setting the subscriptionVersionStatus back to ‘active’, updating the subscriptionVersionFailed-SP-List with the failed service providers who failed either the number pool block or subscription version create and setting the subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’ and the numberPoolBlockFailed-SP-List with any of the failed service providers who failed the subscription version and/or number pool block download.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		95

Appendix B: Message Flow Diagrams

B.3.4.22 Number Pool Block Modification of SOA-Origination Indicator (previously NNP flow 2.18)

A block holder service provider has asked the NPAC SMS to change the value of the numberPoolBlockSOA-Origination indicator on a number pool block.

[Graphic Omitted: Number Pool Block Modification of SOA-Origination Indicator]

Action is taken by NPAC SMS personnel to modify a number pool block object.

1.	NPAC SMS locally M-SETs the number pool block object changing the value of the numberPoolBlockSOA-Origination indicator.
2.	NPAC SMS successfully responds to the M-SET.
3.	The NPAC SMS issues the M-EVENT-REPORT attribute value change to the block holder SOA for the number pool block that contains the numberPoolBlockSOA-Origination indicator, only when the numberPoolBlockSOA-Origination indicator is modified from FALSE to TRUE.
4.	The block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		96

Appendix B: Message Flow Diagrams

B.3.4.23 Number Pool Block De-Pool by NPAC SMS (previously NNP flow 2.19)

This scenario reflects the events that occur when a block is “de-pooled” after the serviceProvNPA-NXX-X object has become effective and active. Only NPAC Personnel are allowed to remove a number pool block object at the request of the number pool block administrator.

The removal of the serviceProvNPA-NXX-X object is a cascading request. First, all subscription versions with the LNP type equal to ‘pool’ must be removed from the non-EDR Local SMSs and the number pool block must be removed from all the EDR Local SMSs.

[Graphic Omitted: Number Pool Block De-Pool by NPAC SMS]

Action is taken by NPAC personnel to ‘de-pool’ a block of TNs.

1.	NPAC SMS issues the M-SET to update the numberPoolBlockStatus to ‘sending’ and the numberPoolBlockBroadcastTimeStamp gets set.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to update the corresponding subscriptionVersions within the block range with LNP type equal to ‘pool’ to a status of ‘sending’ and the subscriptionModifiedTimeStamp gets set.
4.	NPAC SMS responds to the M-SET.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		97

Appendix B: Message Flow Diagrams

B.3.4.24 Number Pool Block De-Pool Successful Broadcast of Subscription Version and Number Pool Block Deletes (previously NNP flow 2.20.1)

In this scenario, the NPAC personnel have initiated the “de-pool” of a block of TNs. The NPAC SMS already has the numberPoolBlock and corresponding subscriptionVersions in the “sending” state.

In this scenario, the NPAC SMS will send all the M-DELETE requests for the number pool block and subscription versions to the Local SMSs and get successful replies to all the requests.

[Graphic Omitted: Number Pool Block De-Pool Successful Broadcast of Subscription Version and Number Pool Block Deletes]

The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.

1.	NPAC SMS sends the M-DELETE for the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX. The subscription version TNs are within the block range and have the LNP type set to ‘pool’.
2.	At the same time, NPAC SMS sends the M-DELETE for the number pool block object to the EDR Local SMS.
3.	Non-EDR Local SMS respond successfully to the M-DELETE.
4.	EDR Local SMS respond successfully to the M-DELETE.

NPAC SMS waits for all the successful responses and retries as necessary.

NPAC SMS receives all successful responses.

5.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘old’ and setting the subscriptionModifiedTimeStamp to the current date and time. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
6.	NPAC SMS responds to the M-SET.
7.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘old’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time. The numberPoolBlockDisconnectCompleteTimeStamp is set when the first successful response is received.
8.	NPAC SMS responds to the M-SET.
9.	NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the donor service provider SOA that the subscription version is being disconnected with the customer disconnect date.
10.	The donor service provider SOA confirms the M-EVENT-REPORT.
11.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT for the numberPoolBlockStatusAttributeValueChange to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to ‘old’.
12.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		98

Appendix B: Message Flow Diagrams

B.3.4.25 Number Pool Block De-Pool Broadcast Successful NPA-NXX-X Updates (previously NNP flow 2.20.2)

NPAC SMS has received successful responses to all numberPoolBlock and subscriptionVersion M-DELETE requests. The NPAC SMS now proceeds to delete the service provider NPA-NXX-X object.

[Graphic Omitted: Number Pool Block De-Pool Broadcast Successful NPA-NXX-X Updates]

1.	NPAC SMS issues the M-DELETE to remove the serviceProvNPA-NXX-X object locally.
2.	NPAC SMS responds successfully to the M-DELETE request for the serviceProvNPA-NXX-X object.
3.	The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the non-EDR Local SMS who are supporting the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.
4.	The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the EDR Local SMS who are supporting the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.
5.	At the same time as step 4, the NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the SOAs who are supporting the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.
6.	Non-EDR Local SMS respond successfully to the M-DELETE.
7.	EDR Local SMS respond successfully to the M-DELETE.
8.	SOA respond successfully to the M-DELETE.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		99

Appendix B: Message Flow Diagrams

B.3.4.26 Number Pool Block De-Pool Broadcast to Local SMS Failure (previously NNP flow 2.21)

This scenario shows the failure of a broadcast for a de-pool of a number pool block. The M-DELETE has been issued on the serviceProvNPA-NXX-X object and now the NPAC SMS is attempting to broadcast the all the M-DELETEs associated with the block removal.

[Graphic Omitted: Number Pool Block De-Pool Broadcast to Local SMS Failure]

1.	NPAC SMS sends the M-DELETE for the subscriptionVersion to the non-EDR Local SMS.
2.	At the same time as step 1, NPAC SMS sends the M-DELETE for the numberPoolBlock to the EDR Local SMS.

NPAC SMS waits for a response from all Local SMSs.

NPAC SMS retries the Local SMSs that have not responded.

No response or an error is received from all the Local SMSs (EDR and non-EDR).

3.	NPAC SMS sets the subscriptionVersionStatus to ‘active’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS sets the numberPoolBlockStatus to ‘active’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers. The numberPoolBlockModifiedTimeStamp also gets set.
6.	NPAC SMS responds to the M-SET.
7.	If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the originating SOA the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange with the numberPoolBlockStatus set back to ‘active’ and numberPoolBlockFailed-SP-List.
8.	SOA confirms M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		100

Appendix B: Message Flow Diagrams

B.3.4.27 Number Pool Block De-Pool Partial Failure Broadcast to Local SMS of Subscription Versions and Number Pool Block (previously NNP flow 2.22.1)

This scenario shows the processing of a partial-failure for the de-pool of a number pool block. The M-DELETE has been issued on the serviceProvNPA-NXX-X object on the NPAC SMS and now the NPAC SMS is attempting to broadcast all the M-DELETEs associated with the block removal to the Local SMSs.

[Graphic Omitted: Number Pool Block De-Pool Partial Failure Broadcast to Local SMS of Subscription Versions and Number Pool Block]

The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.

1.	NPAC SMS sends the M-DELETE for the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX.
2.	NPAC SMS sends the M-DELETE for the number pool block object to the EDR Local SMS.
3.	Non-EDR Local SMS responds to the M-DELETE for the subscriptionVersion.
4.	EDR Local SMS responds to the M-DELETE for the numberPoolBlock.

NPAC SMS waits for a response from all Local SMSs.

NPAC SMS retries any Local SMS that has not responded.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		101

Appendix B: Message Flow Diagrams

B.3.4.28 Number Pool Block De-Pool Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.22.2)

The NPAC SMS broadcast of a block deletion partially failed. The NPAC SMS now updates the states of the objects on the NPAC SMS.

[Graphic Omitted: Number Pool Block De-Pool Broadcast Partial Failure NPAC SMS Updates]

No response or an error is received from at least one Local SMS.

1.	NPAC SMS updates each of the subscriptionVersionNPACs that was broadcasted by setting the subscriptionVersionStatus to ‘old’ and updating the subscriptionFailed-SP-List to the list of failed service providers. The subscriptionModifiedTimeStamp is set to the current date and time. The subscriptionDisconnectCompleteTimeStamp would be set with the first successful response.
	The subscriptionFailed-SP-List will reflect the list of the EDR service providers that failed on the number pool block broadcast and any non-EDR service provider that failed to receive any subscription version.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘old’ and setting the numberPoolBlockFailed-SP-List to the list of currently failed service providers. It also sets the numberPoolBlockModifiedTimeStamp to the current date and time. The numberPoolBlockDisconnectCompleteTimeStamp would be set with the first successful response.
	The numberPoolBlockFailed-SP-List will reflect the list of the EDR service providers that failed on the number pool block broadcast and any non-EDR service provider that failed to receive any subscription versions.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT for the subscription version status attribute value change to the block holder SOA. The numberPoolBlockStatusAttributeValueChange would contain the numberPoolBlockStatus set to ‘old’ and the numberPoolBlockFailed-SP-List.
6.	Block holder SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		102

Appendix B: Message Flow Diagrams

B.3.4.29 Number Pool Block De-Pool Resend Broadcast (previously NNP flow 2.23)

In this scenario, the NPAC SMS resends the broadcast of a de-pool of a block because the first attempt did not complete successfully.

[Graphic Omitted: Number Pool Block De-Pool Resend Broadcast]

Action is taken by the NPAC SMS personnel to resend a previously failed de-pool of block data.

1.	NPAC SMS issues the M-SET to modify the numberPoolBlockStatus to ‘sending’ of the number pool block object. The numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp also get set.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to modify the subscriptionVersionStatus to ‘sending’ of the subscription version object. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp also get set.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues the M-DELETE for the subscription versions to the non-EDR Local SMS if it is accepting downloads for the NPA-NXX and had previously failed the delete request.
6.	At the same time as step 5, the NPAC SMS sends the M-DELETE for the numberPoolBlock to the EDR Local SMS if it is accepting downloads for the NPA-NXX and had previously failed the delete request.
7.	The non-EDR Local SMS sends to the NPAC SMS the results of the M-DELETE. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-DELETE request a tunable amount of times.
8.	The EDR Local SMS sends to the NPAC SMS the results of the M-DELETE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-DELETE request a tunable amount of times.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		103

Appendix B: Message Flow Diagrams

B.3.4.30 Number Pool Block De-Pool Successful Resend Updates (previously NNP flow 2.24)

In this scenario, the NPAC SMS successfully rebroadcast the number pool block and subscription version deletes to the Local SMS. It now proceeds to update the status of the number pool block and corresponding subscription versions and then sends the NPA-NXX-X delete to the Local SMSs.

[Graphic Omitted: Number Pool Block De-Pool Successful Resend Updates]

1.	NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘old’ and setting the subscriptionModifiedTimeStamp to the current date and time. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘old’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time. The numberPoolBlockDisconnectCompleteTimeStamp is set when the first successful response is received.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT for the numberPoolBlockStatusAttributeValueChange to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to ‘old’.
6.	Block holder SOA confirms the M-EVENT-REPORT.
7.	NPAC SMS issues the M-DELETE to remove the serviceProvNPA-NXX-X object locally.
8.	NPAC SMS responds successfully to the M-DELETE request for the serviceProvNPA-NXX-X object.
9.	The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the non-EDR Local SMS that support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.
10.	The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the EDR Local SMS that support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.
11.	At the same time as step 10, the NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the SOA that support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.
12.	Non-EDR Local SMS respond successfully to the M-DELETE.
13.	EDR Local SMS respond successfully to the M-DELETE.
14.	SOA respond successfully to the M-DELETE.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		104

Appendix B: Message Flow Diagrams

B.3.4.31 Number Pool Block De-Pool Resend Failure Updates (previously NNP flow 2.25)

In this scenario, the NPAC SMS was not successful in the resend of a previously failed de-pool attempt and proceeds to update the status of the number pool block and corresponding subscription versions.

[Graphic Omitted: Number Pool Block De-Pool Resend Failure Updates]

1.	NPAC SMS sets the subscriptionVersionStatus to ‘active’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp on the subscription version objects.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS sets the numberPoolBlockStatus to ‘active’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers on the number pool block object. The numberPoolBlockModifiedTimeStamp also gets set.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the originating SOA the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange with the numberPoolBlockStatus set back to ‘active’ and numberPoolBlockFailed-SP-List.
6.	SOA confirms M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		105

Appendix B: Message Flow Diagrams

B.3.4.32 Number Pool Block De-Pool Resend Partial Failure Updates (previously NNP flow 2.26)

In this scenario, the NPAC SMS has attempted to resend a failed de-pool attempt and has resulted in partial-failure. The NPAC SMS proceeds to update the status of the objects locally.

[Graphic Omitted: Number Pool Block De-Pool Resend Partial Failure Updates]

1.	NPAC SMS sets the subscriptionVersionStatus to ‘old’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp to the current date and time on the subscription version objects. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS sets the numberPoolBlockStatus to ‘old’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers on the number pool block object. The numberPoolBlockModifiedTimeStamp also get set. The numberPoolBlockDisconnectCompleteTimeStamp is set when the first successful response is received.
4.	NPAC SMS responds to the M-SET.
5.	If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the originating SOA the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange with the numberPoolBlockStatus set to ‘old’ and numberPoolBlockFailed-SP-List.
6.	SOA confirms M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		106

Appendix B: Message Flow Diagrams

B.3.4.33 Number Pool Block Query by SOA or LSMS (previously NNP flow 2.27)

In this scenario, the service provider personnel queries for one or more number pool block objects from the SOA or Local SMS.

[Graphic Omitted: Number Pool Block Query by SOA or LSMS]

Action is taken by service provider personnel to query one or more numberPoolBlock objects for all attributes.

1.	SOA or Local SMS sends the M-GET request for either requesting a single numberPoolBlock object by numberPoolBlockId or requesting one or more numberPoolBlock objects using a scope and filtered request.
2.	If the requested object(s) exist, the NPAC SMS will respond with a single or linked M-GET reply. If no objects are found, the NPAC SMS will respond with an empty result. All attributes are returned in the query.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		107

Appendix B: Message Flow Diagrams

B.4 SubscriptionVersion Flow Scenarios

Note: All actions for subscription versions in the flows that follow are atomic. If the operation fails for one TN in a range it fails for all TNs in the range.

Any creation or update of a subscription version causes the subscriptionModifiedTimeStamp to be updated. Therefore the explicit setting of that attribute is not reflected in the subscription version flows.

B.4.1 SubscriptionVersion Create Scenarios

The subscriptionVersionNPAC object is created by either the new or old service provider SOA issuing their M-ACTION to create the subscription version. If the new service provider SOA issues its subscriptionVersionNewSP-Create action first, the old service provider SOA has the option of sending in the subscriptionVersionOldSP-Create action or not. If they do send in the subscriptionVersionOldSP-Create, the old service provider explicitly states their concurrence or non-concurrence to the port by the value set within the subscriptionOldSP-Authorization field. If the old service provider does not send in their create request within the concurrence window, this implies concurrence to the port. However, the old service provider can send in their create request after the concurrence window before activation of the subscription version and the NPAC SMS will accept the data if valid.

If the old service provider SOA issues its subscriptionVersionOldSP-Create action first, then the new service provider SOA must issue its subscriptionVersionNewSP-Create action.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		108

Appendix B: Message Flow Diagrams

B.4.1.1 Subscription Version 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 subscriptionVersionobject.

[Graphic Omitted: Subscription Version Create by the Initial SOA]

Action is taken by the old service provider SOA to create a new version of a subscriber.

1. 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 (seconds set to zeros)
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.
2.	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.
3.	NPAC SMS responds to M-CREATE.
4.	NPAC SMS sends action reply with success or failure and reasons for failure.
5.	If the M-ACTION was successful, the NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M-EVENT-REPORT containing the following attributes to old service provider SOA of subscriptionVersionNPAC creation:

subscriptionVersionID
subscriptionTN
subscriptionOldSP
subscriptionNewCurrentSP
subscriptionOldSp-DueDate
subscriptionOldSP-Authorization
subscriptionOldSP-AuthorizationTimeStamp
subscriptionStatusChangeCauseCode — (if subscriptionOldSP-Authorization set to false)

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		109

Appendix B: Message Flow Diagrams

subscriptionVersionStatus
subscriptionVersionConflictTimeStamp — (if subscriptionOldSP-Authorization set to false)

	If the notification is a subscriptionVersionRangeObjectCreation then the TN and SVID are the TN and SVID of the first TN in the range or list.
6.	Old service provider SOA responds by sending an M-EVENT-REPORT confirmation back to the NPAC SMS.
7.	If the M-ACTION was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M- EVENT-REPORT to new service provider SOA of subscriptionVersionNPAC creation.
8.	New service provider SOA issues an M-EVENT-REPORT confirmation to NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		110

Appendix B: Message Flow Diagrams

B.4.1.1.1 Subscription Version Create by the Initial SOA (Old Service Provider) (continued)

[Graphic Omitted: Subscription Version Create by the Initial SOA]

	NPAC SMS decides if this subscription version is the first use of the NPA-NXX.
1.	If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the accepting Local SMSs.
2.	The Local SMS confirms the M-EVENT-REPORT.
3.	The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the Old SOA.
4.	The Old SOA confirms the M-EVENT-REPORT.
5.	The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the New SOA.
6.	The New SOA confirms the M-EVENT-REPORT.

The next scenario would be “SubscriptionVersion Create by the Second SOA (New Service Provider).”

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		111

Appendix B: Message Flow Diagrams

B.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: SubscriptionVersion Create by the Initial SOA]

Action is taken by the new service provider SOA to create a new subscription version.

1. 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 (seconds set to zero)
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
subscriptionWSMSC-DPC — if supported by the Service Provider SOA
subscriptionWSMSC-SSN — if supported by the Service Provider SOA
subscriptionSVType – if supported by the Service Provider SOA

The following attributes are optional:

subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscriptionAlternativeSPID – if supported by the Service Provider SOA

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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		112

Appendix B: Message Flow Diagrams

	If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. Other appropriate errors will also be returned.
	If the subscriptionPortingToOriginal-SP is true, the new Service Provider ID MUST be the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block); if the SPIDs do not match the NPAC SMS will reject the request.
2.	If the request is valid, the NPAC SMS will create the subscriptionVersionNPAC object. The status will be set to “pending” and the subscriptionModifiedTimeStamp and subscriptionCreationTimeStamp will be set.
3.	NPAC SMS responds to M-CREATE.
4.	NPAC SMS sends action reply with success or failure and reasons for failure.
5.	If the M-ACTION was successful, NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M-EVENT-REPORT containing the following attributes to old service provider SOA of subscriptionVersionNPAC creation:

subscriptionVersionID
subscriptionTN
subscriptionOldSP
subscriptionNewCurrentSP
subscriptionNewSP-CreationTimeStamp
subscriptionVersionStatus
subscriptionNewSP-DueDate

	If the notification is a subscriptionVersionRangeObjectCreation then the TN and SVID are the TN and SVID of the first TN in the range or list.
6.	Old service provider SOA responds by sending an M-EVENT-REPORT confirmation back to the NPAC SMS.
7.	If the M-ACTION was successful, NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M-EVENT-REPORT to new service provider SOA of subscriptionVersionNPAC creation.
8.	New service provider SOA issues an M-EVENT-REPORT confirmation to NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		113

Appendix B: Message Flow Diagrams

B.4.1.2.1 Subscription Version Create by the Initial SOA (New Service Provider) (continued)

[Graphic Omitted: Subscription Version Create by the Initial SOA]

	NPAC SMS decides if this subscription version is the first use of the NPA-NXX.
1.	If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the accepting Local SMSs.
2.	The Local SMS confirms the M-EVENT-REPORT.
3.	The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the Old SOA.
4.	The Old SOA confirms the M-EVENT-REPORT.
5.	The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the New SOA.
6.	The New SOA confirms the M-EVENT-REPORT.

The next scenario is either “SubscriptionVersion Create by the Second SOA (Old Service Provider).” or “SubscriptionVersion Activated by New Service Provider SOA”.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		114

Appendix B: Message Flow Diagrams

B.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: SubscriptionVersion Create by Second SOA]

New service provider SOA personnel take action to create a new subscription version.

1. 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 (seconds set to zeros)
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
subscriptionWSMSC-DPC — if supported by the Service Provider SOA
subscriptionWSMSC-SSN — if supported by the Service Provider SOA
subscriptionSVType – if supported by the Service Provider SOA

The following attributes are optional:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

subscriptionAlternativeSPID – if supported by the Service Provider SOA

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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		115

Appendix B: Message Flow Diagrams

	If the subscriptionPortingToOriginal-SP is true, the new Service Provider ID MUST be the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block); if the SPIDs do not match the NPAC SMS will reject the request.
	If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. Other appropriate errors will be returned.
	If the due date for the port is a previous date, the NPAC SMS accepts a value of a previous date from a service provider, in order to match the due date of the port that was previously received from the Old Service Provider.
2.	If successful, the NPAC SMS sets the subscriptionModifiedTimeStamp, subscriptionCreationTimeStamp, and all data specified in the M-ACTION.
3.	NPAC SMS responds to M-SET.
4.	NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.
5.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT with the following attributes to the old service provider when the subscriptionNewSP-DueDate changes value.

subscriptionNewSP-DueDate
subscriptionNewSP-CreationTimeStamp

6.	Old service provider SOA issues M-EVENT-REPORT confirmation.
7.	If the M-ACTION was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the new service provider for all attributes updated from the preceding list of modifiable attributes in addition to the following:

subscriptionNewSP-DueDate
subscriptionNewSP-CreationTimeStamp

8. New service provider SOA issues M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		116

Appendix B: Message Flow Diagrams

B.4.1.4 SubscriptionVersion Create by Second SOA (Old Service Provider) with Authorization to Port

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 authorizing the port.

Note: This is an optional step.

[Graphic Omitted: SubscriptionVersion Create by Second SOA]

Old service provider SOA personnel take action to create a old subscription version.

1. 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
subscriptionNewCurrentSP
subscriptionOldSP
subscriptionOldSP-Authorization
subscriptionOldSP-DueDate (seconds set to zeros)
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.
	If the due date for the port is a previous date, the NPAC SMS accepts a value of a previous date from a service provider, in order to match the due date of the port that was previously received from the New Service Provider.
2.	If the data is valid, the NPAC SMS sets the subscriptionOldSP-AuthorizationTimeStamp, subscriptionModifiedTimeStamp and all data specified in the M-ACTION.
3.	NPAC SMS responds to M-SET.
4.	NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.
5.	If the M-ACTION was successful, the NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT attribute value change to the old service provider for all attributes updated from the following list:

subscriptionOldSP-DueDate
subscriptionOldSP-Authorization
subscriptionOldSP-AuthorizationTimeStamp

6. Old service provider SOA issues M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		117

Appendix B: Message Flow Diagrams

7. If the M-ACTION was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT attribute value change to the new service provider for all attributes updated from the preceding list. The following attributes are sent in the attributeValueChangeNotification:

subscriptionOldSP-DueDate
subscriptionOldSP-Authorization
subscriptionOldSP-AuthorizationTimeStamp

8. New service provider issues M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		118

Appendix B: Message Flow Diagrams

B.4.1.5 SubscriptionVersion Activated by New Service Provider SOA

In this scenario, either both service providers have sent their create data updates for a new subscription version to the NPAC SMS or the concurrence window has expired for receiving the subscriptionVersionOldSP-Create action. The new service provider can now activate the subscription version.

[Graphic Omitted: SubscriptionVersion Activated by New Service Provider SOA]

1. The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.

Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2. NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending,” subscriptionVersionActivationTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC object.

3.	NPAC SMS responds to the M-SET.
4.	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.
5.	NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending,” subscriptionBroadcastTimeStamp on the subscriptionVersionNPAC object.
6.	NPAC SMS responds to the M-SET.

For inter-Service Provider subscription versions that are not being ported to the original service provider’s switch, and ALL intra-Service Provider subscription versions, processing continues in the Flow B.5.1.6.1 — Active SubscriptionVersion Create on Local SMSs Using Create Action .

For inter-Service Provider ports to the original service provider’s switch, follow Flows B.5.1.12 – ‘Inter-Service Provider Subscription Version Port-to-Original: Successful’ and B.5.1.12.1 – ‘Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)’.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		119

Appendix B: Message Flow Diagrams

B.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: Active SubscriptionVersion Create on Local SMS]

NPAC SMS has a new subscriptionVersion with a status of “sending.”

1.	The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs, that is accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	Each Local SMS will reply to the M-CREATE.
	NPAC SMS waits for Local SMSs to respond successfully to the M-CREATE request.
3.	If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the old service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.
4.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the new service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.
6.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	If this TN has been previously ported (i.e., a previously active subscriptionVersionNPAC object exists), the NPAC SMS will issue, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notification to the old service provider SOA for the previously active subscriptionVersionNPAC object of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.
8.	The old service provider SOA for the previously active subscriptionVersionNPAC object returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		120

Appendix B: Message Flow Diagrams

B.4.1.6.1 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. This action is used to create a group of subscription versions with the same routing information.

[Graphic Omitted: Active Subscription Version Create on Local SMS Using Create Action]

NPAC SMS has one or more subscription versions with a status of “sending ” that have been activated by the new service provider.

1.	NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the Local SMS, if it is accepting downloads for the NPA-NXX of the subscriptionVersion. This action contains all data necessary to create the subscription version.
	The Local SMS verifies the action is valid, but does not attempt to create the subscription version(s).
2.	The Local SMS responds to the M-ACTION.
	The Local SMS proceeds to execute all the creates specified by the action.
3.	The Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the creates.
4.	NPAC SMS confirms the M-EVENT-REPORT.
	NPAC SMS waits for all responses a tunable amount of time. The default is 1 hour.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó1997 — 2006 NeuStar, Inc.		121

Appendix B: Message Flow Diagrams

B.4.1.6.2 SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window

This scenario shows no response within “Service Provider Concurrence Window” by the old service provider SOA.

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: SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window]

	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.
1.	NPAC SMS sends the old service provider, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionOldSP-ConcurrenceRequest or subscriptionVersionRangeOldSP-ConcurrenceRequestM-EVENT-REPORT .
2.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3Ó 1997 — 2006 NeuStar, Inc.		122

Appendix B: Message Flow Diagrams

B.4.1.6.3 SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window

This scenario shows no response within “Service Provider Final Concurrence Window” by the old service provider SOA.

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 as well as a subsciptionVersionOldSP-ConcurrenceRequest M-EVENT-REPORT to the old service provider SOA. No response has yet been received by the old service provider SOA.

[Graphic Omitted: SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window]

	NPAC SMS does not receive a response from the old service provider SOA within “Service Provider Final Concurrence Window” for the pending subscriptionVersionNPAC created by the new service provider SOA.
1.	NPAC SMS sends the old service provider, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionOldSPFinalConcurrenceWindowExpiration or subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration
	M-EVENT-REPORT.
2.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	If the old service provider SOA responds with a valid
	M-ACTION or M-SET prior to activation by the new service provider, the subscription version will be updated.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		123

Appendix B: Message Flow Diagrams

B.4.1.6.4 Subscription Version Create: Failure to Receive Response from New SOA

This scenario shows the process of the NPAC SMS after not receiving any concurrence from the new service provider after the “Final Service Provider Concurrence Window.”

The subscription version remains in the NPAC SMS with a status of pending.

[Graphic Omitted: Subscription Version Create: Failure to Receive Response from New SOA]

	NPAC SMS receives no concurrence from the new service provider SOA in “Service Provider Concurrence Window” for the pending subscriptionVersionNPAC created by the old service provider SOA.
1.	NPAC SMS notifies the old service provider, if they support the notification according to their NPAC Customer No New SP Concurrence Notification Indicator in their service provider profile on the NPAC SMS, of the expiration of the final create window where the new service provider did not send up a Create action for this subscription version, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionNewSP-FinalCreateWindowExpiration or subscriptionVersionRangeNewSP-FinalCreateWindowExpiration M-EVENT-REPORT.
2.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
3.	NPAC SMS notifies the new service provider, if they support the notification according to their NPAC Customer No New SP Concurrence Notification Indicator in their service provider profile on the NPAC SMS, of the expiration of the final create window where the new service provider did not send up a Create action for this subscription version, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionNewSP-FinalCreateWindowExpiration or subscriptionVersionRangeNewSP-FinalCreateWindowExpiration M-EVENT-REPORT.
4.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		124

Appendix B: Message Flow Diagrams

B.4.1.6.5 SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window

This scenario shows no response within “Service Provider Concurrence Window” by the new service provider SOA.

In this case, the oldservice 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 new service provider SOA.

[Graphic Omitted: SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window]

NPAC SMS does not receive a response from the new service provider SOA within “Service Provider Concurrence Window” for the pending subscriptionVersionNPAC created by the old service provider SOA.

1.	NPAC SMS sends the new service provider, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionNewSP-CreateRequest or subscriptionVersionRangeNewSP-CreateRequest M-EVENT-REPORT .
2.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

New service provider has up to “Service Provider Final Concurrence Window” to respond to the request.

If the new service provider SOA responds with a valid M-ACTION or M-SET, processing resumes as a successful create.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		125

Appendix B: Message Flow Diagrams

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		126

Appendix B: Message Flow Diagrams

B.4.1.7 SubscriptionVersionCreate M-CREATE Failure to Local SMS

This scenario shows a failure to all of the Local SMS on M-CREATE.

[Graphic Omitted: SubscriptionVersionCreate M-CREATE Failure to Local SMS]

	The new service provider SOA has activated the pending subscription.
1.	The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs, that is accepting downloads for the NPA-NXX of the subscriptionVersion.
	NPAC SMS waits for responses from each Local SMS.
	NPAC SMS resends to each Local SMS up to a tunable number of retries at a tunable interval.
	No responses occur from any Local SMS or all Local SMSs report a failure response to the M-CREATE.
2.	NPAC SMS issues M-SET to update the subscriptionVersionStatus to “failed” in the subscriptionVersionNPAC object, the subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.
3.	NPAC SMS issues M-SET response.
4.	If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change.
5.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
6.	If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change.
7.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		127

Appendix B: Message Flow Diagrams

B.4.1.8 SubscriptionVersion M-CREATE: Partial Failure to Local SMS

This scenario shows a partial failure to a Local SMS on an M-CREATE.

[Graphic Omitted: SubscriptionVersion M-CREATE: Partial Failure to Local SMS]

The new service provider SOA has activated the pending subscription.

1.	The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs, that is accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	One or more Local SMSs respond to the M-CREATE.
	NPAC SMS waits for responses from each Local SMS.
	NPAC SMS resends, to each unresponsive Local SMS, up to a tunable number of retries at a tunable interval.
	No responses occur from at least one Local SMS, or a Local SMS returns an M-CREATE failure.
3.	NPAC SMS issues M-SET to the subscriptionVersionStatus to “partial-failure” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.
4.	NPAC SMS issues M-SET response.
5.	If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.
6.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		128

Appendix B: Message Flow Diagrams

B.4.1.9 Create Subscription Version: Resend Successful to Local SMS Action

This scenario shows the successful resend of a subscription version create. The resend of a failed subscription version create can only be performed by authorized NPAC personnel.

[Graphic Omitted: Create Subscription Version: Resend Successful to Local SMS Action]

	NPAC personnel take action to resend a failed subscriptionVersion create.
1.	The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs that previously failed, and is accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	Each Local SMS will reply to the M-CREATE.
	NPAC SMS waits for all Local SMSs to report successful subscription version creation.
3.	NPAC SMS issues M-SET to update the subscriptionVersionStatus to “active” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.
4.	NPAC SMS issues M-SET response.
5.	If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the old service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.
6.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the new service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		129

Appendix B: Message Flow Diagrams

B.4.1.10 Subscription Version: Resend Failure to Local SMS

This scenario shows a failure on a resend of a Subscription Version M-CREATE a Local SMS. The resend of a failed version can only be performed by authorized NPAC SMS personnel.

[Graphic Omitted: Subscription Version: Resend Failure to Local SMS]

The NPAC personnel issues a resend for the failed or partially failed subscriptionVersion.

1.	The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs for which the M-CREATE previously failed, and is accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	One or more Local SMSs respond to the M-CREATE.
	NPAC SMS waits for responses from each Local SMS.
	NPAC SMS resends, to each unresponsive Local SMS, up to a tunable number of retries at a tunable interval.
	No responses occur from at least one or all Local SMSs, or one or all Local SMSs return an M-CREATE failure.
3.	NPAC SMS issues M-SET to the subscriptionVersionStatus to “partial-failure” or “failed” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.
4.	NPAC SMS issues M-SET response.
5.	If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.
6.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		130

Appendix B: Message Flow Diagrams

B.4.1.11 SubscriptionVersion Create for Intra-Service Provider Port

This scenario shows how an intra-service port is processed.

[Graphic Omitted: SubscriptionVersion Create for Intra-Service Provider Port]

Action is taken by the current provider SOA to create a new version of a subscriber.

1. 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 (seconds set to zeros)
subscriptionPortingToOriginal-SPSwitch

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
subscriptionLNPType
subscriptionWSMSC-DPC — if supported by the Service Provider SOA
subscriptionWSMSC-SSN — if supported by the Service Provider SOA
subscriptionSVType – if supported by the Service Provider SOA

If the subscriptionPortingToOriginal-SP is true, the subscriptionNewCurrentSP must be equal to the subscriptionOldSP. If the new Service Provider Id is NOT the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block) in a “Port to Original” subscription version request then the NPAC SMS will fail the request.

The following attributes are optional:

subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscriptionAlternativeSPID – if supported by the Service Provider SOA

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		131

Appendix B: Message Flow Diagrams

2.	If the request is valid, the NPAC SMS will M-CREATE the subscriptionVersionNPAC object. The status will be set to “pending.” Also the subscriptionNewSP-CreationTimeStamp, and the subscriptionModifiedTimeStamp will be set.
3.	NPAC SMS responds to M-CREATE.
4.	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.
5.	NPAC SMS notifies intra-service provider SOA of the subscriptionVersionNPAC creation by sending, depending upon the service provider’s TN Range Notification Indicator, either a object creation or subscriptionVersionRangeObjectCreation notification.
6.	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 and activation on the NPAC SMS and creation on the Local SMSs. (refer to flow B.5.1.5, Subscription Version Activated by New Service Provider SOA, for activation on the NPAC SMS and flow B.5.1.6, Active Subscription Version Create on Local SMS, for creation on the Local SMSs.
	The only difference is the M-EVENT-REPORT for the subscriptionVersionStatusAttributeValueChange is only sent to the new provider.

NOTE: If this Intra- Service Provider port request is a port-to-original request, follow flows B.5.1.12 and B.5.1.12.1 for successful activate.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		132

Appendix B: Message Flow Diagrams

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		133

Appendix B: Message Flow Diagrams

B.4.1.12 SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Successful

This scenario shows how port-to-original (successful) port is processed and applies to both Intra- and Inter- Service Provider port-to-original requests.

[Graphic Omitted: SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Successful]

	SV 1 is the currently active Subscription Version.
	SV 2 is the current pending Subscription Version.
1.	The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.

Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.
3.	NPAC SMS response to the M-SET.
4.	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.
5.	The NPAC SMS sets the subscriptionVersionStatus to sending and sets the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
6.	NPAC SMS response to the M-SET.
7.	NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.
8.	Each Local SMS responds with a successful M-DELETE reply.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		134

Appendix B: Message Flow Diagrams

B.4.1.12.1 Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)

[Graphic Omitted: Inter-Service Provider Subscription Version Port-to-Original: Successful]

	All Local SMSs respond successfully.
1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA of SV1,depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		135

Appendix B: Message Flow Diagrams

B.4.1.12.2 Intra-Service Provider Subscription Version Port-to-Original: Successful (continued)

[Graphic Omitted: Intra-Service Provider Subscription Version Port-to-Original: Successful]

	All Local SMSs respond successfully.
1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA of SV1,depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		136

Appendix B: Message Flow Diagrams

B.4.1.13 | SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: All LSMSs Fail

This scenario shows how a port-to-original (all fail) port is processed and applies to both Intra- and Inter- Service Provider port-to-original requests

[Graphic Omitted: SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: All LSMSs Fail]

	SV 1 is the currently active Subscription Version.
	SV 2 is the current pending Subscription Version.
1.	The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.

Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.
3.	NPAC SMS response to the M-SET.
4.	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.
5.	The NPAC SMS sets the subscriptionVersionStatus to sending and sets the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
6.	NPAC SMS response to the M-SET.
7.	NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.
	NPAC SMS waits for a response from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from all Local SMSs.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		137

Appendix B: Message Flow Diagrams

B.4.1.13.1 Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)

[Graphic Omitted: Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)]

All Local SMSs have either failed to respond or responded with an error to the M-DELETE request.

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to active.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to active on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to failed. It also sets the subscriptionFailed-SP-List.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2, along with the subscriptionFailed-SP-List.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2, along with the subscriptionFailed-SP-List.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.
	NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.
	NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		138

Appendix B: Message Flow Diagrams

B.4.1.13.2 Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)

[Graphic Omitted: Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)]

All Local SMSs have either failed to respond or responded with an error to the M-DELETE request.

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to active.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to active on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to failed. It also sets the subscriptionFailed-SP-List.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2, along with the subscriptionFailed-SP-List.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.
	NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.
	NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		139

Appendix B: Message Flow Diagrams

B.4.1.14 SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Partial Failure

This scenario shows how a port-to-original (partial fail) port is processed and applies to both Intra- and Inter- Service Provider port-to-original requests

[Graphic Omitted: SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Partial Failure]

	SV 1 is the currently active Subscription Version.
	SV 2 is the current pending Subscription Version.
1.	The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.

Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.
3.	NPAC SMS response to the M-SET.
4.	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.
5.	The NPAC SMS sets the subscriptionVersionStatus to sending and sets the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
6.	NPAC SMS response to the M-SET.
7.	NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.
	NPAC SMS waits for a response from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from at least one, but not each, Local SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		140

Appendix B: Message Flow Diagrams

B.4.1.14.1 Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)

     [Gaphic Omitted: Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)]

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionFailed-SP-List.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2, along with the subscriptionFailed-SP-List.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2, along with the subscriptionFailed-SP-List.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.
	NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.
	NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		141

Appendix B: Message Flow Diagrams

B.4.1.14.2 Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)

[Graphic Omitted: Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)]

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionFailed-SP-List.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2, along with the subscriptionFailed-SP-List.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.
	NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.
	NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		142

Appendix B: Message Flow Diagrams

B.4.1.15 SubscriptionVersion Port-to-Original: Resend

This scenario shows how a port-to-original (resend) port is processed.

[Graphic Omitted: SubscriptionVersion Port-to-Original: Resend]

	SV 1 is the currently active Subscription Version.
	SV 2 is the current pending Subscription Version.
1.	NPAC personnel take action to resend a failed port-to-original for a subscription version.
2.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
3.	NPAC SMS responds to the M-SET.
4.	The NPAC SMS sets the subscriptionVersionStatus to sending on the subscriptionVersionNPAC on SV2.
5.	NPAC SMS response to the M-SET.
6.	NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs that previously failed, that are accepting downloads for the NPA-NXX of the subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation may be sent.
	Each previously failed Local SMS responds with a successful M-DELETE reply.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		143

Appendix B: Message Flow Diagrams

B.4.1.15.1 Subscription Version Port-to-Original: Resend (continued)

[Graphic Omitted: Subscription Version Port-to-Original: Resend (continued)]

	All previously failed Local SMSs respond successfully.
1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
4.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		144

Appendix B: Message Flow Diagrams

B.4.1.16 SubscriptionVersion Port-to-Original: Resend Failure to Local SMS

This scenario shows a failure on a resend of a subscription port-to-original that failed previously to one or more of the Local SMSs. The resend of a failed port-to-original for a subscription can only be performed by authorized NPAC personnel.

[Graphic Omitted: SubscriptionVersion Port-to-Original: Resend Failure to Local SMS]

	SV 1 is the currently active Subscription Version.
	SV 2 is the current pending Subscription Version.
	NPAC personnel take action to resend a failed port-to-original for a subscription version.
1.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
2.	NPAC SMS response to the M-SET.
3.	The NPAC SMS sets the subscriptionVersionStatus to sending on the subscriptionVersionNPAC on SV2.
4.	NPAC SMS response to the M-SET.
5.	NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs that previously failed, that are accepting downloads for the NPA-NXX of the subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation may be sent.
	NPAC SMS waits for a response from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from at least one Local SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		145

Appendix B: Message Flow Diagrams

B.4.1.16.1 SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)

[Graphic Omitted: SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)]

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to “old” or “active” (if all Local SMSs accepting download for the NPA-NXX failed) from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.
2.	NPAC SMS responds to the M-SET.
3.	The NPAC SMS sends to the current/new service provider SOA, depending upon the new/current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to “old” or “active” on SV1.
4.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionFailed-SP-List.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to “partially failed” or “failed” on SV2, along with the subscriptionFailed-SP-List.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the current/new service provider SOA, depending upon the current/new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to “partially failed” or “failed” on SV2, along with the subscriptionFailed-SP-List.
10.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.
	NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.
	NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		146

Appendix B: Message Flow Diagrams

B.4.1.17 Port-To-Original Subscription Version Flows for Pooled TNs

This section contains Port-to-Original flows whose subscription version TNs are part of a pooled block and therefore the behavior of these scenarios is different than normal Port-to-Original subscription version processing.

B.4.1.17.1 Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA (previously NNP flow 3.1.1)

The following scenarios show the broadcast of a Port-to-Original subscription version that is successfully sent to all of the Local SMSs. In this scenario:

• SV1 is the currently active Subscription Version.

• SV2 is the current pending Subscription Version with the Port-To-Original flag set to TRUE.

• SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.

The creation of a port-to-original request will be rejected if the block holder service provider and new service provider are not the same and if the TN is part of a pooled TN range.

This scenario shows the activation by the new service provider SOA and the update to ‘sending’ of the 3 subscription versions.

[Graphic Omitted: Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA]

1. The new, block holder service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs that are within the block.

Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
3.	NPAC SMS responds to the M-SET.
4.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.
5.	NPAC SMS responds to the M-SET.
6.	The NPAC SMS issues an M-CREATE request for SV3 and the subscriptionVersionStatus is set to “sending”, the subscriptionLNPType is set to ‘pool’, the subscriptionActivationTimeStamp, subscriptionCreationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp are set to the current date and time. All routing information originates from the numberPoolBlock that exists for the specified TN(s).
7.	NPAC SMS responds to the M-CREATE.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		147

Appendix B: Message Flow Diagrams

8. The NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (soa-not-authorized) or if there is no version to be activated (no-version-found) or if any other failures occur (invalid-data-values, failed).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		148

Appendix B: Message Flow Diagrams

B.4.1.17.2 Successful Broadcast of Port-to-Original Activation Request for a Pooled TN (previously NNP flow 3.1.2)

The NPAC SMS has the port-to-original request of a pooled TN in sending mode. In this scenario, the broadcasts begin.

[Graphic Omitted: Successful Broadcast of Port-to-Original Activation Request for a Pooled TN]

1.	NPAC SMS issues the M-DELETE for SV1 to the EDR Local SMS that are accepting downloads for the NPA-NXX. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-DELETE request a tunable amount of times.
2.	At the same time as step 1, the NPAC SMS sends out an M-CREATE on the subscription version SV3 to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX of subscription Version SV3. If the create is for multiple subscription versions, the M-ACTION subscriptionVersionLocalSMS-Create will be used instead. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of ‘pool’. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.
3.	The EDR Local SMS responds to the M-DELETE.
4.	Each non-EDR Local SMS responds to the M-CREATE.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		149

Appendix B: Message Flow Diagrams

B.4.1.17.3 Successful Broadcast Complete NPAC SMS Updates for a Port-to-Original Request for a Pooled TN (previously NNP flow 3.1.3)

In this scenario, the NPAC SMS has successfully completed the broadcast of the port-to-original of a pooled TN. The NPAC SMS now updates the status of the subscription versions on the NPAC SMS.

All Local SMSs respond successfully to the port-to-original broadcast of a pooled TN.

[Graphic Omitted: Successful Broadcast Complete NPAC SMS Updates for a Port-to-Original Request for a Pooled TN]

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to active. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionDisconnectCompleteTimeStamp and subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
12.	The current/new, block holder service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		150

Appendix B: Message Flow Diagrams

B.4.1.17.4 Subscription Version Create Port-to-Original of a Pool TN: Failure Broadcast to All Local SMSs (previously NNP flow 3.2.1)

This scenario shows the broadcast of a Port-to-Original subscription version that fails to all of the Local SMSs.

• SV1 is the active Subscription Version.

• SV2 is the pending Subscription Version with the Port to Original flag set to TRUE.

• SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.

In this scenario, the NPAC SMS has the required subscription versions in a ‘sending’ state. The NPAC SMS begins the broadcast.

[Graphic Omitted: Subscription Version Create Port-to-Original of a Pool TN: Failure Broadcast to All Local SMSs]

1. NPAC SMS issues the M-DELETE for SV1 to the EDR Local SMS. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version.

2. At the same time as step 1, the NPAC SMS sends out an M-CREATE on subscription version SV3 to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX of subscription Version SV3. If the create is for multiple subscription versions, the M-ACTION subscriptionVersionLocalSMS-Create will be used instead. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of “pool”.

The NPAC SMS waits for a response from all Local SMSs (EDR and non-EDR).

The NPAC SMS retries any Local SMS that has not responded successfully.

No response or an error is received from all of the EDR and non-EDR Local SMSs.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		151

Appendix B: Message Flow Diagrams

B.4.1.17.5 Updates to NPAC SMS after Failure of Port-to-Original Broadcast for a Pooled TN (previously NNP flow 3.2.2)

The NPAC SMS has just completed an unsuccessful broadcast to the LSMSs of a port-to-original of a pooled TN. The NPAC SMS now proceeds to update the status on the NPAC SMS.

[Graphic Omitted: Updates to NPAC SMS after Failure of Port-to-Original Broadcast for a Pooled TN]

None of the non-EDR Local SMSs has responded successfully to the M-CREATE request for SV3 nor have any of the EDR Local SMSs responded successfully to the M-DELETE for SV1.

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to failure and the subscriptionModifiedTimeStamp is also set to the current date and time.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to active. It also sets the subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to failed. It also sets the subscriptionModifiedTimeStamp to the current date and time and sets the subscriptionFailed-SP-List. The failed SP list contains the EDR and non-EDR Local SMSs who failed to receive the broadcast of SV1 and SV3.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1,, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to active on SV1.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to failed and the subscriptionFailed-SP-List for SV2.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	The NPAC SMS sends to the current/new, block holder service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to failed and the subscriptionFailed-SP-List for SV2.
12.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		152

Appendix B: Message Flow Diagrams

B.4.1.17.6 Port-to-Original Activation Partial Failure Broadcast of a Pooled TN (previously NNP flow 3.3.1)

This scenario shows the broadcast of a Port-to-Original subscription version that fails to one or more, but not all, of the Local SMSs.

• SV1 is the active Subscription Version.

• SV2 is the pending Subscription Version with the Port-To-Original flag set to TRUE.

• SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.

The NPAC SMS has the port-to-original request of a pooled TN in sending mode. In this scenario, the broadcasts begin that will result in a partial failure.

[Graphic Omitted: Port-to-Original Activation Partial Failure Broadcast of a Pooled TN]

1. NPAC SMS issues the M-DELETE to the EDR Local SMS for SV1. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version.

2. NPAC SMS issues an M-CREATE on the subscription version SV3 to all non-EDR Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV3. If the create is for multiple subscription versions, the M-ACTION subscriptionVersionLocalSMS-Create will be used instead. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of “pool”.

3.	The EDR Local SMS responds to the M-DELETE.
4.	Each non-EDR Local SMS responds to the M-CREATE.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		153

Appendix B: Message Flow Diagrams

B.4.1.17.7 Partial-Failure Broadcast Complete NPAC SMS Updates of a Port-to-Original for a Pooled TN (previously NNP flow 3.3.2)

In this scenario, the NPAC SMS has already performed the broadcast of the activation of the port-to-original activation. The broadcast resulted in a partial failure status. The NPAC SMS now updates the objects on the NPAC SMS.

[Graphic Omitted: Partial-Failure Broadcast Complete NPAC SMS Updates of a Port-to-Original for a Pooled TN]

At least one of the non-EDR Local SMSs has not responded successfully to the M-CREATE for SV3 and/or at least one of the EDR Local SMSs has not responded successfully to the M-DELETE for SV1.

1.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to partial failure. The subscriptionModifiedTimeStamp is also set to the current date and time.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the s subscriptionDisconnectCompleteTimeStamp and subscriptionModifiedTimeStamp to the current date and time.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionModifiedTimeStamp to the current date and time and sets the subscriptionFailed-SP-List. The failed list contains the both the EDR and non-EDR Local SMSs who did not complete the broadcast of SV1 and SV3 successfully.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to partially failed and the subscriptionFailed-SP-List for SV2.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to partially failed and the subscriptionFailed-SP-List for SV2.
12.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		154

Appendix B: Message Flow Diagrams

B.4.1.17.8 Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN (previously NNP flow 3.4.1)

This scenario shows how the successful resend of a failed port-to-original broadcast is processed. In this scenario the following subscription versions are used:

• SV1 is the active Subscription Version.

• SV2 is the partially failed or failed Subscription Version with the Port-To-Original flag set to TRUE.

• SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.

In this scenario, the NPAC SMS must resend the port-to-original request. Either at least 1 EDR LSMS failed to receive the M-DELETE for SV1 or at least 1 non-EDR LSMS failed to receive the M-CREATE for SV3. The NPAC SMS will resend the necessary operations to the failed LSMSs.

[Graphic Omitted: Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN]

1.	The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.
2.	NPAC SMS responds to the M-SET.
3.	If one of the failed LSMSs is an EDR LSMS, the NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.
4.	NPAC SMS responds to the M-SET.
5.	If one of the failed LSMSs is a non-EDR LSMS, the NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, the subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV3.
6.	NPAC SMS responds to the M-SET.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		155

Appendix B: Message Flow Diagrams

B.4.1.17.9 Successful Resend Broadcast of a Port-to-Original of a Pooled TN (previously NNP flow 3.4.2)

The NPAC SMS has the necessary subscription versions in sending mode. It now broadcasts the data.

[Graphic Omitted: Successful Resend Broadcast of a Port-to-Original of a Pooled TN]

1.	If one of the failed Local SMSs is an EDR LSMS, the NPAC SMS issues the M-DELETE to the failed EDR Local SMS for SV1. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version.
2.	If one of the failed Local SMSs is a non-EDR LSMS, the NPAC SMS sends out an M-CREATE on the subscription version SV3 to the failed non-EDR Local SMSs that are accepting downloads for the NPA-NXX of subscription Version SV3. If the M-CREATE is for multiple subscription versions, a scoped and filtered operation will be sent. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of “pool”.
3.	If a request was sent, the EDR Local SMS responds to the M-DELETE.
4.	If a request was sent, the non-EDR Local SMS responds to the M-CREATE.

All previously failed Local SMSs respond successfully.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		156

Appendix B: Message Flow Diagrams

B.4.1.17.10 Updates to NPAC SMS after Successful Resend of Port-to-Original Request of a Pooled TN (previously NNP flow 3.4.3)

The NPAC SMS just successfully re-broadcasted the necessary updates to the Local SMS. It now updates the status of the objects on the NPAC SMS.

[Graphic Omitted: Updates to NPAC SMS after Successful Resend of Port-to-Original Request of a Pooled TN]

1.	If a resend to a non-EDR Local SMS was successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to active. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to the M-SET.
3.	If a resend to a EDR Local SMS was successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp. If the subscription status was previously set to “failed”, the subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1,, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.
12.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		157

Appendix B: Message Flow Diagrams

B.4.1.17.11 Subscription Version Create Port-to-Original of a Pool TN: Resend Failure to Local SMS (previously NNP flow 3.5)

This scenario shows how the unsuccessful resend of a failed port-to-original broadcast is processed. In this scenario, the following subscription versions are used:

• SV1 is the active Subscription Version.

• SV2 is the failed Subscription Version with the Port-To-Original flag set to TRUE.

• SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder and its current status is failed.

In the following scenario, the NPAC SMS must resend the port-to-original request. All the EDR LSMS failed to receive the M-DELETE for SV1 and all the non-EDR LSMSs failed to receive the M-CREATE for SV3. The NPAC SMS will resend the necessary operations to the failed LSMSs, but the resend will result in total failure again. The scenario would work just as a successful resend, except for when the NPAC SMS sets the final statuses on the NPAC SMS.

[Graphic Omitted: Subscription Version Create Port-to-Original of a Pool TN: Resend Failure to Local SMS]

1.	If all non-EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to failed. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to the M-SET.
3.	If all the EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 back to active. It also sets the subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 back to failed and setting the subscriptionFailed-SP-List to the list of all the service providers that failed to receive the broadcast successfully (EDR and non-EDR). It also sets the subscriptionModifiedTimeStamp.
6.	NPAC SMS responds to the M-SET.
7.	The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set back to active on SV1.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2 with the subscriptionFailed-SP-List.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2 with the subscriptionFailed-SP-List.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		158

Appendix B: Message Flow Diagrams

12. The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		159

Appendix B: Message Flow Diagrams

B.4.1.17.12 Subscription Version Create Port-to-Original of a Pool TN: Resend Partial Failure to Local SMS (previously NNP flow 3.6)

This scenario shows how the unsuccessful resend of a partially failed port-to-original broadcast is processed. In this scenario, the following subscription versions are used:

• SV1 is the old Subscription Version.

• SV2 is the partially failed Subscription Version with the Port-To-Original flag set to TRUE.

• SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder and its current status is partially failed.

In the following scenario, the NPAC SMS must resend the port-to-original request. At least 1 of the EDR LSMSs failed to receive the M-DELETE for SV1 and/or at least 1 of the non-EDR LSMSs failed to receive the M-CREATE for SV3. The NPAC SMS will resend the necessary operations to the failed LSMSs, but the resend will result in partial failure again. The scenario would work just as a successful resend, except for when the NPAC SMS sets the final statuses on the NPAC SMS.

[Graphic Omitted: Subscription Version Create Port-to-Original of a Pool TN: Resend Partial Failure to Local SMS]

1.	If a resend of a non-EDR Local SMS was not successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to partially failed. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to the M-SET.
3.	If a resend of an EDR Local SMS was not successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 back to old. It also sets the subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionModifiedTimeStamp and setting the subscriptionFailed-SP-List to the list of all the service providers that failed to receive the broadcast successfully (EDR and non-EDR).
6.	NPAC SMS responds to the M-SET.
7.	If SV1 was updated, the NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set back to old on SV1.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2 and the subscriptionFailed-SP-List.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2 and the subscriptionFailed-SP-List.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		160

Appendix B: Message Flow Diagrams

12. The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		161

Appendix B: Message Flow Diagrams

B.4.1.17.13 Subscription Version Port-to-Original of a Pool TN – Creation Prior to NPA-NXX-X Effective Date (previously NNP flow 3.7)

In this scenario, the service provider SOA attempts to create a port-to-original request prior to the effective date of the corresponding serviceProvNPA-NXX-X object. The NPAC SMS will reject this request, as a port-to-original request can not be created prior to the effective date of the corresponding serviceProvNPA-NXX-X.

[Graphic Omitted: Subscription Version Port-to-Original of a Pool TN – Creation Prior to NPA-NXX-X Effective Date]

SOA personnel take action to create a port-to-original request.

1. The new service provider SOA sends a valid, M-ACTION, subscriptionVersionNewSP-Create request with the subscriptionPortingToOriginal-SPSwitch set to ‘TRUE’ for a TN within a pooled block.

2. NPAC SMS replies with an error, ‘soa-not-authorized’.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		162

Appendix B: Message Flow Diagrams

B.4.1.18 SubscriptionVersion Inter-Service Provider Create by either SOA (Old or New Service Provider) with a Due Date which is Prior to the NPA-NXX Effective Date – Error

In this scenario, the old or new service provider SOA attempts to create an inter-service provider port for a TN with no currently active subscription version, with a due date prior to the effective date of the corresponding serviceProvNPA-NXX object (of that TN). The NPAC SMS will reject this request, as an inter-service provider port cannot be created with a due date prior to the effective date of the corresponding serviceProvNPA-NXX.

[Graphic Omitted: SubscriptionVersion Inter-Service Provider Create by either SOA]

SOA personnel take action to create an inter-service provider port for a TN with a due date which is prior to the associated NPA-NXX (of that TN) Effective Date.

1. The old or new service provider SOA attempts to create a new subscription version by sending a valid M-ACTION subscriptionVersionOldSP-Create (or NewSP-Create) request for a TN with a due date which is prior to the Effective Date for the respective NPA-NXX (of that TN).

2. The NPAC SMS sends an error back to the originating SOA, ‘soa-not-authorized’.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		163

Appendix B: Message Flow Diagrams

B.4.2	Modify Scenarios
B.4.2.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 be performed using an M-ACTION only by the current service provider SOA.

This scenario can only be performed when the subscriptionVersionStatus is active and the FailedSP-List is empty. If a Modify Active request is made for an active subscription version that has an entry in the FailedSP-List, the NPAC SMS will reject the request.

[Graphic Omitted: SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA]

Action is taken by current service provider to modify an active subscription version by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified.

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
subscriptionWSMSC-DPC — if supported by the Service Provider SOA
subscriptionWSMSC-SSN — if supported by the Service Provider SOA
subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscriptionSVType – if supported by the Service Provider SOA
subscriptionAlternativeSPID-if supported by the Service Provider SOA

1.	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.
2.	If the M-ACTION data validates, NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionVersionStatus is updated to “sending,” the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp are set, and any other modified attributes are updated.
3.	NPAC SMS issues M-SET response indicating success or failure.
4.	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).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		164

Appendix B: Message Flow Diagrams

5.	NPAC SMS issues M-SET to all Local SMSs for the updated attributes, that are accepting downloads for the NPA-NXX of the subscriptionVersion. If the update involves multiple subscription version objects, a scoped and filtered request will be sent.
6.	Local SMSs reply to M-SET.
	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. However, upon failure the version status is updated to “active” and the subscriptionFailedSP-List is updated to contain the name of the service providers for which the download fails.
7.	NPAC SMS issues M-SET to update the current subscriptionVersionNPAC object subscriptionVersionStatus to “active.”
8.	NPAC SMS responds to M-SET.
9.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current provider of the subscriptionVersionStatus update.
10.	Service provider SOA issues M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		165

Appendix B: Message Flow Diagrams

B.4.2.2 SubscriptionVersion Modify Active: Failure to Local SMS

This scenario shows the broadcast of a modified active subscription that fails to one or more of the Local SMSs.

[Graphic Omitted: SubscriptionVersion Modify Active: Failure to Local SMS]

	The NPAC SMS has an active subscription version that has been successfully modified by the current service provider. The subscription version now has a status of “sending”.
1.	The NPAC SMS issues M-SET to all Local SMSs for the updated attributes, that are accepting downloads for the NPA-NXX of the subscriptionVersion.
	Local SMSs should respond successfully to the M-SET.
	NPAC SMS waits for responses from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from at least one Local SMS.
2.	NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “active” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMS that failed to successfully receive the broadcast.
3.	NPAC SMS responds to the M-SET.
4.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.
5.	The current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		166

Appendix B: Message Flow Diagrams

B.4.2.3 SubscriptionVersion Modify Prior to Activate Using M-ACTION

This scenario can only be performed when the subscriptionVersionStatus is conflict or pending.

NOTE: The flow for un-do of a cancel-pending subscription version is documented in the cancel section, B.5.3.5 Un-Do Cancel-Pending SubscriptionVersion Request.

[Graphic Omitted: SubscriptionVersion Modify Prior to Activate Using M-ACTION]

Action is taken by a service provider to modify a subscriptionVersion by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified.

The old service provider can only update the following attributes:

subscriptionOldSP-DueDate (seconds set to zeros)
subscriptionOldSP-Authorization
subscriptionStatusChangeCauseCode

NOTE: The subscriptionStatusChangeCauseCode can only be modified when the subscriptionOldSP-Authorization is set to FALSE, and, if provided, it’s ignored when the subscriptionOldSP-Authorization is set to TRUE.

The new service provider can only update the attributes:

subscriptionLRN
subscriptionNewSP-DueDate (seconds set to zeros)
subscriptionCLASS-DPC
subscriptionCLASS-SSN
subscriptionLIDB-DPC
subscriptionLIDB-SSN
subscriptionCNAM-DPC
subscriptionCNAM-SSN
subscriptionISVM-DPC
subscriptionISVM-SSN
subscriptionWSMSC-DPC — if supported by the Service Provider SOA
subscriptionWSMSC-SSN — if supported by the Service Provider SOA
subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscriptionSVType – if supported by the Service Provider SOA
subscriptionAlternativeSPID-if supported by the Service Provider SOA

1. Service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the version. The NPAC SMS validates the data.

2. If validation is successful, NPAC SMS will M-SET the attributes modified in the subscriptionVersionNPAC object and set the subscriptionModifiedTimeStamp.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		167

Appendix B: Message Flow Diagrams

3.	The NPAC SMS will issue an M-SET response.
4.	NPAC SMS replies to the M-ACTION with success or failure and reasons for failure.
	Note: If the old service provider was the initiator of the M-ACTION that caused the subscription version status to change, the NPAC SMS would issue a subscriptionVersionStatusAttributeValueChange M-EVENT-REPORT to the old and new service provider SOAs.
5.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the old service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:
	— subscriptionNewSP-DueDate
	— subscriptionNewSP-CreationTimeStamp
	— subscriptionOldSP-Authorization
	— subscriptionOldSP-AuthorizationTimeStamp
	— subscriptionStatusChangeCauseCode

In the event the modification request results in a change of status the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the old service provider SOA.

6.	The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.
7.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the new service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:
	— subscriptionNewSP-DueDate
	— subscriptionNewSP-CreationTimeStamp
	— subscriptionOldSP-Authorization
	— subscriptionOldSP-AuthorizationTimeStamp
	— subscriptionStatusChangeCauseCode
	In the event the modification request results in a change of status the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the new service provider SOA.
8.	The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		168

Appendix B: Message Flow Diagrams

B.4.2.4 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 or pending.

[Graphic Omitted: SubscriptionVersion Modify Prior to Activate Using M-SET]

Action is taken by a service provider to modify the subscriptionVersion by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified. The old service provider can only update the following attributes:

subscriptionOldSP-DueDate (seconds set to zeros)
subscriptionOldSP-Authorization
subscriptionStatusChangeCauseCode

NOTE: The subscriptionStatusChangeCauseCode can only be modified when the subscriptionOldSP-Authorization is set to FALSE

The new service provider can only update the attributes:

subscriptionLRN
subscriptionNewSP-DueDate (seconds set to zeros)
subscriptionCLASS-DPC
subscriptionCLASS-SSN
subscriptionLIDB-DPC
subscriptionLIDB-SSN
subscriptionCNAM-DPC
subscriptionCNAM-SSN
subscriptionISVM-DPC
subscriptionISVM-SSN
subscriptionWSMSC-DPC — if supported by the Service Provider SOA
subscriptionWSMSC-SSN — if supported by the Service Provider SOA
subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscriptionSVType – if supported by the Service Provider SOA
subscriptionAlternativeSPID-if supported by the Service Provider SOA

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

2. The NPAC SMS will issue an M-SET response indicating success or failure and reasons for failure.

Note: If the old service provider was the initiator of the M-SET that caused the subscription version status to change, the NPAC SMS would issue a subscriptionVersionStatusAttributeValueChange M-EVENT-REPORT to the old and new service provider SOAs

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		169

Appendix B: Message Flow Diagrams

3.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the old service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:
	— subscriptionNewSP-DueDate
	— subscriptionNewSP-CreationTimeStamp
	— subscriptionOldSP-Authorization
	— subscriptionOldSP-AuthorizationTimeStamp
	— subscriptionStatusChangeCauseCode
	In the event the modification request results in a change of status the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the old service provider SOA.
4.	The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the new service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:
	— subscriptionNewSP-DueDate
	— subscriptionNewSP-CreationTimeStamp
	— subscriptionOldSP-Authorization
	— subscriptionOldSP-AuthorizationTimeStamp
	— subscriptionStatusChangeCauseCode
	In the event the modification request results in a change of status the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the new service provider SOA.
6.	The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		170

Appendix B: Message Flow Diagrams

B.4.2.5 Subscription Version Modify Active: Resend Successful to Local SMS

This scenario shows the successful resend of a modification of an active subscription. The resend of a failed modified active version can only be performed by authorized NPAC personnel.

[Graphic Omitted: Subscription Version Modify Active: Resend Successful to Local SMS]

	Action is taken by NPAC personnel to resend the failed modified active version.
1.	NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionVersionStatus is updated to “sending”.
2.	NPAC SMS issues M-SET response indicating success or failure.
3.	NPAC SMS issues M-SET to all Local SMSs that previously failed for the updated attributes, and are accepting downloads for the NPA-NXX of the subscriptionVersion.
4.	Local SMSs reply to M-SET.
	All Local SMSs have reported the object modification.
5.	NPAC SMS issues M-SET to update the current subscriptionVersionNPAC object subscriptionVersionStatus to “active.”
6.	NPAC SMS responds to M-SET.
7.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current provider of the subscriptionVersionStatus update.
8.	Service provider SOA issues M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		171

Appendix B: Message Flow Diagrams

B.4.2.6 Subscription Version Modify Active: Resend Failure to Local SMS

This scenario shows a failure on a resend of a modified active subscription that failed previously to one or more of the Local SMSs. The resend of a failed modified active version can only be performed by authorized NPAC personnel.

[Graphic Omitted: Subscription Version Modify Active: Resend Failure to Local SMS]

The NPAC SMS has an active subscription version that has been unsuccessfully modified by the current service provider. The NPAC personnel issues a resend for the failed modified version and the subscription version now has a status of “sending”.

1.	The NPAC SMS issues M-SET to all Local SMSs that previously failed for the updated attributes, and are accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	Local SMSs should respond successfully to the M-SET.
3.	NPAC SMS waits for responses from each Local SMS.
4.	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from at least one or all Local SMSs.
5.	NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “active” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.
6.	NPAC SMS responds to the M-SET.
7.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.
8.	The current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		172

Appendix B: Message Flow Diagrams

B.4.2.7 SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA

This scenario shows the modification of a disconnect pending subscription. The modification of a disconnect pending subscription version can be performed using an M-ACTION only by the current service provider SOA.

[Graphic Omitted: SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA]

Action is taken by current service provider to modify a disconnect pending subscription version by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified.

The current service provider can only modify the following attributes:

subscriptionCustomerDisconnectDate
subscriptionEffectiveReleaseDate

1.	Current service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the disconnect pending version. The NPAC SMS validates the data.
2.	If the M-ACTION data is valid, NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionModifiedTimeStamp is set, and any other modified attributes are updated.
3.	NPAC SMS issues M-SET response indicating success or failure.
4.	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).

If the newly modified ERD is the current date or a previous date, the NPAC will follow the “immediate disconnect” flow (B.5.4.1). Otherwise, the NPAC waits for the subscriptionEffectiveReleaseDate to arrive, at which point it will follow the “immediate disconnect” flow (B.5.4.1).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		173

Appendix B: Message Flow Diagrams

B.4.3 Cancel Scenarios

A subscription version can be canceled when the current status is conflict, pending or disconnect pending.

B.4.3.1 SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred

In this scenario, the old service provider initiates the cancel after both the old and new service provider SOAs have issued their create actions. Once the new service provider SOA’s cancellation acknowledgment is received, the version status is set to “canceled”. Since the old service provider SOA initiated the cancel, its cancellation acknowledgment is optional.

[Graphic Omitted: SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred]

Action is initiated by the old or new service provider SOA to cancel a subscription version by specifying the TN, TN range, or version ID of the subscription version to be canceled.

1. Service provider SOA issues an M-ACTION subscriptionVersionCancel to the NPAC SMS to the lnpSubscriptions object.

Note:  When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionCancelWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2.	NPAC SMS issues M-SET to update subscriptionVersionStatus to “cancel-pending” in the subscriptionVersionNPAC object and the subscriptionModifiedTimeStamp.
3.	NPAC SMS issues M-SET response.
4.	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.
5.	Depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus change is sent from the NPAC SMS to the old service provider SOA.
6.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	Depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChangeM-EVENT-REPORT for the subscriptionVersionStatus change is sent from the NPAC SMS to the new service provider SOA.
8.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		174

Appendix B: Message Flow Diagrams

B.4.3.1.1 Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)

[Graphic Omitted: Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)]

1.	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.
Note:	When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionOldSP-CancellationAcknowledgeWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.
2.	The NPAC SMS issues M-SET for the subscriptionOldSP-CancellationTimeStamp in the subscriptionVersionNPAC object and subscriptionModifiedTimeStamp.
3.	NPAC SMS issues an M-SET response.
4.	NPAC SMS responds to the M-ACTION with either a success or failure and failure reasons. If the action fails, no modifications are applied.
5.	The new service provider SOA sends an M-ACTION subscriptionVersionNewSP-CancellationAcknowledge to the NPAC SMS lnpSubscriptions object.
Note:	When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionNewSP-CancellationAcknowledgeWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.
6.	The NPAC SMS issues M-SET for the subscriptionNewSP-CancellationTimeStamp, subscriptionModifiedTimeStamp, subscriptionCancellationTimeStamp, and subscriptionVersionStatus to “canceled.”
7.	NPAC SMS issues M-SET response.
8.	NPAC SMS replies to M-ACTION with success or failure and reasons for failure. If the action fails, no modifications are applied.
9.	If the last M-ACTION was successful, the NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus update to canceled to the old service provider SOA.
10.	If the last M-ACTION was successful, the old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus update to canceled to the new service provider SOA.
12.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		175

Appendix B: Message Flow Diagrams

B.4.3.2 SubscriptionVersionCancel: No Acknowledgment from a SOA

The NPAC SMS has set the status of the subscription version to “cancel-pending” upon request of the old SOA. It is now waiting for the acknowledgments from both service provider SOAs. Acknowledgment from the old SOA is optional. In this scenario the new service provider does not respond.

[Graphic Omitted: SubscriptionVersionCancel: No Acknowledgment from a SOA]

	NPAC SMS is waiting for the cancellation acknowledgments from both service provider SOAs.
1.	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.
Note:	When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionOldSP-CancellationAcknowledgeWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.
2.	NPAC SMS issues M-SET for the subscriptionOldSP-CancellationTimeStamp and subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.
3.	NPAC SMS responds to M-SET.
4.	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.
	The NPAC SMS waits for the cancellation acknowledgment from the new service provider SOA. No reply is received after a tunable period.
5.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionCancellationAcknowledgeRequest or subscriptionVersionRangeCancellationAcknowledgeRequest M-EVENT-REPORT to the unresponsive new service provider SOA.
6.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
	The “Service Provider Concurrence Cancellation Window” has expired and still no cancellation acknowledgment is received from the new service provider.
7.	NPAC SMS issues M-SET to update the subscriptionVersionStatus to conflict and the subscriptionConflictTimeStamp and subscriptionModifiedTimeStamp are set.
8.	NPAC SMS issues M-SET response.
9.	The NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORTto the old service provider SOA.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		176

Appendix B: Message Flow Diagrams

11.	The NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORTto the new service provider SOA.
12.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
13.	The NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider SOA.
14.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
15.	The NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider SOA.
16.	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.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		177

Appendix B: Message Flow Diagrams

B.4.3.3 Subscription Version Cancels With Only One Create Action Received

Once one of the subscriptionVersionNewSP-Create or subscriptionVersionOldSP-Create actions has been received, the subscription version can be canceled by the same service provider who created the subscription version. In this case, the subscription version status is set to “canceled”, not “cancel-pending”, and no further acknowledgments are necessary by either the old or new service provider.

If the new service provider SOA creates the pending subscription version and the old service provider attempts to cancel it (or vice-versa), an error is returned to the service provider who requested the cancel.

In this scenario, the new service provider SOA has already successfully issued the subscriptionVersionNewSP-Create action. The old service provider has not issued its subscriptionVersionOldSP-Create action. Now, the new service provider needs to cancel the pending subscription version.

[Graphic Omitted: Subscription Version Cancels With Only One Create Action Received]

Action is taken by the new service provider to cancel a subscription version they created.

1.	The new service provider SOA sends M-ACTION subscriptionVersionCancel to the NPAC SMS lnpSubscriptions object to cancel a pending subscriptionVersionNPAC.
Note:	When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionCancelWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.
2.	NPAC SMS issues M-SET to update the subscriptionVersionStatus to “canceled” and update the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.
3.	NPAC SMS issues M-SET response.
4.	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 service provider not authorized.
	If successful, the subscriptionPreCancellationStatus is set to the current subscriptionVersionStatus, and then the subscriptionVersionStatus is set to “canceled”. If the action fails, no modifications are applied and processing stops.
5.	Depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT is sent to the old service provider SOA.
6.	The old service provider confirms the M-EVENT-REPORT.
7.	Depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT is sent to the new service provider SOA.
8.	The new service provider confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		178

Appendix B: Message Flow Diagrams

B.4.3.4 Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison

In this scenario, the current service provider initiates a cancel for a subscription version that has a current status of ‘disconnect-pending’. Once the current service provider’s cancellation request is received, the version status is set to “active”.

[Graphic Omitted: Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison]

Action is initiated by the current service provider SOA to cancel a disconnect pending subscription version by specifying the TN, or version ID of the subscription version to be canceled.

1.	The current service provider SOA sends M-ACTION subscriptionVersionCancel to the NPAC SMS lnpSubscriptions object to cancel one or more pending subscriptionVersionNPAC.
Note:	When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionCancelWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.
2.	NPAC SMS issues an M-SET to update subscriptionVersionStatus to “active” in the subscriptionVersionNPAC object and the subscriptionModifiedTimeStamp.
3.	NPAC SMS issues M-SET Response.
4.	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 service provider not authorized. If successful, the subscription status is set to “active”.
	If the action fails, no modifications are applied and processing stops.
5.	Depending on the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus change is sent to the current Service Provider SOA.
6.	The current service provider SOA returns an M-EVENT-REPORT confirmation back to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		179

Appendix B: Message Flow Diagrams

B.4.3.5 Un-Do Cancel-Pending Subscription Version Request

This scenario can only be performed when the subscription VersionStatus is cancel-pending.

[Graphic Omitted: Un-Do Cancel-Pending Subscription Version Request]

Action is taken by a service provider to un-do a cancel-pending subscription version request by specifying the TN and the version status, or by specifying the version ID of the subscription version to be modified; and the new-version-status set to pending.

Only the service provider that issued the initial cancel request for the subscription version will be allowed to issue an un-do cancel-pending subscription version request.

This flow indicates the Old service provider SOA initiates the request, however either the Old or New service provider SOA is allowed to submit the request so long as they submitted the cancel request.

In this situation the service provider (regardless of whether they are the new or old service provider indicated in the subscription version) can only update the following attribute:

new-version-status=pending

1.	Service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the version. The NPAC SMS validates the data.
2.	If validation is successful, NPAC SMS will M-SET the attributes modified in the subscriptionVersionNPAC object and set the subscriptionModifiedTimeStamp.
3.	The NPAC SMS will issue an M-SET response.
4.	NPAC SMS replies to the M-ACTION with success or failure and reasons for failure.
5.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA, indicating the status is now pending.
6.	The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.
7.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA, indicating the status is now pending.
8.	The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 2006 NeuStar, Inc.		180

Appendix B: Message Flow Diagrams

B.4.4 Disconnect Scenarios

B.4.4.1 SubscriptionVersion Immediate Disconnect

The current service provider can disconnect an active subscription version. In this scenario, the disconnect is immediate.

[Graphic Omitted: SubscriptionVersion Immediate Disconnect]

	Current service provider SOA personnel take action to disconnect a subscription version.
1.	Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs. The subscription version status must be active and no pending, failed, conflict or cancel-pending versions can exist.
2.	NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action.
3.	NPAC SMS responds to whether M-SET was successful.
4.	NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.
5.	NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action. The subscriptionVersionStatus goes to “sending ” and the subscriptionModifiedTimeStamp and the subscriptionBroadcastTimeStamp are both set accordingly.
6.	NPAC SMS responds to whether M-SET was successful.
7.	NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the donor service provider SOA that the subscription version is being disconnected with the customer disconnect date.
8.	The donor service provider SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		181

Appendix B: Message Flow Diagrams

B.4.4.1.1 SubscriptionVersion Immediate Disconnect (continued)

[Graphic Omitted: SubscriptionVersion Immediate Disconnect (continued)]

1.	NPAC SMS sends out an M-DELETE on the subscriptionVersion to all Local SMSs, that are accepting downloads for the NPA-NXX of the subscriptionVersion. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.
2.	Each Local SMS responds with a successful M-DELETE reply.
	All Local SMSs respond successfully.
3.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.
4.	NPAC SMS responds to M-SET.
5.	NPAC SMS issues, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange an M-EVENT-REPORT for the subscriptionVersionStatus equal to “old.”
6.	Service provider SOA responds to M-EVENT-REPORT.
	After a tunable amount of days, the subscription version is purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		182

Appendix B: Message Flow Diagrams

B.4.4.2 SubscriptionVersion Disconnect With Effective Release Date

In this scenario, a future dated request is submitted to disconnect an active subscriptionVersion.

[Graphic Omitted: SubscriptionVersion Disconnect With Effective Release Date]

	Service provider SOA personnel take action to disconnect a subscription version.
1.	Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs, and also has future dated the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict, or cancel-pending versions can exist.
2.	NPAC SMS M-SETs the status to disconnect-pending, and sets the subscriptionEffectiveReleaseDate of the existing subscriptionVersionNPAC and also the subscriptionModifiedTimeStamp.
3.	NPAC SMS responds to M-SET.
4.	NPAC SMS responds to M-ACTION. If the action fails, no modifications are applied and the processing stops.
5.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA.
6.	The current service provider SOA issues the M-EVENT-REPORT confirmation.
	The NPAC SMS waits for the subscriptionEffectiveReleaseDate date to arrive.

At this point, the flow follows an immediate disconnect scenario. First the NPAC SMS sets the subscriptionVersionStatus to sending, then the donor service provider’s SOA is notified of the impending disconnect. The NPAC SMS proceeds to issue M-DELETEs for the subscriptionVersion to the Local SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		183

Appendix B: Message Flow Diagrams

B.4.4.3 SubscriptionVersion Disconnect: Failure to Local SMS

This scenario shows the broadcast of a disconnected subscription that fails to all of the Local SMSs.

[Graphic Omitted: SubscriptionVersion Disconnect: Failure to Local SMS]

	The NPAC SMS has an active subscription version that has been successfully disconnected by the current service provider using the subscriptionVersionDisconnect action. The subscription version now has a status of “sending”.
1.	NPAC SMS issues the M-DELETE to all Local SMSs for the subscriptionVersion, that are accepting downloads for the NPA-NXX of the subscriptionVersion.
	NPAC SMS waits for a response from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from all Local SMSs.
2.	NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “active” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of all the Local SMSs.
3.	NPAC SMS responds to the M-SET.
4.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.
5.	Current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		184

Appendix B: Message Flow Diagrams

B.4.4.4 SubscriptionVersion Disconnect: Partial Failure to Local SMS

This scenario shows the broadcast of a disconnected subscription that fails to one or more, but not all, of the Local SMSs.

[Graphic Omitted: SubscriptionVersion Disconnect: Partial Failure to Local SMS]

	The NPAC SMS has an active subscription version that has been successfully disconnected by the current service provider using the subscriptionVersionDisconnect action. The subscription version now has a status of “sending”.
1.	NPAC SMS issues the M-DELETE to all Local SMSs for the subscriptionVersion, that are accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	Local SMSs should respond successfully to the M-DELETE.
	NPAC SMS waits for a response from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from at least one Local SMS.
3.	NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “old” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.
6.	Current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		185

Appendix B: Message Flow Diagrams

B.4.4.5 Subscription Version Disconnect: Resend Successful to Local SMS

This scenario shows a successful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. The resend of a failed disconnect can only be performed by authorized NPAC personnel.

[Graphic Omitted: Subscription Version Disconnect: Resend Successful to Local SMS]

	NPAC personnel take action to resend a failed disconnect for a subscription version.
1.	NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending”.
2.	NPAC SMS responds to whether M-SET was successful.
3.	NPAC SMS sends out an M-DELETE on the subscriptionVersion to all previously failed Local SMSs, that are accepting downloads for the NPA-NXX of the subscriptionVersion.
4.	Each Local SMS responds with a successful M-DELETE reply.
	All Local SMSs respond successfully.
5.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.
6.	NPAC SMS responds to M-SET.
7.	NPAC SMS issues, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus equal to “old.”
8.	Service provider SOA responds to M-EVENT-REPORT.
	After a tunable amount of days, the subscription version is purged by the NPAC SMS housekeeping process.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		186

Appendix B: Message Flow Diagrams

B.4.4.6 Subscription Version Disconnect: Resend Failure to Local SMS

This scenario shows a failure on a resend of a subscription disconnect that failed previously to one or more of the Local SMSs. The resend of a failed disconnect for a subscription can only be performed by authorized NPAC personnel.

[Graphic Omitted: Subscription Version Disconnect: Resend Failure to Local SMS]

	NPAC personnel take action to resend a failed disconnect for a subscription version.
1.	NPAC SMS issues the M-DELETE to all Local SMSs for which the disconnect previously failed for the subscriptionVersion, and are accepting downloads for the NPA-NXX of the subscriptionVersion.
2.	Local SMSs should respond successfully to the M-DELETE.
	NPAC SMS waits for a response from each Local SMS.
	NPAC SMS retries any Local SMS that has not responded.
	No response or an error is received from at least one or all Local SMSs.
3.	NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “old” or “active” (if all Local SMSs failed) from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.
6.	Current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		187

Appendix B: Message Flow Diagrams

B.4.4.7 Disconnect Subscription Version Scenarios for TNs that are part of a Number Pool Block

B.4.4.7.1 SOA Initiates Successful Disconnect Request of Ported Pooled TN (previously NNP flow 4.1.1)

The current service provider can disconnect an active subscription version that will return to the block holder after the number pool block has been activated. In this scenario, the disconnect is immediate where the TN returns to the block holder and the number pool block is active. In this scenario:

• SV1 is the currently active Subscription Version that will be disconnected.

• SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.

SV1 will be broadcast to the EDR Local SMSs to disconnect the ported TN and revert to the number pool block routing information. SV2 will be broadcast to the non-EDR Local SMSs with the number pool block routing information.

In this scenario, the SOA sends in the disconnect action to a ported, pooled TN.

[Graphic Omitted: SOA Initiates Successful Disconnect Request of Ported Pooled TN]

Current service provider SOA personnel take action to disconnect a subscription version.

1.	Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs, and also has NOT future dated (i.e., used the current date) the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict or cancel-pending versions can exist.
2.	NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action for SV1. The subscriptionVersionStatus for SV1 goes to “sending ”. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp are set accordingly.
3.	NPAC SMS responds to the M-SET.
4.	NPAC SMS issues M-CREATE to create SV2. The routing information comes from the numberPoolBlock object that contains the TN. The status is set to ‘sending’. The subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp, subscriptionCreationTimeStamp and subscriptionModifiedTimeStamp are all set.
5.	NPAC SMS responds to M-CREATE.
6.	NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.
7.	NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the Donor service provider SOA that the subscription version is being disconnected with the customer disconnect date. This SOA is the block holder SOA.
8.	The donor service provider SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		188

Appendix B: Message Flow Diagrams

B.4.4.7.2 Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation (previously NNP flow 4.1.2)

The NPAC SMS is ready to broadcast the disconnect of the ported, pooled TN.

[Graphic Omitted: Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation]

1.	NPAC SMS sends the M-DELETE request to the EDR Local SMS to delete the existing subscription version and cause the routing to return to the number pool block. If a range of subscription versions is being removed, the M-DELETE will be scoped and filtered for the appropriate subscription versions by TN.
2.	At the same time as step 1, the NPAC SMS sends out the M-CREATE of a subscription version to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscription version for SV2. If the M-CREATE is for multiple subscription versions, the subscriptionVersionLocalSMS-Create M-ACTION will be sent. The subscription version for the TN has a LNP type of ‘pool’.
3.	EDR Local SMS sends its successful M-DELETE reply.
4.	Non-EDR Local SMS responds with a successful M-CREATE reply.
5.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to active for subscriptionVersionNPAC objects for SV2. The subscriptionModifiedTimeStamp is also set.
6.	NPAC SMS responds to M-SET.
7.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects for SV1. It also sets the subscriptionModifiedTimeStamp. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
8.	NPAC SMS responds to M-SET.
9.	NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA for the subscriptionVersionStatus being set to old on SV1.
10.	The current service provider SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		189

Appendix B: Message Flow Diagrams

B.4.4.7.3 Subscription Version Disconnect With Effective Release Date (replace/update existing flow B.5.4.2 with this flow here – NNP flow 4.2)

In this scenario, a future dated request is submitted to disconnect an active subscription version that will return to the block holder.

[Graphic Omitted: Subscription Version Disconnect With Effective Release Date]

Current service provider SOA personnel take action to disconnect a subscription version.

1.	Current service provider SOA issues an M-ACTION request to disconnect the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN, or range of TNs, and also has future dated the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict, conflict-pending, or cancel-pending versions can exist.
2.	NPAC SMS issues an M-SET to set the status to disconnect-pending, and set the subscriptionEffectiveReleaseDate, and the subscriptionModifiedTimeStamp of the existing subscriptionVersionNPAC.
3.	NPAC SMS responds to M-SET.
4.	NPAC SMS responds to M-ACTION. If the action fails, no modifications are applied and the processing stops.
5.	NPAC SMS sends, depending upon the block holder service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA.
6.	The current service provider SOA issues the M-EVENT-REPORT confirmation.

The NPAC SMS waits for the subscriptionEffectiveReleaseDate date to arrive.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		190

Appendix B: Message Flow Diagrams

B.4.4.7.4 Subscription Version Disconnect of a Ported Pooled TN After Block Activation: Failure to Local SMS (previously NNP flow 4.3.1)

This scenario shows the broadcast of a disconnect subscription after block activation that fails to all of the Local SMSs. In this scenario:

• SV1 is the currently active Subscription Version.

• SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN After Block Activation: Failure to Local SMS]

NPAC SMS has a subscription version that is in the process of being disconnected. The subscription version TN is part of a number pool block. SV1, the subscription being disconnected, and SV2, the reinstatement of the routing data in the number pool block, are in a state of ‘sending’.

1.	NPAC SMS sends the M-DELETE request to the EDR Local SMS for SV1.
2.	At the same time as step 1, the NPAC SMS sends the M-CREATE request to the non-EDR Local SMS for SV2.

NPAC SMS waits for responses from all Local SMSs.

NPAC SMS retries each Local SMS that has not responded.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		191

Appendix B: Message Flow Diagrams

B.4.4.7.5 Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates (previously NNP flow 4.3.2)

NPAC SMS is attempting to disconnect a subscription version whose TN is a part of a number pool block. It has broadcast the data to the LSMSs.

[Graphic Omitted: Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates]

No response occurs from any of the Local SMS, or all return failures to the M-CREATE or M-DELETE request, or a combination of the two.

1.	NPAC SMS issues the M-SET to update the SV2 subscriptionVersionStatus from “sending” to “failed”. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to update the SV1 subscriptionVersionStatus from “sending” to “active”. It also updates the subscriptionFailed-SP-List with the service provider ID and name of all the Local SMSs. The subscriptionModifiedTimeStamp is also set.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status for SV1 along with the subscriptionFailed-SP-List.
6.	Current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		192

Appendix B: Message Flow Diagrams

B.4.4.7.6 Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS (previously NNP flow 4.4.1)

This scenario shows the broadcast of a disconnect subscription version after the number pool block activation that fails to one or more, but not all, Local SMSs. In this scenario:

• SV1 is the currently active Subscription Version.

• SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.

NPAC SMS has a subscription version that is in the process of being disconnected. The subscription version TN is part of a number pool block. SV1, the subscription being disconnected, and SV2, the reinstatement of the routing data in the number pool block, are in a state of ‘sending’.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS]

1.	NPAC SMS sends the M-DELETE request to the EDR Local SMS for SV1.
2.	At the same time as step 1, the NPAC SMS sends the M-CREATE request to the non-EDR Local SMS for SV2.
3.	The EDR Local SMS responds to the M-DELETE.
4.	The non-EDR Local SMS responds to the M-CREATE.

NPAC SMS waits for responses from all Local SMSs.

NPAC SMS retries each Local SMS that has not responded.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		193

Appendix B: Message Flow Diagrams

B.4.4.7.7 Subscription Version Disconnect of a Ported Pooled TN Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.4.2)

NPAC SMS is attempting to disconnect a subscription version whose TN is a part of a number pool block.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Partial Failure Broadcast NPAC SMS Updates]

A response does not occur from at least one, but not all Local SMSs and/or at least one, but not all, Local SMSs respond with an error to the M-DELETE or M-CREATE request.

1.	NPAC SMS issues the M-SET to update the SV2 subscriptionVersionStatus from “sending” to “partially-failed”. The subscriptionModifiedTimeStamp and subscriptionActivationTimeStamp are also set.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues the M-SET to update the SV1 subscriptionVersionStatus from “sending” to “old”. It also updates the subscriptionFailed-SP-List with the service provider ID and name of all the non-EDR and EDR Local SMSs that failed the broadcast. The subscriptionModifiedTimeStamp is also set. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the status of ‘old’ for SV1 along with the subscriptionFailed-SP-List.
6.	Current service provider SOA issues the M-EVENT-REPORT confirmation.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		194

Appendix B: Message Flow Diagrams

B.4.4.7.8 Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS (previously NNP flow 4.5.1)

This scenario shows a successful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. The resend of a failed disconnect can only be performed by authorized NPAC personnel. In this scenario:

• SV1 is the currently active Subscription Version.

• SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.

NPAC Personnel take action to resend a failed disconnect for a subscription version (SV1) that took place after the activation of the number pool block.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS]

1.	NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues an M-SET to update the subscriptionVersionNPAC object for SV2. The subscriptionVersionStatus is set to “sending” for SV2 and the subscriptionModifiedTimeStamp is updated.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-DELETE on the subscriptionVersion SV1 to all previously failed EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV1 TN.
6.	At the same time as step 5, the NPAC SMS issues an M-CREATE on the subscription version SV2 to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX and had previously failed.
7.	EDR Local SMS responds successfully to the M-DELETE on SV1.
8.	Each non-EDR Local SMS responds successfully to the M-CREATE on SV2.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		195

Appendix B: Message Flow Diagrams

B.4.4.7.9 Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates (previously NNP flow 4.5.2)

All non-EDR Local SMSs have responded successfully to the M-CREATE for SV2 and all EDR Local SMSs have responded successfully to the M-DELETE for SV1.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates]

1.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to ‘active’ for SV2. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to M-SET.
3.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to ‘old’ for SV1. The subscriptionModifiedTimeStamp is also set.
4.	NPAC SMS responds to M-SET.
5.	NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider for SV1 with the subscriptionVersionStatus set to ‘old’.
6.	Current service provider confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		196

Appendix B: Message Flow Diagrams

B.4.4.7.10 Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS (previously NNP flow 4.6.1)

This scenario shows an unsuccessful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. the resend of a failed disconnect can only be performed by NPAC personnel. In this scenario:

• SV1 is the currently active Subscription Version.

• SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder with a status of failed.

NPAC Personnel take action to resend a failed disconnect for a subscription version (SV1). This rebroadcast will result in failure again.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS]

1.	NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.
2.	NPAC SMS responds to the M-SET.
3.	NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV2 and the subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.
5.	NPAC SMS issues an M-DELETE on the subscriptionVersion SV1 to all previously failed EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV1 TN.
6.	At the same time as step 5, the NPAC SMS issues an M-CREATE on the subscriptionVersion SV2 to all previously failed non-EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV2 TN.

NPAC SMS waits for responses from all Local SMSs.

NPAC SMS retries each Local SMS that has not responded.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		197

Appendix B: Message Flow Diagrams

B.4.4.7.11 Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates (previously NNP flow 4.6.2)

None of the non-EDR Local SMSs has responded successfully to the M-CREATE and none of the EDR Local SMSs responded successfully to the M-DELETE.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates]

1.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to failed for SV2. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to M-SET.
3.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to active for SV1. The subscriptionFailed-SP-List and subscriptionModifiedTimeStamp is also set.
4.	NPAC SMS responds to M-SET.
5.	NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider for SV1 with the subscriptionVersionStatus set to ‘active’ and the subscriptionFailed-SP-List.
6.	Current service provider confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		198

Appendix B: Message Flow Diagrams

B.4.4.7.12 Subscription Version Disconnect of a Ported Pooled TN: Resend Partial Failure to Local SMS (previously NNP flow 4.7.1)

This scenario shows an unsuccessful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. the resend of a failed disconnect can only be performed by NPAC personnel. In this scenario:

• SV1 is the previously active Subscription Version now with a status of old.

• SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder with a status of partially failed.

The NPAC SMS is initiating the resend of a previously partially failed disconnect of a ported, pooled TN for a number pool block that was active at the time of the initial broadcast.

1.	If a non-EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.
2.	NPAC SMS responds to the M-SET.
3.	If an EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV2 and the subscriptionModifiedTimeStamp.
4.	NPAC SMS responds to the M-SET.
5.	If the status of SV1 is set to sending, the NPAC SMS issues an M-DELETE on the subscriptionVersion SV1 to all previously failed EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV1 TN.
6.	At the same time as step 5 and if the status of SV2 is set to sending, the NPAC SMS issues an M-CREATE on the subscriptionVersion SV2 to all previously failed non-EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV2 TN.
7.	The EDR Local SMS responds to the M-DELETE request.
8.	The non-EDR Local SMS responds to the M-CREATE request.

NPAC SMS waits for responses from all Local SMSs.

NPAC SMS retries each Local SMS that has not responded.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Resend Partial Failure to Local SMS]

B.4.4.7.13 Subscription Version Disconnect of a Ported Pooled TN Resend Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.7.2)

At least one of the non-EDR Local SMSs has not responded successfully to the M-CREATE and/or at least one of the EDR Local SMSs has not responded successfully to the M-DELETE.

[Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Resend Partial Failure Broadcast NPAC SMS]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		199

Appendix B: Message Flow Diagrams

1.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to partially-failed for SV2. The subscriptionModifiedTimeStamp is also set.
2.	NPAC SMS responds to M-SET.
3.	NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for SV1. The subscriptionFailed-SP-List and subscriptionModifiedTimeStamp is also set.
4.	NPAC SMS responds to M-SET.
5.	NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider for SV1 with the subscriptionVersionStatus set to ‘old’ along with the subscriptionFailed-SP-List.
6.	Current service provider confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		200

Appendix B: Message Flow Diagrams

B.4.4.7.14 Subscription Version Immediate Disconnect of a Contaminated Pooled TN Prior to Block Activation (after Effective Date) (previously NNP flow 4.8)

In this scenario, the current service provider disconnects an active subscription version that will return to the block holder. However, the NPA-NXX-X is past the effective date, but has not yet been activated.

[Graphic Omitted: Subscription Version Immediate Disconnect of a Contaminated Pooled TN Prior to Block Activation]

Current service provider SOA personnel take action to disconnect a subscription version.

1.	Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs, and also has NOT future dated (i.e., used the current date) the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict or cancel-pending versions can exist.
2.	NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action for SV1. The subscriptionVersionStatus for SV1 goes to “sending ”. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp are set accordingly.
3.	NPAC SMS responds to whether M-SET was successful.
4.	NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.
5.	NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the Donor service provider SOA that the subscription version is being disconnected with the customer disconnect date. This SOA is the block holder SOA.
6.	The donor service provider SOA confirms the M-EVENT-REPORT.
7.	NPAC SMS sends the M-DELETE request to the Local SMS to delete the existing subscription version.
8.	Local SMS sends its M-DELETE reply.

All Local SMSs have responded successfully.

9.	NPAC SMS sets the subscriptionVersionStatus to ‘old’ and sets the subscriptionModifiedTimeStamp. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.
10.	NPAC SMS responds to the M-SET.
11.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange notification to the current service provider’s SOA with the subscriptionVersionStatus set to ‘old’.
12.	Service provider SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		201

Appendix B: Message Flow Diagrams

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

B.4.5.1 SubscriptionVersion Conflict by the NPAC SMS

This scenario shows a version being placed into conflict by the NPAC personnel.

[Graphic Omitted: SubscriptionVersion Conflict by the NPAC SMS]

	NPAC personnel or NPAC SMS take action to set the status of a subscription to “conflict.”
1.	NPAC SMS issues M-SET request to update subscriptionVersionStatus to “conflict,” subscriptionConflictTimeStamp, and subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.
2.	NPAC SMS issues an M-SET response. If the M-SET fails, processing for this scenario stops.
3.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to old service provider SOA.
4.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange to new service provider SOA.
6.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider to set the old service provider’s authorization to “FALSE”. Since the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider to set the old service provider’s authorization to “FALSE”. Since the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		202

Appendix B: Message Flow Diagrams

B.4.5.1.1 Subscription Version Conflict Resolution by the NPAC SMS (continued)

[Graphic Omitted: Subscription Version Conflict Resolution by the NPAC SMS (continued)]

	Once the conflict is resolved, NPAC personnel take action to remove the subscriptionVersion from conflict.
1.	NPAC SMS issues an M-SET request to update the subscriptionModifiedTimeStamp and the subscriptionVersionStatus to “pending.”
2.	NPAC SMS issues an M-SET response. If the M-SET fails, processing for this scenario stops.
3.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the new status to the old service provider SOA.
4.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the new status to the new service provider SOA.
6.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider’s SOA indicating the authorization has been set to “TRUE”.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider’s SOA indicating the authorization has been set to “TRUE”.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		203

Appendix B: Message Flow Diagrams

B.4.5.2 Subscription Version Conflict Removal by the New Service Provider SOA

In this scenario, the new service provider elects to remove the subscription version from conflict.

[Graphic Omitted: Subscription Version Conflict Removal by the New Service Provider SOA]

	A subscription version exists on the NPAC SMS with a status of conflict.
	The new service provider SOA personnel take action to remove the subscription version from conflict.
1.	The new service provider SOA sends the M-ACTION Request subscriptionVersionRemoveFromConflict specifying the subscription version TN or subscription version ID of the subscription version in conflict.

Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionRemoveFromConflictWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.

2.	If the request is valid, the NPAC SMS will set the status to “pending”.
	The request will be denied and an error returned if the subscriptionOldSP-Authorization was set to conflict by the old service provider and the conflict restriction window has not expired and/or the old service provider specified cause code value 50 or 51, regardless of the conflict restriction window expiration.
3.	The NPAC SMS responds to its own M-SET.
4.	The NPAC SMS sends an M-ACTION Response with success or failure and reason for failure.
5.	The NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider’s SOA.
6.	The New SOA sends the M-EVENT-REPORT confirmation.
7.	The NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider’s SOA.
8.	The Old SOA sends the M-EVENT-REPORT confirmation.
9.	NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to set the old service provider’s authorization to “TRUE”.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider indicating the authorization has been set to “TRUE”.
12.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		204

Appendix B: Message Flow Diagrams

B.4.5.3 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: SubscriptionVersion Conflict: No Conflict Resolution]

	NPAC personnel or NPAC SMS take action to set a subscriptionVersionStatus to “conflict.”
1.	NPAC SMS issues an M-SET request to set the subscriptionVersionStatus to “conflict,” the subscriptionConflictTimeStamp, and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.
2.	NPAC SMS responds to M-SET. If the M-SET fails, processing stops for this scenario until the M-SET completes successfully.
3.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange to old service provider SOA for the new “conflict” status.
4.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange to new service provider SOA for the “conflict” status.
6.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
7.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider to set the authorization to “FALSE”. Since the Subscription Version Status was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.
8.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
9.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider to set the authorization to “FALSE”. Since the Subscription Version Status was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.
10.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		205

Appendix B: Message Flow Diagrams

B.4.5.3.1 Subscription Version Conflict: No Conflict Resolution (continued)

[Graphic Omitted: Subscription Version Conflict: No Conflict Resolution (continued)]

	“Version Conflict Cancellation Window” expires without conflict resolution.
1.	NPAC SMS issues an M-SET request to set the subscriptionVersionStatus to “cancel” in the subscriptionVersionNPAC object and sets the subscriptionCancellationTimeStamp and subscriptionModifiedTimeStamp.
2.	NPAC SMS responds to M-SET. If the M-SET fails, processing stops for this scenario until the M-SET is successfully completed.
3.	NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for status to old service provider SOA for the “cancel” status.
4.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
5.	NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for status to new service provider SOA for the “cancel” status.
6.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		206

Appendix B: Message Flow Diagrams

B.4.5.4 Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)

The old service provider SOA can put a pending subscription version into conflict by setting its authorization flag to FALSE. This can be done on the subscriptionVersionOldSP-Create action, subscriptionVersionModify action, or M-SET of the attribute on the subscription version object.

This scenario shows the old service provider putting a new pending subscription version into conflict by turning the authorization flag FALSE on the subscriptionVersionOldSP-Create. In this case, the old service provider’s create action is the second sent to the NPAC SMS.

[Graphic Omitted: Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)]

	Action is taken by the old service provider to set a subscription version to conflict using the subscriptionVersionOldSP-Create action.
1.	The old service provider SOA sends M-ACTION subscriptionVersionOldSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC with the status of “conflict”.
	The old service provider SOA specifies the following valid attributes:
	subscriptionTN or valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionOldSP-DueDate (seconds set to zeros) subscriptionOldSP-Authorization subscriptionLNPType subscriptionStatusChangeCauseCode
	In this case, the subscriptionOldSP-Authorization is set to FALSE.
2.	NPAC SMS issues M-CREATE to create the subscriptionVersionNPAC with a status of “conflict” and sets all the other attribute values from the subscriptionVersionOldSP-Create action.
3.	NPAC SMS issues M-CREATE response.
4.	NPAC SMS returns M-ACTION reply. This either reflects a success or failure and reasons for the failure.
5.	If the action was successful, the NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA notifying them of the updates.
6.	The old service provider SOA confirms the M-EVENT-REPORT.
7.	If the action was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		207

Appendix B: Message Flow Diagrams

	subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA notifying them of the updates.
8.	The new service provider SOA confirms the M-EVENT-REPORT.
9.	NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to set the old service provider’s authorization to “FALSE”. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to set the new service provider authorization to “FALSE”. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.
12.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		208

Appendix B: Message Flow Diagrams

B.4.5.5 Subscription Version Conflict Removal by the Old Service Provider SOA

In this scenario, the old service provider elects to remove the subscription version from conflict.

[Graphic Omitted: Subscription Version Conflict Removal by the Old Service Provider SOA]

	A subscription version exists on the NPAC SMS with a status of conflict.
	The old service provider SOA personnel take action to remove the subscription version from conflict.
1.	The old service provider SOA sends the M-ACTION subscriptionVersionRemoveFromConflict specifying the subscription version TN or subscription version ID of the subscription version in conflict.
2.	If the request is valid, the NPAC SMS will set the status to “pending”.
3.	The NPAC SMS responds to its own M-SET.
4.	The NPAC SMS responds to the M-ACTION with success or failure and reason for failure.
5.	The NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the Old SOA.
6.	The Old SOA sends the M-EVENT-REPORT confirmation.
7.	The NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the New SOA.
8.	The New SOA sends the M-EVENT-REPORT confirmation.
9.	NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider indicating the authorization has been set to “TRUE”.
10.	The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.
11.	NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider indicating the authorization has been set to “TRUE”.
12.	The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3 ©1997—2006 NeuStar, Inc.		209

Appendix B: Message Flow Diagrams

B.4.6      SubscriptionVersion Query

This scenario shows subscriptionVersion query from service provider systems to the NPAC SMS.

[Graphic Omitted: SubscriptionVersion Query]

	Action is taken by either a service provider SOA or Local SMS for retrieving one or more versions of a subscription.
1.	The service provider SOA or Local SMS issues a scoped filtered M-GET from the lnpSubscriptions object to retrieve a specific version for a subscription version 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.
2.	For Service Providers that DO NOT support the enhanced SV Query Functionality (Service Provider SV Query Indicator tunable parameter set to FALSE), the NPAC SMS replies with the first requested subscriptionVersion data if the requested number of records is less than or equal to “Max SubscriberQuery” specified in the NPAC SMS. Otherwise a complexityLimitation error will be returned.
	For Service Providers that support the enhanced SV Query functionality (Service Provider SV Query Indicator tunable parameter set to TRUE,) the NPAC SMS replies with the requested subscriptionVersion data if the requested number of records is less than or equal to “Maximum Subscription Query” tunable value specified in the NPAC SMS. If the requested subscriptionVersion data exceeds the tunable value, then the number of subscriptionVersion records that equal the tunable value will be returned. The service provider SOA or Local SMS will use the data returned to submit a subsequent query, starting with the next record from where the previous query finished. Only when subscriptionVersion data is returned that contains less than the tunable value, is it safe for the service provider SOA or Local SMS to assume all data has been retrieved from the NPAC SMS.

The query return data includes:

subscriptionVersionId (SOA, LSMS)

subscriptionTN (SOA, LSMS)

subscriptionLRN (SOA, LSMS)

subscriptionNewCurrentSP (SOA, LSMS)

subscriptionOldSP (SOA)

subscriptionNewSP-DueDate (SOA)

subscriptionNewSP-CreationTimeStamp (SOA)

subscriptionOldSP-DueDate (SOA)

subscriptionOldSP-Authorization (SOA)

subscriptionOldSP-AuthorizationTimeStamp (SOA)

subscriptionActivationTimeStamp (SOA)

subscriptionBroadcastTimeStamp (SOA)

subscriptionConflictTimeStamp (SOA)

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		210

Appendix B: Message Flow Diagrams

subscriptionCustomerDisconnectDate (SOA)

subscriptionDisconnectCompleteTimeStamp (SOA)

subscriptionEffectiveReleaseDate (SOA)

subscriptionVersionStatus (SOA, LSMS)

subscriptionCLASS-DPC (SOA, LSMS)

subscriptionCLASS-SSN (SOA, LSMS)

subscriptionLIDB-DPC (SOA,LSMS)

subscriptionLIDB-SSN (SOA, LSMS)

subscriptionCNAM-DPC (SOA, LSMS)

subscriptionCNAM-SSN (SOA, LSMS)

subscriptionISVM-DPC (SOA, LSMS)

subscriptionISVM-SSN (SOA, LSMS)

subscriptionWSMSC-DPC — if supported by the Service Provider SOA (SOA, LSMS)

subscriptionWSMSC-SSN — if supported by the Service Provider SOA (SOA, LSMS)

subscriptionEndUserLocationValue (SOA)

subscriptionEndUserLocationType (SOA)

subscriptionBillingId (SOA)

subscriptionLNPType (SOA)

subscriptionPreCancellationStatus (SOA)

subscriptionCancellationTimeStamp (SOA)

subscriptionOldTimeStamp (SOA)

subscriptionModifiedTimeStamp (SOA)

subscriptionCreationTimeStamp (SOA)

subscriptionOldSP-CancellationTimeStamp (SOA)

subscriptionNewSP-CancellationTimeStamp (SOA)

subscriptionOldSP-ConflictResolutionTimeStamp (SOA)

subscriptionNewSP-ConflictResolutionTimeStamp (SOA)

subscriptionPortingToOriginal-SPSwitch (SOA)

subscriptionFailedSP-List (SOA)

subscriptionDownloadReason (SOA)

subscriptionTimerType (SOA) — if supported by the Service Provider

subscriptionBusinessType (SOA) — if supported by the Service Provider

subscriptionStatusChangeCauseCode (SOA)

subscriptionSVType – if supported by the Service Provider

subscriptionAlternativeSPID – if supported by the Service Provider

3.	The NPAC SMS replies with the rest of the subscription version data that matches the requested criteria.
4.	The NPAC SMS replies with the final, empty M-GET response.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		211

Appendix B: Message Flow Diagrams

B.4.6.1 Subscription Data Download

DELETED. This scenario is superceded by the text and flows in section B.7, Local SMS and SOA Recovery.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		212

Appendix B: Message Flow Diagrams

B.5       LSMS Filter NPA-NXX Scenarios

B.5.1            lsmsFilterNPA-NXX Creation by the Local SMS

[Graphic Omitted: lsmsFilterNPA-NXX Creation by the Local SMS]

	Action is taken by the Local SMS personnel to create an lsmsFilterNPA-NXX object.
1.	The Local SMS sends the M-CREATE request to the NPAC for the lsmsFilterNPA-NXX object to be created.
2.	The NPAC SMS attempts to create the object. If successful, the M-CREATE response is returned. Otherwise, an error is returned.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		213

Appendix B: Message Flow Diagrams

B.5.2      lsmsFilterNPA-NXX Deletion by the Local SMS

[Graphic Omitted: lsmsFilterNPA-NXX Deletion by the Local SMS]

	Action is taken by the Local SMS personnel to delete an lsmsFilterNPA-NXX object.
1.	The Local SMS sends the M-DELETE request to the NPAC for the lsmsFilterNPA-NXX object to be removed.
2.	The NPAC SMS attempts to delete the object. If successful, the M-DELETE response is returned. Otherwise, an error is returned.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		214

Appendix B: Message Flow Diagrams

B.5.3      lsmsFilterNPA-NXX Query by the Local SMS

[Graphic Omitted: lsmsFilterNPA-NXX Query by the Local SMS]

	Action is taken by the Local SMS personnel to query for one or all lsmsFilterNPA-NXX object(s).
1.	The Local SMS sends the M-GET request to the NPAC for the lsmsFilterNPA-NXX object(s).
2.	If the Service Provider ID was specified, all lsmsFilterNPA-NXX objects for that Service Provider are returned. If only one object was requested, that object is returned.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		215

Appendix B: Message Flow Diagrams

B.5.4      lsmsFilterNPA-NXX Creation by the SOA

[Graphic Omitted: lsmsFilterNPA-NXX Creation by the SOA]

	Action is taken by the SOA personnel to create an lsmsFilterNPA-NXX object.
1.	The SOA sends the M-CREATE request to the NPAC for the lsmsFilterNPA-NXX object to be created.
2.	The NPAC SMS attempts to create the object. If successful, the M-CREATE response is returned. Otherwise, an error is returned.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		216

Appendix B: Message Flow Diagrams

B.5.5      lsmsFilterNPA-NXX Deletion by the SOA

[Graphic Omitted: lsmsFilterNPA-NXX Deletion by the SOA]

	Action is taken by the SOA personnel to delete an lsmsFilterNPA-NXX object.
1.	The SOA sends the M-DELETE request to the NPAC for the lsmsFilterNPA-NXX object to be removed.
2.	The NPAC SMS attempts to delete the object. If successful, the M-DELETE response is returned. Otherwise, an error is returned.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		217

Appendix B: Message Flow Diagrams

B.5.6      lsmsFilterNPA-NXX Query by the SOA

[Graphic Omitted: lsmsFilterNPA-NXX Query by the SOA]

	Action is taken by the SOA personnel to query for one or all lsmsFilterNPA-NXX object(s).
1.	The SOA sends the M-GET request to the NPAC for the lsmsFilterNPA-NXX object(s).
2.	If the Service Provider ID was specified, all lsmsFilterNPA-NXX objects for that Service Provider are returned. If only one object was requested, that object is returned.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		218

Appendix B: Message Flow Diagrams

B.6      Local SMS and SOA Recovery

For all download requests in this section, the Local SMS or SOA should behave as follows in response to the possible download M-ACTION response from the NPAC SMS:

Success – process the data received from the NPAC SMS, continue processing.

No-data-selected – no data was found, continue processing.

Criteria-too-large (using the Maximum Number of Download Records tunable) – break up the request into a smaller time range and re-issue the request to the NPAC SMS (only applies to SV requests).

OR

Criteria-too-large (using the Maximum Number of Download Notifications tunable) – break up the request into a smaller time range and re-issue the request to the NPAC SMS (only applies to notification requests).

Time-range-invalid (using the Maximum Download Duration tunable) – break up the request into shorter time ranges and re-issue the request to the NPAC SMS.

Failed – go into retry mode. Re-issue the request configurable number of additional retry attempts with an “x” amount of delay between requests (“x” is based on a configurable amount of time after receiving the failure for each request). If a failed response is received for the final retry request, abort the association and re-start the recovery process. Note: It is recommended that the Local SMS or SOA use the same value that the NPAC SMS uses for retry interval.

For activities that specify “continue processing”, the Local SMS or SOA should send the NPAC SMS, either the next lnpDownload Action for a different type of data, or an lnpRecoveryComplete request, depending on where the response appears in the flow.

It is optional as to whether the Local SMS recovers Service Provider Data, Network Data, Subscription Data, Notification Data, or any combination of the four; and if the SOA recovers the Service Provider Data, Network Data, and/or Notification Data, or any combination of the three. Number Pool Block information may (optionally) be recovered by EDR-capable LSMSs. For a Local SMS or SOA that initiates recovery, the only step that is required is the lnpRecoveryComplete message, at the end of all previous data recovery requests. This instructs the NPAC SMS to send previously queued messages and resume normal processing.

Due to prerequisite data requirements on some local systems (service provider object must exist before subtending network data, which must exist before subtending subscription versions, etc.), it is also expected that the order of recovery would be Service Provider Data, followed by Network Data, Subscription Data, Number Pool Block Data (for LSMSs that are EDR-capable), then Notification Data.

If the Local SMS or SOA supports the receipt of linked action replies (based on the Local SMS Linked Replies Indicator and SOA Linked Replies Indicator, in the NPAC Customer record), the NPAC SMS will send linked action replies when a recovery request is initiated and the amount of data returned is greater than the associated Blocking Factor.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		219

Appendix B: Message Flow Diagrams

B.6.1      Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS (previously NNP flow 5.2)

This scenario demonstrates how a non-EDR Local SMS resynchronizes itself with the NPAC SMS.

This scenario demonstrates the recovery of additions, deletions and modifications of network and subscription version data. The recovery of this data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS]

Local SMS personnel take action to resynchronize their Local SMS with the NPAC SMS.

The Non-EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set. The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.

1. Non-EDR Local SMS sends the lnpDownload M-ACTION to start network data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified. If one of the following is selected (all-network-data, all NPA-NXX-X data, a range of NPA-NXX-X data, a single NPA-NXX-X), the NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.

2. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies. . In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).

3. Non-EDR Local SMS sends the lnpDownload M-ACTION to start subscription data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified.

4. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data). All creates, modifies and

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		220

Appendix B: Message Flow Diagrams

	deletes are received, a single record for each subscription version. (i.e. no ranges). The Non-EDR Local SMS will receive all the activity on subscription versions with a LNP type of ‘pool’.
5.	If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).
6.	The old service provider SOA confirms the M-EVENT-REPORT.
7.	If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA of the status change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).
8.	The current service provider SOA confirms the M-EVENT-REPORT.
9.	If any corrections were issued to the resyncing Local SMS for subscription versions with LNP type equal to ‘pool’, the NPAC SMS will send the numberPoolBlockStatusAttributeValueChange to the current block holder SOA, if the numberPoolBlockSOA-Origination indicator is TRUE, with the current number pool block status and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains the discrepancy).
10.	The block holder SOA confirms the M-EVENT-REPORT.
11.	If deletes were sent for any subscription versions with LNP type equal to ‘pool’ that completed the broadcast of the M-DELETEs for a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs, who support the serviceProvNPA-NXX-X object, the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.
12.	Local SMS responds to the M-DELETE.
13.	Non-EDR Local SMS sends M-ACTION, lnpNotificationRecovery, to the NPAC SMS. The Non-EDR Local SMS specifies a time range.
14.	If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with the notification updates that occurred within the given time range. If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).
15.	Non-EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.
16.	NPAC SMS replies to the M-ACTION.

Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		221

Appendix B: Message Flow Diagrams

B.6.1.1      Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM

This scenario demonstrates how a non-EDR Local SMS resynchronizes itself with the NPAC SMS using SWIM criteria.

This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, subscription version, and notification data. The recovery of network and subscription version data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM]

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM]

Local SMS personnel take action to resynchronize their Local SMS with the NPAC SMS.
The Non-EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set. The Service Provider LSMS SWIM Recovery Indicator in the recovering Service Provider’s profile on the NPAC SMS must be set to TRUE and the recovery requests (lnpDownload and lnpNotificationRecovery) must include the SWIM attribute to recover only the messages that were missed. The Linked Replies indicator must also be set to TRUE.

The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.

1.	Non-EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: service provider data download. In this case, the Local SMS specifies the SWIM attribute.
2.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
3.	Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
4.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
5.	Non-EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: network data download. In this case, the Local SMS specifies the SWIM attribute.
6.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		222

Appendix B: Message Flow Diagrams

	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
	The NPAC SMS sends the missed, serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.
7.	Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
8.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
9.	Non-EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: subscription data download. In this case, the Local SMS specifies the SWIM attribute.
10.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
	All creates, modifies and deletes are received, a single record for each subscription version. (i.e. no ranges). The Non-EDR Local SMS will receive all the activity on subscription versions with a LNP type of ‘pool’.
11.	Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
12.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
13.	If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).
14.	The old service provider SOA confirms the M-EVENT-REPORT.
15.	If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA of the status change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		223

Appendix B: Message Flow Diagrams

16.	The current service provider SOA confirms the M-EVENT-REPORT.
17.	If any corrections were issued to the resyncing Local SMS for subscription versions with LNP type equal to ‘pool’, the NPAC SMS will send the numberPoolBlockStatusAttributeValueChange to the current block holder SOA, if the numberPoolBlockSOA-Origination indicator is TRUE, with the current number pool block status and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains the discrepancy).
18.	The block holder SOA confirms the M-EVENT-REPORT.
19.	If deletes were sent for any subscription versions with LNP type equal to ‘pool’ that completed the broadcast of the M-DELETEs for a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs, who support the serviceProvNPA-NXX-X object, the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.
20.	Local SMS responds to the M-DELETE.
21.	Non-EDR Local SMS sends the lnpNotificationRecovery M-ACTION to start SWIM: notification data download. The Non-EDR Local SMS specifies the SWIM attribute.
22.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
23.	Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
24.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.

Note:

If any of the SWIM processing recovery responses from the NPAC SMS (SwimProcessing-Recovery Response) include a stop-date (timestamp), this indicates that the SWIM Maximum tunable has been exceeded, and SWIM data accumulation stopped at the provided stop-date (timestamp). In order to fully synchronize with the NPAC SMS, since additional messages may have been missed, the Service Provider will want to issue additional recovery requests specifying criteria other than SWIM to get all missing data (see B.7.1 for example). Alternatively, upon receiving the stop-date timestamp the Service Provider may perform time-based recovery after each SWIM-based recovery request for each data type. For example, the Service Provider would request SWIM-based recovery for SP data and if they receive a stop-date timestamp they would then perform time-base recovery for SP data; then the Service Provider would request SWIM-based recovery for Network Data and if they receive a stop-date timestamp they would then perform time-based recovery for Network Data – and so on and so forth for each data type.

Upon successful recovery, SWIM accumulation will be turned back on for the Service Provider.

25.	Non-EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.
26.	NPAC SMS replies to the M-ACTION.

Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		224

Appendix B: Message Flow Diagrams

B.6.2      Sequencing of Events on Initialization/Resynchronization of EDR Local SMS (previously NNP flow 5.1)

This scenario demonstrates how an EDR Local SMS resynchronizes itself with the NPAC SMS.

These scenarios demonstrate the recovery of additions, deletions and modifications of network, subscription version and number pool block data. The recovery of this data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of EDR Local SMS]

The EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set.

The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.

1.	EDR Local SMS sends lnpDownload M-ACTION to start network data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified. If one of the following is selected (all-network-data, all NPA-NXX-X data, a range of NPA-NXX-X data, a single NPA-NXX-X), the NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.
2.	If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).
3.	EDR Local SMS sends the lnpDownload M-ACTION to start subscription data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified.
4.	If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data). All creates, modifies and deletes are received, a single record for each subscription version. (i.e. no ranges). The EDR Local SMS will not receive any activity on subscription versions with LNP type of ‘pool’.
5.	If any corrections were issued to the resyncing Local SMS that involved the activation of a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		225

Appendix B: Message Flow Diagrams

6.	The old service provider SOA confirms the M-EVENT-REPORT.
7.	If any corrections were issued to the resyncing Local SMS that involved a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).
8.	The current service provider SOA confirms the M-EVENT-REPORT.
9.	EDR Local SMS sends the lnpDownload M-ACTION to start number pool block data download. The Local SMS specifies the start time.
10.	NPAC SMS responds to M-ACTION with updates.
11.	NPAC SMS sends the M-EVENT-REPORTs to the block holder SOAs for any number pool block with the SOA-Origination indicator set to true whose numberPoolBlockFailed-SP-List and possibly numberPoolBlockStatus were just updated due to the number pool block download.
12.	Block holder SOA confirms to the M-EVENT-REPORT.
13.	If deletes were sent for any number pool blocks that completed the broadcast of the M-DELETEs of a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.
14.	Local SMS responds the M-DELETE.
15.	EDR Local SMS sends M-ACTION, lnpNotificationRecovery, to the NPAC SMS. The EDR Local SMS specifies a time range.
16.	If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with the notification updates that occurred within the given time range. If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).
17.	EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.
18.	NPAC SMS replies to the M-ACTION.

Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		226

Appendix B: Message Flow Diagrams

B.6.2.1     Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM

This scenario demonstrates how an EDR Local SMS resynchronizes itself with the NPAC SMS using SWIM criteria.

This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, subscription version, number pool block, and notification data. The recovery of network, subscription version and number pool block data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM]

Local SMS personnel take action to resynchronize their Local SMS with the NPAC SMS.

The EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set. The Service Provider LSMS SWIM Recovery Indicator in the recovering Service Provider’s profile on the NPAC SMS must be set to TRUE and the recovery request (lnpDownload and lnpNotificationRecovery) must include the SWIM attribute to recover only the messages that were missed. The Linked Replies indicator must also be set to TRUE.

The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.

1.	EDR Local SMS sends lnpDownload M-ACTION to start SWIM: service provider data download. In this case, the Local SMS specifies the SWIM attribute.
2.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
3.	EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
4.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
5.	EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: network data download. In this case, the Local SMS specifies the SWIM attribute.
6.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		227

Appendix B: Message Flow Diagrams

	a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
	The NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.
7.	EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
8.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
9.	EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: subscription data download. In this case, the Local SMS specifies the SWIM attribute.
10.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
	All creates, modifies and deletes are received, a single record for each subscription version. (i.e. no ranges). The EDR Local SMS will not receive any activity on subscription versions with LNP type of ‘pool’.
11.	EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
12.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
13.	If any corrections were issued to the resyncing Local SMS that involved the activation of a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).
14.	The old service provider SOA confirms the M-EVENT-REPORT.
15.	If any corrections were issued to the resyncing Local SMS that involved a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).
16.	The current service provider SOA confirms the M-EVENT-REPORT.
17.	EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: number pool block data download. The Local SMS specifies the SWIM attribute.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		228

Appendix B: Message Flow Diagrams

18.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
19.	EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
20.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
21.	NPAC SMS sends the M-EVENT-REPORTs to the block holder SOAs for any number pool block with the SOA-Origination indicator set to true whose numberPoolBlockFailed-SP-List and possibly numberPoolBlockStatus were just updated due to the number pool block download.
22.	Block holder SOA confirms to the M-EVENT-REPORT.
23.	If deletes were sent for any number pool blocks that completed the broadcast of the M-DELETEs of a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.
24.	Local SMS responds the M-DELETE.
25.	EDR Local SMS sends the lnpNotificationRecovery M-ACTION to start SWIM: notification data download. The EDR Local SMS specifies the SWIM attribute.
26.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
27.	EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
28.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.

Note: If any of the SWIM processing recovery responses from the NPAC SMS (SwimProcessing-RecoveryResponse) include a stop-date (timestamp), this indicates that the SWIM Maximum tunable has been exceeded, and SWIM data accumulation stopped at the provided stop-date (timestamp). In order to fully synchronize with the NPAC SMS, since additional messages may have been missed, the Service Provider will want to issue additional recovery requests specifying criteria other than SWIM to get all missing data (see B.7.2 for example). Alternatively, upon receiving the stop-date timestamp the Service Provider may perform time-based recovery after each SWIM-based recovery request for each data type. For example, the Service

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		229

Appendix B: Message Flow Diagrams

Provider would request SWIM-based recovery for SP data and if they receive a stop-date timestamp they would then perform time-base recovery for SP data; then the Service Provider would request SWIM-based recovery for Network Data and if they receive a stop-date timestamp they would then perform time-based recovery for Network Data – and so on and so forth for each data type.

Upon successful recovery, SWIM accumulation will be turned back on for the Service Provider.

29.	EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.
30.	NPAC SMS replies to the M-ACTION.

Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		230

Appendix B: Message Flow Diagrams

B.6.3      Sequencing of Events on Initialization/Resynchronization of SOA

This scenario demonstrates how a SOA resynchronizes itself with the NPAC SMS. In this example, the SOA supports network data over the SOA.

If the SOA supports a separate SOA channel for notifications, then they should associate with the notificationDownload function bit.

This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, and notification data.

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of SOA]

SOA takes action to resynchronize their SOA with the NPAC SMS.

The SOA establishes an association to the NPAC SMS with the resynchronization flag on, and the network data management (networkDataMgmt) association function set. The NPAC SMS will queue all current activity on the NPAC SMS until the service SOA sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.

1.	SOA sends the lnpDownload M-ACTION to start network data download. In this case, the SOA specifies the start time and end time. There are criteria other than time which may be specified. If one of the following is selected (all-network-data, all NPA-NXX-X data, a range of NPA-NXX-X data, a single NPA-NXX-X), the NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the SOA’s “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.
2.	If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the SOA responds to the M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).
3.	SOA sends M-ACTION, lnpNotificationRecovery, to the NPAC SMS. The SOA specifies a time range.
4.	If the requested notification(s) exist and the SOA Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with the notification updates that occurred within the given time range. If the requested notification(s) exist and the SOA Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).
5.	SOA sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.
6.	NPAC SMS replies to the M-ACTION.

Any activity that the NPAC SMS had queued up during the recovery period will now be sent.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		231

Appendix B: Message Flow Diagrams

Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		232

Appendix B: Message Flow Diagrams

B.6.3.1       Sequencing of Events on Initialization/Resynchronization of SOA using SWIM

This scenario demonstrates how a SOA resynchronizes itself with the NPAC SMS using SWIM criteria. In this example, the SOA supports network data, data downloads and notifications over the SOA.

If the SOA supports a separate SOA channel for notifications, then they should associate with the notificationDownload function bit.

This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, and notification data.

[Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of SOA using SWIM]

SOA takes action to resynchronize their SOA with the NPAC SMS.

The SOA establishes an association to the NPAC SMS with the resynchronization flag on, and the network data management (networkDataMgmt) association function set. The Service Provider SOA SWIM Indicator in the recovering Service Provider’s profile on the NPAC SMS must be set to TRUE and the recovery requests (lnpDownload and lnpNotificationRecovery) must include the SWIM attribute to recover only the messages that were missed. The Linked Replies indicator must also be set to TRUE.

The NPAC SMS will queue all current activity on the NPAC SMS until the SOA sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.

1.	SOA sends the lnpDownload M-ACTION to start swim: service provider data download. In this case, the SOA specifies the SWIM attribute.
2.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the SOA should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
3.	SOA issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
4.	NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.
5.	SOA sends lnpDownload M-ACTION to start SWIM: network data download. In this case, the SOA specifies the SWIM attribute.
6.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		233

Appendix B: Message Flow Diagrams

	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the SOA should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
	The NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the SOA’s “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.
7.	SOA issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACITON reply.
8.	NPAC SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResponse.
9.	SOA sends lnpNotificationRecovery M-ACTION to start SWIM: notification data download. The SOA specifies the SWIM attribute.
10.	The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.
	In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.
	In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the SOA should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.
11.	SOA issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.
12.	NPAC SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResponse.

Note:

If any of the SWIM processing recovery responses from the NPAC SMS (SwimProcessing-RecoveryResponse) include a stop-date (timestamp), this indicates that the SWIM Maximum tunable has been exceeded, and SWIM data accumulation stopped at the provided stop-date (timestamp). In order to fully synchronize with the NPAC SMS, since additional messages may have been missed, the Service Provider will want to issue additional recovery requests specifying criteria other than SWIM to get all missing data (see B.7.3 for example). Alternatively, upon receiving the stop-date timestamp the Service Provider may perform time-based recovery after each SWIM-based recovery request for each data type. For example, the Service Provider would request SWIM-based recovery for SP data and if they receive a stop-date timestamp they would then perform time-base recovery for SP data; then the Service Provider would request SWIM-based recovery for Network Data and if they receive a stop-date timestamp they would then perform time-based recovery for Network Data – and so on and so forth for each data type.

Upon successful recovery, SWIM accumulation will be turned back on for the Service Provider.

13.	SOA sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.
14.	NPAC SMS replies to the M-ACTION.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		234

Appendix B: Message Flow Diagrams

Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		235

Appendix B: Message Flow Diagrams

B.7       Miscellaneous

B.7.1            SOA/Local SMS Notification of Scheduled NPAC Downtime

This scenario shows SOA/Local SMS notification of scheduled NPAC downtime.

[Graphic Omitted: SOA/Local SMS Notification of Scheduled NPAC Downtime]

     Action is taken by NPAC SMS personnel to schedule downtime for the NPAC SMS system

1.	The NPAC SMS sends an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT to the Local SMSs.
2.	The Local SMSs respond by sending an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT confirmation back to the NPAC SMS.
3.	The NPAC SMS sends an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT to all SOAs.
4.	The SOA(s) respond by sending an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT confirmation back to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		236

Appendix B: Message Flow Diagrams

B.7.2            NPA-NXX Split

This scenario shows NPAC SMS personnel initiation of an NPA-NXX split that does not involve a Number Pool Block object.

[Graphic Omitted: NPA-NXX Split]

The NPAC SMS will create NPA-NXX split data based on information in the NPA Split Load Flat File from an industry source.

The old NPA-NXX exists and is past the effective date of the object.

The NPAC SMS will automatically generate the add/delete of the new NPA-NXX based on information in the NPA Split Load Flat File from an industry source.

The permissive dialing period begins.

The NPAC SMS updates all subscription version records in its local database that are affected by the NPA-NXX Split. The TN field will be updated with the new NPA. Internal mapping between the old and new NPA-NXXs for the TNs is maintained.

The NPAC SMS accepts requests involving the old and new NPA-NXX values but only broadcasts using the new NPA-NXX value.

The permissive dialing period expires.

1.	NPAC SMS deletes the old serviceProvNPA-NXX object locally.
2.	NPAC SMS responds to the M-DELETE.
3.	The NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the Local SMSs who are accepting downloads for this NPA-NXX.
4.	At the same time as step 7, the NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the SOAs who are accepting downloads for this NPA-NXX.
5.	The Local SMS responds to the M-DELETE.
6.	The SOA responds to the M-DELETE.

The NPAC SMS updates all subscription version records in its local database that match the specified TN range by updating the TN value for each object and removing the internal field.

All Local SMS, SOA and NPAC SMS will now use the new NPA-NXX for all requests.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		237

Appendix B: Message Flow Diagrams

B.7.2.1       NPA-NXX Split that contains a block of pooled TNs Part 1 (previously NNP flow 7)

In this scenario, the NPAC SMS personnel initiate an NPA-NXX split that contains a block of pooled TNs.

[Graphic Omitted: NPA-NXX Split that contains a block of pooled TNs Part 1]

The NPAC SMS will create NPA-NXX split data based on information in the NPA Split Load Flat File from an industry source.

The old NPA-NXX and NPA-NXX-X exist and are past the effective date of the objects.

The NPAC SMS will automatically generate the add/ delete of the new NPA-NXX based on information in the NPA Split Load Flat File from an industry source.

1.	The NPAC SMS automatically creates the new serviceProvNPA-NXX-X objects with the effective date equal to the date of the start of permissive dialing.
2.	The NPAC SMS responds to the M-CREATE.
3.	The NPAC SMS broadcasts each serviceProvNPA-NXX-X M-CREATE to the Local SMSs that support the object according to their NPAC Customer LSMS NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.
4.	At the same time as step 3, the NPAC SMS broadcasts each serviceProvNPA-NXX-X M-CREATE to the SOAs that support the object according to their NPAC Customer SOA NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.
5.	The Local SMS responds to the M-CREATE request.
6.	The SOA responds to the M-CREATE request.

The NPAC SMS updates all subscription version and number pool block records in its local database that match the specified TN range. The TN or NPA-NXX-X field will be updated with the new NPA and a data field internal to the NPAC SMS will be set to the previous TN or NPA-NXX-X value (old NPA).

The permissive dialing period starts.

During the permissive dialing period, the NPAC SMS accepts requests involving the old and new NPA-NXX values according to the following rules:

• For subscription versions and number pool blocks, the NPAC SMS will accept either the new or old NPA-NXX value, but only broadcast using the new NPA-NXX value.

• The creation of a new serviceProvNPA-NXX-X object using either the old or new NPA-NXX value, but the NPAC SMS will create and broadcast both the old and new serviceProvNPA-NXX-X object creations to those service providers who support the serviceProvNPA-NXX-X object according to their NPAC Customer LSMS NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.

• If a serviceProvNPA-NXX-X is to be removed (de-pooled), the NPAC SMS will broadcast the M-DELETEs for both the old and new serviceProvNPA-NXX-X objects.

• The removal of a NXX from the NPA-NXX split will cause the broadcast of the M-DELETE of the new serviceProvNPA-NXX-X object to the Local SMSs.

The permissive dialing period continues into the next flow.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		238

Appendix B: Message Flow Diagrams

B.7.2.2       NPA-NXX Split that contains a block of pooled TNs Part 2 (previously NNP flow 7)

The Permissive Dialing Period is in progressive for an NPA-NXX split. This flow shows what occurs at the end of the Permissive Dialing Period.

[Graphic Omitted: NPA-NXX Split that contains a block of pooled TNs Part 2]

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		239

Appendix B: Message Flow Diagrams

The permissive dialing period expires.

1.	NPAC SMS deletes the old serviceProvNPA-NXX-X object locally.
2.	NPAC SMS responds to the M-DELETE.
3.	The NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX-X objects to the Local SMSs who are supporting the object according to the NPAC Customer LSMS NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.
4.	At the same time as step 3, the NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX-X objects to the SOAs who are supporting the object according to the NPAC Customer SOA NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.
5.	The Local SMS responds to the M-DELETE.
6.	The SOA responds to the M-DELETE.
7.	NPAC SMS deletes the old serviceProvNPA-NXX object locally.
8.	NPAC SMS responds to the M-DELETE.
9.	The NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the Local SMSs who are supporting downloads of the object according to their NPA-NXX filters on the NPAC SMS.
10.	At the same time as step 9, the NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the SOAs who are supporting the object according to their NPA-NXX filters on the NPAC SMS.
11.	The Local SMS responds to the M-DELETE.
12.	The SOA responds to the M-DELETE.

The NPAC SMS updates all subscription version and number pool block records in its local database that match the specified TN range by updating the TN or NPA-NXX-X value for each object and removing the internal field.

All Local SMS, SOA and NPAC SMS will now use the new NPA-NXX and NPA-NXX-X for all requests.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		240

Appendix B: Message Flow Diagrams

B.7.3            Mass Update

NPAC SMS personnel can perform a mass update on subscription data.

[Graphic Omitted: Mass Update]

	Action is taken by the NPAC SMS personnel to request that a mass update be performed on active subscription data.
	Search the subscription database for subscription versions that match the specified mass update criteria. Perform steps 1 through 4 for the allowable range of subscription versions. The NPAC logs as errors subscription versions that match the mass update criteria but are in the wrong state.
1.	The NPAC SMS sends an M-SET on the subscription versions to the Local SMS, that is accepting downloads for the NPA-NXX of the subscription versions.
2.	The Local SMS replies to the M-SET.
3.	The NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA.
4.	The service provider SOA sends a confirmation to the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		241

Appendix B: Message Flow Diagrams

B.7.3.1       Mass Update for a range of TNs that contains a Number Pool Block (previously NNP flow 8)

In this scenario, the NPAC SMS personnel perform a mass update on a range of TNs that includes a number pool block object.

[Graphic Omitted: Mass Update for a range of TNs that contains a Number Pool Block]

Action is taken by NPAC SMS personnel to perform a mass update.
The NPAC SMS may specify the service provider ID, LNP type and TN-Range in its selection criteria. The LNP type can be restricted as only LISP, only LSPP, only POOL, or none (which would then include all three types).
The NPAC SMS can update only the routing information (LRN, DPC and SSN data).
If the LNP type includes ‘pool’ TNs, the TN-Range specified must include a number pool block’s entire TN-Range.
The NPAC SMS searches the number pool block and subscription version databases for the objects that match the selection criteria. For all objects that match the criteria, the following occurs:
1.	NPAC SMS sends the M-SET for the number pool block objects to the EDR Local SMSs who are accepting updates for the NPA-NXX.
2.	NPAC SMS sends the M-SET, scope and filtered for the appropriate criteria, for the non-pooled subscription version updates to the EDR Local SMS who are accepting updates for the NPA-NXX.
3.	NPAC SMS sends the M-SET, scope and filtered for the appropriate criteria, for the subscription version updates to the non-EDR Local SMSs who are accepting updates for the NPA-NXX.
4.	EDR Local SMS responds to the M-SET for the number pool block object.
5.	EDR Local SMS responds to the M-SET for the subscription versions.
6.	Non-EDR Local SMS responds to the M-SET for the subscription versions.
7.	NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA for any subscription versions, not of LNP type set to ‘pool’, that were updated to a status of ‘active’.
8.	SOA confirms the M-EVENT-REPORT.
9.	NPAC SMS sends the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange for the status being set to ‘active’ to the block holder service provider SOA for any number pool block objects updated to a status of ‘active’ if the numberPoolBlockSOA-Origination indicator is ‘TRUE’.
10.	SOA confirms the M-EVENT-REPORT.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		242

Appendix B: Message Flow Diagrams

B.7.4            Application Level Heartbeat Requests

B.7.4.1       NPAC initiated Application Level Heartbeat Request to local system

     This scenario shows the NPAC sending an Application Level Heartbeat Message to the SOA/LSMS.

[Graphic Omitted: NPAC initiated Application Level Heartbeat Request to local system]

1.	The NPAC SMS sends an M-EVENT-REPORT ApplicationLevelHeartbeat Request to the SOA/Local SMS that support this feature, after a configurable amount of time with no message traffic
2.	The SOA/Local SMS issues an M-EVENT-REPORT ApplicationLevelHeartbeat Response back to the NPAC SMS.

If the response in step 2 is not provided within the timeout period, the association is aborted by the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		243

Appendix B: Message Flow Diagrams

B.7.4.2       Local system initiated Application Level Heartbeat request

This scenario show the SOA/LSMS sending an Application Level Heartbeat Message to the NPAC SMS.

[Graphic Omitted: Local system initiated Application Level Heartbeat request]

1. The SOA/LSMS sends an M-EVENT-REPORT ApplicationLevelHeartbeat Request to the NPAC SMS, after a configurable amount of time with no message traffic

2. The NPAC SMS issues an M-EVENT-REPORT ApplicationLevelHeartbeat Response back to the SOA/LSMS.

If the response in step 2 is not provided within the timeout period, the expectation is that the SOA/LSMS would abort their association to the NPAC SMS.

March 9, 2006	NANC Version 3.3.2a		NPAC SMS Interoperable Interface Specification
Release 3.3©1997 — 2006 NeuStar, Inc.		244