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, 2009
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 incorporation or organization)	(I.R.S. Employer Identification No.)
46000 Center Oak Plaza Sterling, Virginia (Address of principal executive offices)	20166 (Zip Code)

(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 þ     No o

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 whether the registrant has submitted electronically and posted on its corporate Web site, if any, every Interactive Data File required to be submitted and posted pursuant to Rule 405 of Regulation S-T during the preceding 12 months (or for such shorter period that the registrant was required to submit and post such files).  Yes o     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, a non-accelerated filer, or a smaller reporting company. See the definitions of “large accelerated filer,” “accelerated filer” and “smaller reporting company” in Rule 12b-2 of the Exchange Act. (Check one):

Large accelerated filer þ Accelerated filer o Non-accelerated filer o
(Do not check if a
smaller reporting company) Smaller reporting company o

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 February 19, 2010, 74,465,138 shares of NeuStar Class A common stock were outstanding and 3,082 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, 2009 was approximately $1.74 billion.

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 2010 Annual Meeting of Stockholders, which NeuStar intends to file with the Securities and Exchange Commission within 120 days of December 31, 2009.

TABLE OF CONTENTS

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

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.

ITEM 1.   BUSINESS

Overview

We provide essential clearinghouse services to the communications industry and enterprise customers. Our customers use the databases we contractually maintain in our clearinghouse to obtain data required to successfully route telephone calls in North America, to exchange information with other communications service providers, or CSPs, 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 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, and AT&T Inc., must access our clearinghouse to properly route virtually all of their customers’ calls. We provide clearinghouse services to emerging CSPs, including Internet service providers, mobile network operators, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, we provide domain name services, including internal and external managed DNS solutions that play a key role in directing and managing traffic on the Internet, and we manage the authoritative directories for the .us and .biz Internet domains. We operate the authoritative directory for U.S. Common Short Codes, which is part of the short messaging service relied upon by the U.S. wireless industry, and provide solutions used by mobile network operators throughout Europe and Asia to enable mobile instant messaging for their end users.

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 critical technology services that solve the addressing, interoperability and infrastructure needs of CSPs and enterprises. These services are now used by CSPs and enterprises to manage a range of their technical and operating requirements, including:

•  Addressing.  We enable CSPs and enterprises 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 their networks by centrally managing certain critical data they use to route communications over their networks.

Company Information and History

We incorporated in Delaware in 1998 to acquire our business from Lockheed Martin Corporation. We completed this acquisition 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. 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.

1

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 and enterprises 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. The 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 Internet Protocol, or 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.

Enterprises in the United States and throughout the world have become increasingly reliant on the Internet and other DNS-based systems to support their businesses. With the growth in e-commerce and the emergence of advanced DNS-based communication services, large and small enterprises have increased demand for:

•  secure and reliable email and networks;

•  authoritative directories for Internet domain names; and

•  domain name registration services.

Our Clearinghouse

We provide our services from a set of unique databases, systems and platforms in geographically dispersed data centers, which we refer to collectively as our clearinghouse. We designed our clearinghouse to provide substantial advantages in meeting the challenges facing the communications industry and enterprises for both traditional voice and IP networks. First, our clearinghouse databases and capabilities provide competing CSPs and enterprises with fair, equal and 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, such as mobile instant messaging, regardless of originating or terminating technologies. Third, our customers may access our clearinghouse through standard interfaces. Our clearinghouse also enables connections to authoritative operating data for our customers, including CSPs, content providers and enterprises. As a result, our clearinghouse facilitates advanced services, such as multi-media content services and mobile instant messaging. Finally, our services facilitate the management of networks and services, including the deployment of new technologies and protocols, the balancing of communications traffic across our customers’ internal networks, network consolidation, and the control of instant messaging services, which promote our customers’ ability to create differentiated and value-added services.

2

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

•  Reliable.  Our clearinghouse services depend on complex technology that is designed to deliver reliability consistent with industry standards and the standards of our customers. 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 these standards.

•  Scalable.  The modular design of our clearinghouse enables capacity expansion without service interruption or quality of service degradation, 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 on a regular basis.

NeuStar Clearinghouse Services

Addressing

“Addresses” are a shared resource among CSPs and, in certain circumstances, enterprises. 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 the identification of multiple addresses 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 and enterprises require 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 services under fixed-fee 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. As of January 1, 2009, we are paid on an annual, fixed-fee basis.

3

•  Internet Infrastructure Services.

•  Ultra Services.  We provide a suite of services that play a key role in directing and managing Internet traffic, and monitoring, testing and measuring the performance of websites and networks. All of these services enable thousands of customers to intelligently and securely control and distribute Internet traffic, while ensuring security, scalability and reliability of websites, email and networks. We are typically paid a recurring monthly fee based on contractually established monthly transaction volumes. If the transactions processed exceed the maximum of the transaction volumes that were contractually established, we are paid a per-transaction fee for these excess transactions.

•  Domain Name Registry Services.  We operate the authoritative registries of Internet domain names for the .biz and .us top level domains. In addition, we are the technical back-end registry operator for the .travel and .tel top-level domains. All Internet communications routing to any of these domains must query a copy of our directory to ensure that the communication is routed to the appropriate destination. We are the exclusive provider of wholesale registration services to domain name retailers for all regions outside of the home countries for the .cn, or the country code top-level domain for China, and .tw, or the country code top-level domain for Taiwan. We are primarily paid on a subscription basis for each name in the registries.

•  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 by consumer brand companies and organizations to count votes using wireless devices in promotional marketing efforts, such as votes for sporting event MVPs, to register for contests and special offers, to download applications such as ring tones, and are used for product awareness campaigns. 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 in the United States and Canada 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. In the United States, as of January 1, 2009, we are paid on an annual, fixed-fee basis. In Canada, 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.

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. Our services include:

•  Network Management.  Our customers in the United States and Canada use our clearinghouse to centrally process changes to essential network elements that are used to route telephone calls. In the United States, as of January 1, 2009, we are paid on an annual, fixed-fee basis. In Canada, we are paid on a per-transaction

4

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.

NeuStar Next Generation Messaging Services

Mobile Instant Messaging.  We provide scalable solutions to mobile network operators across Europe and Asia, which allow them to manage instant messaging, or IM, services provided by Internet service providers and to create their own branded IM services. We are typically paid a monthly fee on a per-active user basis.

Operations

Sales Force and Marketing

As of December 31, 2009, our sales and marketing organization consisted of approximately 283 people who work together to 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, and develop a clear and consistent corporate image.

We have an experienced sales and marketing staff who offer extensive knowledge in the management of telephone numbers and domain name systems, number portability and IP clearinghouse services. We believe we have close relations with our customers, and we understand 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

We strive to provide world-class customer service, and we provide customer support 24 hours a day, 7 days a week. Customer support personnel are responsible for the end-to-end ownership of all customer inquiries, provisioning and trouble requests. Our staff works closely with our customers to ensure 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 these individuals is measured by customer satisfaction surveys and through stringent measurements of key performance indicators.

Operational Capabilities

We operate our services through our state-of-the-art data centers and remotely hosted computer hardware that is currently located in third-party facilities throughout the world. Our data centers, including third-party facilities that we use, 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. In general, we subscribe to the highest level of service and responsiveness available from each third party vendor that we use. Further, to protect the integrity of our systems, the major components of our networks are generally designed to eliminate any single point of failure.

We have consistently met and frequently exceeded our contractual service level requirements and, for some of our services, our performance results are monitored internally and subjected to independent audits on a regular basis.

Research and Development

We maintain a research and development group, the principle functions of which are to develop new services and improvements to existing services, oversee quality control processes and perform application testing. Our processes surrounding the development of new services and improvement to existing services focus on the

5

challenges communicated to us by our customers related to the management of an expanding array of technologies and end-user services across a growing number of CSPs and enterprises. We employ industry experts in areas of technology that we believe are key to solving these problems. Our quality control and application testing processes focus predominantly on highly technical issues related to the performance of our technology platforms, which are identified through both internal and external feedback mechanisms, and continuous testing of our applications and system platforms to ensure uptime commensurate to service level standards we have committed to our customers. As of December 31, 2009, we had approximately 84 employees dedicated to research and development, which consists of software engineers, project managers and documentation specialists. We expense our research and development costs as they are incurred. Our research and development expense was $27.4 million, $27.5 million and $16.2 million for the years ended December 31, 2007, 2008 and 2009, respectively.

Customers

We serve traditional providers of communications, including local exchange carriers, such as Verizon Communications Inc. and AT&T Inc.; competitive local exchange carriers, such as XO Holdings, Inc. and Level 3 Communications, Inc.; wireless service providers, such as Verizon Wireless Inc., and long distance carriers. We also serve emerging CSPs, including Comcast Corporation, Cox Communications, Inc. and Cbeyond, Inc., and emerging providers of VoIP services, such as Vonage Holdings Corp.

In addition to serving traditional 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. For example, customers for our managed DNS services include a wide range of both large and small enterprises, including registry operators, such as the Canadian Internet Registration Authority, and e-commerce companies. All Internet service providers rely on our Internet registry services 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, Inc. 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 U.S. 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. Mobile network operators throughout Europe and Asia, including several country operators affiliated with Vodafone Group Plc, rely on our instant messaging solutions to provide mobile instant messaging to their end users.

Our customers include over 10,600 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 2009. The amount of our revenue derived from customers inside the United States was $387.4 million, $434.0 million and $431.2 million for the years ended December 31, 2007, 2008 and 2009, respectively. The amount of our revenue derived from customers outside the United States was $41.8 million, $54.8 million and $49.2 million for the years ended December 31, 2007, 2008 and 2009, respectively. The amount of our revenue derived under our contracts with North American Portability Management LLC, or NAPM, an industry group that represents all telecommunications service providers in the United States, was $301.8 million, $331.8 million and $306.1 million for the years ended December 31, 2007, 2008 and 2009, respectively.

We have two business segments, Clearinghouse and Next Generation Messaging, or NGM. For further discussion of the operating results of our segments, including revenue, income (loss) from operations, total assets, goodwill, and intangible assets, as well as information concerning our international operations, see Note 17 to our Consolidated Financial Statements in Item 8.

Competition

Our services most frequently compete against the 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

6

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, International Business Machines Corporation, or IBM, Noblis, Inc., Nortel Networks Corporation, Pearson Education, Inc., Perot Systems Corporation, Telcordia Technologies, Inc. and VeriSign, Inc. We have renewed or extended the term of several of these contracts since they were first awarded to us. 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 in 2015 to provide number portability services, NAPM 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 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 with high customer satisfaction 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 VeriSign, Inc., which manages the .com and .net registries, Afilias Limited, which manages the .org and .info 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 these categories:

•  systems integrators such as Accenture Ltd, 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;

•  with respect to our Ultra Services, companies such as Akamai Technologies, Inc., Afilias Limited, F5 Networks, Inc., Keynote Systems, Inc., and Compuware Corporation, that compete with us in one or more of our Ultra Services, including internal and external managed DNS services, network monitoring and load testing;

•  with respect to mobile instant messaging, companies that develop presence and instant messaging solutions, such as Nokia Corporation and Colibria AS; and

•  with respect to order management services, companies such as Synchronoss Technologies, Inc., Telcordia Technologies, Inc., Syniverse Technologies, Inc. and Evolving Systems, Inc., which offer communications interoperability services, including inter-CSP order processing and workflow management on an outsourced basis.

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 and adversely affect our business. The market for clearinghouse services may not

7

continue to develop, and CSPs and enterprises may not continue to use clearinghouse services rather than in-house systems and purchased or internally-developed software.

Employees

As of December 31, 2009, we employed 896 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, in the United States, we provide wireline and wireless number portability, implement the allocation of pooled blocks of telephone numbers and provide network management services pursuant to seven regional contracts with NAPM. Although the FCC has plenary authority over the administration of telephone number portability, it is not a party to our contracts with NAPM. The North American Numbering Council, a federal advisory committee to which the FCC has delegated limited oversight responsibilities, reviews and oversees NAPM’s management of these contracts. See “— Regulatory Environment — Telephone Numbering.” We recognized revenue under our contracts with NAPM primarily on a per-transaction basis through December 31, 2008, and the aggregate fees for transactions processed under these contracts were determined by the total number of transactions. In January 2009, we amended our seven regional contracts with NAPM to provide for an annual fixed-fee pricing model under which the annual fixed-fee, or Base Fee, was set at $340.0 million in 2009 and is subject to an annual price escalator of 6.5% in subsequent years. The amendments also provide for a fixed credit of $40.0 million in 2009, $25.0 million in 2010 and $5.0 million 2011, which will be applied to reduce the Base Fee for the applicable year. Additional credits of up to $15.0 million annually in 2009, 2010 and 2011 may be triggered if the customers reach certain levels of aggregate telephone number inventories and adopt and implement certain Internet Protocol (IP) fields and functionality. During 2009, our customers adopted and implemented these IP fields and functionality, and earned $7.5 million of the additional credits as a result, but did not reach the levels of aggregate telephone number inventories required to earn additional credits. In the event that the volume of transactions in a given year is above or below the contractually established volume range for that year, the fixed-fee may be adjusted up or down, respectively, with any such adjustment being applied in the following year. Under both the transaction-based and fixed-fee models, our 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. Under these 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 transaction 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 NAPM continue through June 2015.

On November 3, 2005, BellSouth Corporation filed a petition seeking changes in the way our customers are billed for services provided by us under our contracts with NAPM. In response to the BellSouth petition, the FCC requested comments from interested parties. As of February 19, 2010, the FCC had not initiated a formal rulemaking process, and the BellSouth petition remains pending. In addition, after the amendment of our contracts with NAPM in September 2006, Telcordia Technologies, Inc. filed a petition with the FCC requesting an order that would require NAPM to conduct a new bidding process to appoint a provider of telephone number portability services in the United States, which Telcordia has continued to pursue in response to our amendment of these contracts in January 2009. As of February 19, 2010, the FCC had not initiated a formal rulemaking process, and the Telcordia petition remains pending. If the Telcordia petition is successful, we may lose one or more of our contracts with North American Portability LLC or lose a portion of our business in one or more geographic regions where we provide services.

8

We also provide wireline and wireless 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 NAPM 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 originally awarded by the FCC in 2003 and in July 2009, the FCC awarded us a short-term contract under which we will continue to serve as the North American Numbering Plan Administrator. The contract commenced on July 9, 2009 and has an initial term of six-months with two six-month extension options exercisable by the FCC. In January 2010, the FCC exercised the first of these two six-month extension options and extended this contract through July 8, 2010. The National Pooling Administration contract was originally awarded to us by the FCC in 2001. Under this contract, we perform the administrative functions associated with the allocation of pooled blocks of telephone numbers in the United States. The terms of this contract provide for a fixed fee associated with the administration of the pooling system. In August 2007, the FCC awarded us a new contract to continue as the National Pooling Administrator. The initial contract term was two years, commencing in August 2007, and the contract has three one-year extension options that are exercisable at the election of the FCC. In August 2009, the FCC exercised the first of the three one-year extension options to extend the contract through August 2010.

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 originally granted in May 2001. In December 2006, the ICANN awarded to us a renewal of the .biz contract through December 2012. Under the terms of the amended agreement, the .biz contract automatically renews after 2012 unless it has been determined that we have been in fundamental and material breach of certain provisions of the agreement and have failed to cure such breach. Similarly, pursuant to a contract with the U.S. Department of Commerce, we operate the .us Internet domain registry. This contract was originally awarded in October 2001. In October 2007, the government awarded to us a renewal of the .us contract for a period of three years, which may be extended by the government for two additional one-year periods. In response to a bid protest filed by one of our competitors, the Department of Commerce evaluated the procedures it followed in awarding to us the .us contract. Pending resolution of this evaluation, performance under our new .us contract was stayed, and the terms of our previous .us contract remained in effect. The evaluation was completed in August 2008 and the terms of the new .us contract were amended. The amended contract expires in August 2011, with two one-year renewal options exercisable by the Department of Commerce. The .biz and .us 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. In June 2008, the contract was amended to include a term through December 2015. 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.

9

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 of 1996 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, VoIP providers, manufacturers, state regulators, consumer groups, and telecommunications associations.

Telephone Number Portability.  The Telecommunications Act of 1996 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, NAPM, as 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 our performance as the North American Numbering Plan Administrator and the National Pooling Administrator has determined that, with respect to our performance in 2008, we “exceeded” and “more than met” our performance guidelines under each such respective review. Similar reviews of our performance in 2009 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 NAPM 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,

10

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

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

We are required to maintain confidentiality of 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 on a full-time or part-time basis, 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 serves 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

11

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.

In contemplation of 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 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 originally granted to us in May 2001, which currently runs through December 2012 and renews automatically thereafter unless it has been determined that we have been in fundamental and material breach of certain provisions of the agreement and have failed to cure such breach. Similarly, pursuant to a contract with the U.S. Department of Commerce, we operate the .us Internet domain registry. This contract was originally granted in October 2001 and was renewed in October 2007 for a period of three years, with two one-year extension periods exercisable at the option of the U.S. Department of Commerce. In response to a bid protest filed by one of our competitors, the Department of Commerce evaluated the procedures it followed in awarding to us the .us contract. Pending resolution of this evaluation, performance under our new .us contract was stayed, and the terms of our previous .us contract remained in effect. The evaluation was completed in August 2008 and the contract terms were amended. The amended contract expires in August 2011, with two one-year renewal options exercisable by the Department of Commerce. 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.

12

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, these 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. With our entry into the IM market, we have also sought to protect our technology and our ability to deliver our IM solutions to our customers through patent prosecution. In addition, we have recently expanded our patent efforts in other service offerings.

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 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 made his annual certification to that effect to the NYSE on July 22, 2009. 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 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;

13

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

ITEM 1A.   RISK FACTORS

Risks Related to Our Business

The loss of, or damage to, a data center or any other failure or interruption to our network infrastructure could materially harm our revenue and impair our ability to conduct our operations.

Because virtually all of the services we provide require communications service providers to query a copy of our continuously updated databases and directories to obtain necessary routing and other essential operational data, the integrity of our data centers, including network elements managed by third parties throughout the world, and the systems through which we deliver our services is essential to our business. Notably, our data centers and related systems are essential to the orderly operation of the U.S. telecommunications system because they enable 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. Moreover, both we and our customers rely on hardware, software and other equipment developed, supported and maintained by third-party providers. 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;

•  failure of, or defects in, the third party systems, software or equipment on which we or our customers rely to access our data centers and other systems;

•  errors in the processing of data by our system;

•  computer viruses or software defects;

•  physical or electronic break-ins, sabotage, distributed denial of service, or DDoS, attacks, intentional acts of vandalism and similar events;

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

•  power loss, natural disasters, or telecommunications failures; or

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

We may not have sufficient redundant systems or back-up facilities to allow us to receive and process data if one of the foregoing events occurs. Further, increases in the scope of services that we provide increase the complexity of our network infrastructure. As the scope of services we provide expands or changes in the future, we may be required to make significant expenditures to establish new data centers from which we may provide services. Moreover, as we add customers, expand our service offerings and increase our visibility in the market, the

14

likelihood that we will become a target of physical or electronic break-ins, sabotage, DDoS attacks, intentional acts of vandalism and similar events increases. If we cannot adequately protect the ability of our data centers and related systems to perform consistently at a high level and without interruptions, or otherwise fail to meet our customers’ expectations:

•  our reputation may be damaged, 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 penalties or damages claims, under our contracts or otherwise, including the requirement to pay substantial penalties related to service level requirements in our contracts;

•  we may be required to make significant expenditures to repair or replace equipment, third party systems or, in some cases, an entire data center, or to establish new data centers and systems from which we may provide services;

•  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, performance and business prospects.

Security breaches could result in significant liabilities, interruptions 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. Such a security or privacy breach could subject us to significant penalties as well as claims for damages under our contracts. Further, 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 harm our reputation and cause our customers to reduce their use of our services, which could harm our revenue and business prospects.

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 6% and 13% of our total revenue in 2009, represented in the aggregate approximately 64% of our total revenue in 2009. 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 June 2015. 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 considered for renewal if we fail to meet our customers’ expectations, including for performance or 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.

15

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 NAPM, we rely on other contracts to provide other 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. Further, with respect to the renewal or extension of any of our government contracts, we may be subject to bid protests from a competitor, which may require the dedication of substantial company resources, and may result in the loss of the contract. If we were unable to renew or extend any of these contracts, the number of services we are able to offer may be reduced, which would adversely affect our revenue. Further, 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. 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 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.

16

Regulatory and statutory changes that affect us or the communications industry in general may increase our costs or otherwise adversely affect our business.

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 services could change in ways that we cannot 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; and

•  After the amendment of our contracts with North American Portability Management LLC in September 2006, Telcordia Technologies, Inc. filed a petition with the FCC requesting an order that would require North American Portability Management LLC to conduct a new bidding process to appoint a provider of telephone number portability services in the United States, which Telcordia has continued to pursue in response to our amendment of these contracts in January 2009. If successful, this petition could result in the loss of one or more of our contracts with North American Portability Management LLC or otherwise frustrate our strategic plans;

•  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, 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 applications to meet changing customer needs. Our ability to take advantage of opportunities in the market may require us to invest in

17

development and incur other expenses well in advance of our ability to generate revenue from these services. We cannot guarantee that we will be able to adapt to these challenges or respond successfully or in a cost-effective way, particularly in the early stages of launching a new service. Further, we may experience delays in the development of one or more features of our solutions, which could materially reduce the potential benefits to us for providing these services. In addition, there can be no assurance that our solutions will be adopted by potential customers, or that we will be able to reach acceptable contract terms with customers to provide these services. Our failure to adapt to meet market demand in a cost-effective manner could adversely affect our ability to compete and retain customers or market share.

Our customers face implementation and support challenges in introducing IP-based services, which may slow their rate of adoption or implementation of our solutions.

Historically, communications service providers have been relatively slow to implement new, complex services such as instant messaging and other IP-based communications. For example, during 2008 and 2009, we witnessed slower than anticipated deployment of our mobile instant messaging solutions by our carrier customers. We have limited or no control over, and cannot accurately predict, the pace at which communications service providers implement these new IP-based services. Moreover, the launch of new IP-based services by communications service providers requires significant expenditures by our customers to market and drive adoption by end users. We do not control the decision over whether such expenditures will occur or the timing of such expenditures. In turn, even if CSPs attempt to drive adoption of new IP-based services, our future revenue and profits will also depend, in part, on the wide adoption of such services by end users. For instance, we may be required to expend substantial resources to support the efforts of our customers to market and drive the adoption of our mobile instant messaging services by end users. The failure of, or delay by, communications service providers to introduce and support IP-based services utilizing our solutions in a timely and effective manner, or the failure by end users to adopt such services, could have a material adverse effect on our business and operating results.

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 frequently compete against the 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, instant messaging and other communications 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 margins or loss of market share, any of which would harm our business.

Our strategic initiatives relating to mobile instant messaging may be hampered by the actions of other industry participants with strategic objectives that are different than ours, as well as those of our competitors.

Our mobile instant messaging solutions are integrated with the systems of our CSP customers and with mobile devices, and rely in part on our ability to interoperate with large Internet portals such as Yahoo! and Microsoft. Because our strategic objectives may not be aligned with those of our customers or the Internet portals, and because our customers and the Internet portals may not agree on the manner in which mobile instant messaging should operate, our ability to execute on our strategy may be hampered. As a result, revenue from our instant messaging solutions may not grow as expected and may decline. In addition, some of our mobile instant messaging solutions rely on the use of open standards. If we are unable to integrate our instant messaging solutions with systems used by

18

our customers or device manufacturers because they do not adopt open standards or otherwise, revenue from our instant messaging solutions may not grow as expected and may decline. Moreover, the proliferation of open standards and protocols could make it easier for new market entrants and existing competitors to introduce products that compete with our solutions, which could adversely affect our business and operating results.

If we were unable to protect our intellectual property rights adequately, the value of our services and solutions could be diminished.

Our success is dependent in part on obtaining, maintaining and enforcing our proprietary rights and our ability to avoid infringing on the proprietary rights of others. While we take precautionary steps to protect our technological advantages and intellectual property and rely in part on patent, trademark, trade secret and copyright laws, we cannot assure that the precautionary steps we have taken will completely protect our intellectual property rights. Because patent applications in the United States are maintained in secrecy until either the patent application is published or a patent is issued, we may not be aware of third-party patents, patent applications and other intellectual property relevant to our services and solutions that may block our use of our intellectual property or may be used by third-parties who compete with our services and solutions.

As we expand our business and introduce new services and solutions, there may be an increased risk of infringement and other intellectual property claims by third parties. From time to time, we and our customers may receive claims alleging infringement of intellectual property rights, or may become aware of certain third party patents that may relate to our services and solutions. For example, our instant messaging solutions are designed to conform to Open Mobile Alliance, or OMA, specifications and those of other standards bodies. To the extent that any individual or organization that has contributed intellectual property to OMA or other standards bodies claims that it has retained its rights relating to such intellectual property, we may be subject to claims of infringement by such individuals or organizations, some of which have greater financial resources and larger intellectual property portfolios than our own.

Additionally, some of our customer agreements require that we indemnify our customers for infringement claims resulting from their use of our intellectual property embedded in their products. Any litigation regarding patents or other intellectual property could be costly and time consuming and could divert our management and key personnel from our business operations. The complexity of the technology involved, and the number of parties holding intellectual property within the communications industry, increase the risks associated with intellectual property litigation. Moreover, the commercial success of our services and solutions may increase the risk that an infringement claim may be made against us. Royalty or licensing arrangements, if required, may not be available on terms acceptable to us, if at all. Any infringement claim successfully asserted against us or against a customer for which we have an obligation to defend could result in costly litigation, the payment of substantial damages, and an injunction that prohibits us from continuing to offer the service or solution in question, any of which could have a material adverse effect on our business, operating results and financial condition.

Our intellectual property could be misappropriated, which could force us to become involved in expensive and time-consuming litigation.

Our ability to compete and continue to provide technological innovation is substantially dependent upon internally developed technology. We rely on a combination of patent, copyright, and trade secret laws to protect our intellectual property or proprietary rights in such technology. Despite our efforts to protect our intellectual property and proprietary rights, unauthorized parties may copy or otherwise obtain and use our products, technology or trademarks. Effectively policing our intellectual property is time consuming and costly, and the steps taken by us may not prevent infringement of our intellectual property or proprietary rights in our products, technology and trademarks, particularly in foreign countries where in many instances the local laws or legal systems do not offer the same level of protection as in the United States.

19

Our failure to achieve or sustain market acceptance for our services 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 our services and solutions. 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, a competing domain name registry provider may reduce its prices for domain name registration or an ISP or a competitor may offer mobile instant messaging solutions at reduced prices or at no cost to the customer;

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

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.

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

Under our contracts with NAPM, we earn revenue for telephone number portability services on an annual, fixed-fee basis. However, in the event that the volume of transactions in a given year is above or below the contractually established volume range for that year, the fixed-fee may be adjusted up or down, respectively, with any such adjustment being applied to the following year’s invoices. In addition, under our contract with the Canadian LNP Consortium Inc., we earn revenue on a per transaction basis. As a result, if industry participants in the United States reduce their usage of our services in a particular year to levels below the established volume range for that year or if industry participants in Canada reduce their usage of our services from their current levels, our revenue and results of operations may suffer. For example, consolidation in the industry could result in a decline in transactions if the remaining CSPs decide to handle changes to their networks internally rather than use the services that we provide. Moreover, if customer churn among 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. 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 existing services or for the ancillary directory services that we expect to offer, which would harm our future revenue and growth prospects.

If we are unable to manage our costs, our profits could be adversely affected.

Historically, 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 expanded operations, as well as any future 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 costs without compromising our quality of service, or if new systems that we implement to assist in managing our operations do not produce the expected benefits, we may experience higher turnover in our customer base and our revenue and profits could be adversely affected.

20

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 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 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, and we may be required to invest significant capital and resources after acquisition to maintain or grow the businesses that we acquire. In addition, we may need to record write-downs from impairments of goodwill, intangible assets, or long-lived assets, or record adjustments to the purchase price that occur after the closing of the transaction, which could reduce our future reported earnings. If we fail to successfully integrate and support the operations of the businesses we acquire, or if anticipated revenue enhancements and cost savings are not realized from these acquired businesses, our business, results of operations and financial condition would be materially adversely affected. Further, 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.

An impairment in the carrying value of goodwill or long-lived assets could negatively impact our consolidated results of operations and net worth.

Goodwill is initially recorded at fair value and is not amortized, but is reviewed for impairment at least annually or more frequently if impairment indicators are present. In general, long-lived assets are only reviewed for impairment if impairment indicators are present. In assessing goodwill and long-lived assets for impairment, we make significant estimates and assumptions, including estimates and assumptions about market penetration, anticipated growth rates, and risk-adjusted discount rates based on our budgets, business plans, economic projections, anticipated future cash flows and industry data. Some of the estimates and assumptions used by management have a high degree of subjectivity and require significant judgment on the part of management. Changes in estimates and assumptions in the context of our impairment testing may have a material impact, and any potential impairment charges could substantially affect our financial results in the periods of such charges.

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

Our instant messaging solutions predominantly target international markets. In addition, we are pursuing, and we intend to pursue in the future, other international business opportunities. 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;

•  difficulty of enforcing contracts and collecting receivables through some foreign legal systems;

•  differences in foreign laws and regulations, including foreign tax, intellectual property, labor and contract law, as well as unexpected changes in legal and regulatory requirements;

•  differing technology standards and pace of adoption;

•  export restrictions on encryption and other technologies;

•  fluctuations in currency exchange rates and any imposition of currency exchange controls;

21

•  increased competition by local, regional, or global companies;

•  difficulties associated with managing a large organization spread throughout various countries; and

•  international privacy, data security or consumer protection-related laws and regulations.

If we continue to expand our business globally, our success 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 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. If we do not retain our senior management, or if we fail to plan adequately for the succession of such individuals, our customer relationships, results of operations and financial condition may be adversely affected.

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 services and solutions 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.

Health epidemics or other events such as wars, acts of terrorism, political unrest or other man-made or natural disasters could severely disrupt our business operations.

Adverse public health epidemics or pandemics could disrupt business and the economies of the countries in which we do business, including those in Asia. Certain regions in Asia have reported outbreaks of a highly pathogenic flu caused by the H1N1 virus. In the first half of 2003, certain countries in Asia experienced an outbreak of Severe Acute Respiratory Syndrome, or SARS, which seriously interrupted economic activities and caused the demands for goods and services to decrease in the affected regions. A recurrence of SARS or an outbreak of the H1N1 or other influenzas could result in a widespread health crisis that could adversely affect the economies and financial markets of many countries, particularly in Asia. Such events could cause a significant disruption in our operations, services, development of our services, and customer demand for our services. Such significant disruptions could have an adverse impact on our business, financial condition, results of operations and cash flows.

Risks Related to the Financial Market Conditions

The recent financial crisis could negatively affect market utilization of our existing and new services and may harm our financial results.

Our success depends on our ability to generate revenues from our existing services and our introduction of new services, extensions of existing services and geographic expansion. For some of the services we provide, the market has only recently developed, and the viability and profitability of these services is unproven. Our ability to grow our business will be compromised if we do not develop and market services that achieve broad market acceptance with our current and potential customers. If our service offerings do not gain widespread market acceptance, our financial results could suffer. The global economic disruption experienced during the second half of 2008 and

22

throughout 2009, and any continuing unfavorable changes in economic conditions, may result in lower overall spending by our current and potential customers, and adversely affect our ability to generate revenue from our existing services, introduce new services or extensions of existing services and expand geographically. If the economic downturn is prolonged, we may have difficulty in maintaining and establishing a market for our existing and new services and our financial performance may suffer.

Funds invested in auction rate securities that we hold may not be accessible in the short term, and we may be required to adjust the carrying value of these securities through an asset impairment charge.

As of December 31, 2009, we had investments in auction rate securities, or ARS, with an aggregate par value totaling approximately $37.7 million, all of which are classified as current. Our ARS are floating rate securities with long-term maturities, certain of which have underlying assets that are guaranteed by third parties, and all of which were marketed by financial institutions with auction reset dates primarily at 28 or 35 day intervals to provide short-term liquidity. Beginning in February 2008, auctions for these securities began to fail, which has decreased the short-term liquidity of these securities and caused the interest rates earned on these securities to increase. We will not be able to access these remaining funds until a future auction for these ARS is successful, we sell the securities in a secondary market, or they are redeemed by the issuer. We can make no assurance that we would be able to sell our ARS in a secondary market at a favorable price or otherwise. We have the right to require the issuer of our ARS to repurchase the ARS at par value beginning on June 30, 2010. If the credit rating of either the issuer of the ARS or the third-party insurers of the underlying investments deteriorates, we may be required to further adjust the carrying value of the ARS through a loss in current period earnings.

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. 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. However, our neutrality requirements may limit or prohibit our ability to obtain debt or equity financing by restricting the ability of certain parties from acquiring our stock or our debt, or the amount that such parties may acquire. In addition, difficulties in the global credit markets have resulted in a substantial decrease in the availability of credit. Some commercial banks are refusing to provide financing, others are imposing more onerous terms on borrowers, including higher interest rates. As a result, additional financing may not be available on terms favorable to us, or at all. Further, 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;

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

23

•  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. Recently, the stock market in general has 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.

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.

24

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

25

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

None.

ITEM 2.   PROPERTIES

Our corporate headquarters are located in Sterling, Virginia under two leases that are scheduled to expire in July and August 2010, which have two five-year renewal options. On May 2009, we extended these leases for an additional ten year period through August 31, 2020 and have four five-year renewal options. In addition, on January 20, 2010, we entered into a lease relating to our corporate headquarters in Sterling, Virginia that commences October 1, 2010 and terminates January 31, 2021, and has two five-year renewal options.

We lease facilities in Staines, United Kingdom, Haifa, Israel and Dusseldorf, Germany, to support our sales and services operations for our NGM business segment. Within the United States, we also have general office and sales facilities for our Clearinghouse business segment in North Carolina, the District of Columbia, Arizona, Kentucky, Washington and California. These domestic and international leases expire on various dates through January 2020. We believe that our existing facilities are sufficient to meet our requirements, and that new space will be available on commercially reasonable terms as we expand.

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.

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

None.

26

PART II

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

Market for Our 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 February 19, 2010, our Class A common stock was held by 218 stockholders of record. The 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, 2008
First quarter	$	30.52	$	21.33
Second quarter	$	28.74	$	21.25
Third quarter	$	25.00	$	18.68
Fourth quarter	$	20.15	$	13.24
Fiscal year ended December 31, 2009
First quarter	$	19.87	$	12.77
Second quarter	$	22.36	$	16.48
Third quarter	$	23.57	$	19.65
Fourth quarter	$	24.32	$	21.79

There is no established public trading market for our Class B common stock. As of February 19, 2010, our Class B common stock was held by 6 stockholders of record.

Dividends

We did not pay any cash dividends on our Class A or Class B common stock in 2008 or 2009 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.

Purchases of Equity Securities

The following table is a summary of our repurchases of common stock during each of the three months in the quarter ended December 31, 2009:

							Maximum Number
							(or Approximate
							Dollar Value)
					Total Number of		of Shares
					Shares Purchased as		that May Yet Be
	Total Number		Average		Part of Publicly		Purchased Under
	of Shares		Price Paid		Announced Plans or		the Plans or
Month	Purchased(1)		per Share		Programs		Programs
October 1 through October 31, 2009		—	$	—		—	$	—
November 1 through November 30, 2009		6,664		23.76		—		—
December 1 through December 31, 2009		66		22.81		—		—
Total		6,730	$	23.75		—	$	—

(1) The number of shares purchased consists of shares of common stock tendered by employees to us to satisfy the employees’ tax withholding obligations arising as a result of vesting of restricted stock grants under our stock incentive plan. We purchased these shares for their fair market value on the vesting date. None of these share purchases were part of a publicly announced program to purchase our common stock.

27

Performance Graph

The following chart shows how $100 invested in our Class A common stock on June 29, 2005, the day our Class A common stock began trading on the New York Stock Exchange, would have performed through the period ended December 31, 2009, compared with: (a) $100 invested in the Russell 2000 Index, and (b) $100 invested in the NYSE TMT Index, and Index of Technology, Media and Telecommunications companies, each over that same period. The comparison assumes reinvestment of dividends. The stock performance in the graph is included to satisfy our SEC disclosure requirements, and is not intended to forecast or to be indicative of future performance.

This Performance Graph shall not be deemed to be incorporated by reference into our SEC filings and shall not constitute soliciting material or otherwise be considered filed under the Securities Act of 1933, as amended, or the Securities Exchange Act of 1934, as amended.

	06-29-05		12-31-05		12-31-06		12-31-07		12-31-08		12-31-09
NeuStar	$	100	$	117	$	125	$	110	$	74	$	89
Russell 2000	$	100	$	105	$	123	$	119	$	78	$	97
NYSE TMT	$	100	$	103	$	126	$	140	$	83	$	105

28

ITEM 6.   SELECTED FINANCIAL DATA

The tables below present selected consolidated statements of operations data for each of the five years ended December 31, 2009 and selected consolidated balance sheet data as of December 31, 2005, 2006, 2007, 2008 and 2009. The selected consolidated statements of operations data for each of the three years ended December 31, 2007, 2008 and 2009, and the selected consolidated balance sheet data as of December 31, 2008 and 2009, 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, 2005 and 2006, and the selected consolidated balance sheet data as of December 31, 2005, 2006 and 2007, have been derived from our audited consolidated financial statements and related notes not included in this report.

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,
	2005			2006			2007			2008			2009
	(In thousands, except per share data)
Consolidated Statements of Operations Data:
Total revenue	$	242,469		$	332,957		$	429,172		$	488,845		$	480,385
Operating expense:
Cost of revenue (excluding depreciation and amortization shown separately below)		64,891			86,106			94,948			105,589			113,260
Sales and marketing		29,543			47,671			70,833			74,182			83,371
Research and development		11,883			17,639			27,381			27,527			16,160
General and administrative		28,048			34,902			48,633			58,407			55,974
Depreciation and amortization		16,025			24,016			37,731			40,582			38,040
Restructuring (recoveries) charges		(389	)		—			—			1,691			6,022
Impairment of goodwill		—			—			—			93,602			—
Impairment of long-lived assets		—			—			—			18,159			—
		150,001			210,334			279,526			419,739			312,827
Income from operations		92,468			122,623			149,646			69,106			167,558
Other (expense) income:
Interest and other expense		(2,081	)		(1,260	)		(1,147	)		(16,237	)		(6,071	)
Interest and other income		2,366			3,984			4,612			13,112			7,519
Income before income taxes		92,753			125,347			153,111			65,981			169,006
Provision for income taxes		37,251			51,353			60,776			61,687			67,865
Net income		55,502			73,994			92,335			4,294			101,141
Net income attributable to noncontrolling interests		(104	)		(95	)		—			—			—
Net income attributable NeuStar, Inc.		55,398			73,899			92,335			4,294			101,141
Dividends on and accretion of preferred stock		(4,313	)		—			—			—			—
Net income attributable to NeuStar, Inc. common stockholders	$	51,085		$	73,899		$	92,335		$	4,294		$	101,141
Net income attributable to NeuStar, Inc. common stockholders per common share:
Basic	$	1.48		$	1.02		$	1.21		$	0.06		$	1.36
Diluted	$	0.72		$	0.94		$	1.16		$	0.06		$	1.34
Weighted average common shares outstanding:
Basic		34,438			72,438			76,038			74,350			74,301
Diluted		77,047			78,340			79,300			76,107			75,465

29

	As of December 31,
	2005		2006		2007		2008		2009
	(In thousands)
Consolidated Balance Sheet Data:
Cash, cash equivalents and short-term investments	$	103,475	$	58,252	$	198,678	$	161,653	$	342,191
Working capital		113,296		53,970		210,870		164,636		316,263
Goodwill and intangible assets		54,150		257,051		240,944		134,661		127,206
Total assets		283,215		448,259		616,661		519,166		647,804
Deferred revenue and customer credits, excluding current portion		18,463		17,921		18,063		11,657		8,923
Long-term debt and capital lease obligations, excluding current portion		4,459		3,925		10,923		11,933		10,766
Total stockholders’ equity		186,267		341,146		480,535		386,653		504,437

30

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

In 2009, we maintained solid profitability and high cash generation despite uncertain and challenging economic conditions. Additionally, the January 2009 amendments to our NAPM contracts for telephone number portability services in the United States provided us with enhanced visibility and reliability for a substantial portion of our total revenue through June 2015.

During 2009, we further positioned ourselves for growth through innovation, especially in the world of Internet Protocol, or IP. For example, our amended contracts to provide telephone number portability services in the United States allow for increased use of our innovative services, and enable us to help the telecommunications industry meet its emerging needs for IP functionality. To this end, in May 2009, as contemplated by our amended contracts to provide telephone number portability services, our customers adopted and implemented certain IP fields and functionality for voice, short messaging service, or SMS, and multi-media messaging service, or MMS. In addition, we strengthened our sales and distribution capabilities in our Ultra Services, which furthers our global market reach.

We continued to experience increased demand for our telephone portability services in the United States and our internet domain name services during 2009. Our total revenue for 2009 was $480.4 million, a slight decrease of 1.7% as compared to 2008. Our revenue reflects an increase of 11.9% from services provided outside of our contracts to provide telephone number portability services in the United States. This increase was driven by increased internet traffic and increased demand for our secure, reliable and scalable Ultra Services, which grew 27.6% over 2008. However, this increase was offset by our anticipated decrease in annual revenue due to the January 2009 amended pricing terms under our contracts to provide telephone number portability services in the United States. Under these contracts, our revenue decreased 8.9% despite a growth in transaction volume of 6.1% over 2008. During 2009, the effective price per transaction was $0.74, compared to $0.86 for 2008.

In our NGM business and areas of our Clearinghouse business, we have continued to drive cost efficiencies. During 2009, we extended our NGM restructuring plan first announced in December 2008 to more appropriately allocate resources to our key mobile instant messaging initiatives. We plan to relocate some of our operations and support functions to more cost effective geographies while maintaining access to skilled labor pools.

The growing demand for our services, the recurring nature of our revenue streams and our strategic cost management efforts facilitated our profitability and strong cash flows in 2009. As a result of the increased demand for our services and our focus on cost management, our cash flows from operations for the year ended December 31, 2009 were $175.3 million. This resulted in total cash, cash equivalents and short-term investment balances of $342.2 million as of December 31, 2009.

Our Company

We provide the communications industry and enterprise customers with critical technology services that solve their addressing, interoperability and infrastructure needs. These services are used by CSPs and enterprise customers to manage a range of their technical and operating requirements, including:

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

31

•  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, depreciation and amortization, and restructuring charges.

Cost of revenue includes all direct materials, direct labor, and those indirect costs related to the generation of revenue such as indirect labor, outsourced services, materials and supplies and facilities cost. Our primary cost of revenue is related to personnel costs associated with service implementation, product maintenance, customer deployment and customer care, including salaries, stock-based compensation and other personnel-related expense. In addition, cost of revenue includes costs relating to developing modifications and enhancements of our existing technology and services, as well as royalties paid related to our U.S. Common Short Code services and registry gateway services. Cost of revenue also includes our information technology and systems department, including network costs, data center maintenance, database management, data processing costs and facilities costs.

Sales and marketing expense consists of personnel costs, such as salaries, sales commissions, travel, stock-based compensation, and other personnel-related expense; costs associated with attending and sponsoring trade shows; facilities costs; professional 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; contractor costs; 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, support services and professional services fees.

Depreciation and amortization relates to amortization of identifiable intangibles, and the depreciation of our property and equipment, including our network infrastructure and facilities related to our services.

Restructuring charges relate to the termination of certain employees and reduction in or closure of leased facilities in some of our international locations.

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, or SEC, 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 reasonable, actual results may differ from those estimates. In addition, while we have used our best estimates based on facts and circumstances available

32

to us at the time, different estimates reasonably could have been used in the current period. Changes in the accounting estimates we use are reasonably likely to occur from period to period, which may have a material impact on the presentation of our financial condition and results of operations. If actual results or events differ materially from those contemplated by us in making these estimates, our reported financial condition and results of operation could be materially affected. See Item 1A of this report, “Risk Factors,” for certain matters that may bear on our results of operations.

Revenue Recognition

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 NAPM, an industry group that represents all telecommunications service providers in the United States. In 2007 and 2008, we recognized revenue under our contracts with NAPM primarily on a per-transaction basis. The aggregate fees for transactions processed under these contracts were determined by the total number of transactions, and these fees were billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share was 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. 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.

In January 2009, we amended our seven regional contracts with NAPM under which we provide telephone number portability and other clearinghouse services to CSPs in the United States. These amendments provide for an annual fixed-fee pricing model under which the annual fixed-fee, or Base Fee, was set at $340.0 million in 2009 and is subject to an annual price escalator of 6.5% in subsequent years. The amendments also provide for a fixed credit of $40.0 million in 2009, $25.0 million in 2010 and $5.0 million in 2011, which will be applied to reduce the Base Fee for the applicable year. Additional credits of up to $15.0 million annually in 2009, 2010 and 2011 may be triggered if the customers reach certain levels of aggregate telephone number inventories and adopt and implement certain Internet Protocol, or IP, fields and functionality. To the extent any available additional credits expire unused, they will be recognized in revenue at that time. During 2009, our customers adopted and implemented the IP fields and functionality, and earned $7.5 million of the additional credits as a result. However, our customers did not reach the levels of aggregate telephone number inventories required to earn additional credits and as a result, $7.5 million of additional revenue was recognized in the fourth quarter of 2009. The amendments also enable our customers to earn credits if volume of transactions in a given year is above or below the contractually established volume range for that year. The determination of credits earned based on transaction volume is done annually at the end of the year and these credits are applied to the following year’s invoices. There were no credits earned in 2009 by our customers for transaction volumes above or below the contractually established volume range for 2009. We determine the fixed and determinable fee under the amended contracts on an annual basis and recognize such fee on a straight-line basis over twelve months. For 2009, we concluded that the fixed and determinable fee equaled $285.0 million, which represents the Base Fee of $340.0 million reduced by the $40.0 million fixed credit and $15.0 million of available additional credits. We record the fixed and determinable fee amongst addressing, interoperability and infrastructure based on the relative volume of transactions in each of these service offerings processed during the applicable period.

In 2007, pricing under our contracts with NAPM was $0.91 per transaction regardless of transaction volume. During 2008, per-transaction pricing under the contracts with NAPM was derived on a straight-line basis using an effective rate calculation formula based on annualized transaction volume between 200.0 million and 587.5 million. For annualized transaction volumes less than or equal to 200.0 million, the price per transaction was equal to a flat rate of $0.95 per transaction. For annualized volumes greater than or equal to 587.5 million, the price per transaction was equal to a flat rate of $0.75 per transaction. For the year ended December 31, 2008, the weighted average per transaction price was $0.86.

33

During 2009, the effective price per transaction was calculated by dividing the ratable portion of the fixed and determinable fee by the number of transactions during the corresponding period. For the year ended December 31, 2009, the effective price per transaction under the contracts with NAPM was $0.74.

For more information regarding how we recognize revenue for each of our service categories, please see Note 2 to our Consolidated Financial Statements in Item 8 of Part II of this report.

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.

Restructuring

In December 2008, we announced a restructuring plan for our NGM business segment, involving the termination of certain employees and reduction in or closure of leased facilities in some of our international locations. As a result, we incurred $1.2 million in severance related costs and $0.5 million in lease and facilities exit costs for the year ended December 31, 2008. In August 2009, we announced the extension of the restructuring plan to include further headcount reductions and the closure of certain facilities. We anticipate that the restructuring plan will be completed by the end of the second quarter of 2010. We recognized a charge of $4.8 million in severance and related costs and $0.2 million in lease and facility exit costs in the year ended December 31, 2009 in connection with this plan. In addition to the restructuring charges recorded in 2008 and 2009, we expect to incur additional pre-tax cash restructuring charges of approximately $2.5 million to $3.0 million, consisting primarily of employee severance and related costs of approximately $1.7 million to $2.2 million, and lease and facility exit costs of approximately $0.8 million. These restructuring costs include estimated costs for leased facilities that are no longer being used. This accrual is equal to the present value of the minimum future lease payments under our contractual lease obligations, offset by the present value of the estimated sublease income, whether or not we intend to sublease the facility. If actual market conditions are different than those we have projected, we may be required to recognize additional restructuring costs or benefits associated with these facilities.

In October 2009, we adopted a plan to relocate certain operations and support functions to Louisville, Kentucky. We estimate we will incur approximately $3.0 million to $3.5 million of employee severance and related costs through the second quarter of 2010. During the fourth quarter of 2009, we recorded restructuring charges of $1.0 million related to severance and related costs under this plan.

As of December 31, 2009, our accrued restructuring liability was $3.6 million, including $1.5 million and $2.1 million of liabilities relating to our Clearinghouse and NGM segments, respectively. As of December 31, 2009, our total accrued restructuring liability associated with severance and related costs was $1.8 million, including $0.2 million and $1.6 million of liabilities related to our Clearinghouse and NGM segments, respectively. The total minimum lease payments attributable to our vacated facilities were $1.8 million, net of anticipated sublease payments, and include $1.3 million and $0.5 million relating to our Clearinghouse and NGM segments, respectively. These lease payments will be made over the remaining lives of the relevant leases, which range from three months to four years.

Goodwill

Goodwill represents the excess purchase price paid over the fair value of tangible or identifiable intangible assets acquired and liabilities assumed in our acquisitions. In accordance with the Intangibles-Goodwill and Other Topic of the Financial Accounting Standards Board, or FASB, Accounting Standards Codification, or ASC, we test our goodwill for impairment on an annual basis, or on an interim basis if an event occurs or circumstances change that indicate an impairment may have occurred. For purposes of our annual impairment test, we have identified and assigned goodwill to two reporting units, our Clearinghouse reporting unit and our NGM reporting unit.

34

Fair value of each reporting unit is determined using both an income approach and market approach. To assist in the process of determining whether a goodwill impairment exists, we perform internal valuation analyses and consider other market information that is publicly available. We also may obtain appraisals from external advisors. Significant assumptions used in the determination of fair value include market penetration, anticipated growth rates, and risk-adjusted discount rates for the income approach, as well as the selection of comparable companies and comparable transactions for the market approach.

Our 2009 annual goodwill impairment analysis, which we performed for each of our reporting units during the fourth quarter of 2009, did not result in an impairment charge. We believe that the assumptions and estimates used to determine the estimated fair values of each of our reporting units are reasonable; however, these estimates are inherently subjective, and there are a number of factors, including factors outside of our control that could cause actual results to differ from our estimates. Changes in estimates and assumptions could have a significant impact on whether or not an impairment charge is recognized and also the magnitude of any such charge. Specifically, for our NGM reporting unit as of October 1, 2009, the annual testing date, the estimated fair value exceeded our carrying value by approximately 10%. The assumptions and estimates used by management to value the NGM reporting unit have a high degree of subjectivity due to the early stage of operations and the emerging nature of mobile instant messaging technology, and are thus more likely to change over time. In addition, because relatively few carriers control a substantial portion of the end users who will drive the success of mobile instant messaging, the activities of NGM’s largest customers could have a significant impact on these assumptions and estimates. Our assumptions and estimates regarding our NGM reporting unit could change due to further delays resulting from changes in strategy by participants in the mobile instant messaging market, lack of effective marketing efforts to promote mobile instant messaging to end users, unforeseen changes in the market or other factors.

The key assumptions used in our 2009 annual goodwill impairment test to determine the fair value of our NGM reporting unit included: (a) cash flow projections, which include growth assumptions for forecasted revenue and expenses; (b) a terminal multiple of 7.0 times based upon the expected proceeds resulting from a sale of the NGM business unit at the end of the cash flow projection period; (c) a discount rate of 35%, which was based upon the NGM business unit’s weighted cost of capital adjusted for the risks associated with the operations at the time of the annual goodwill impairment test; (d) selection of comparable companies and transactions used in the market approach; and (e) our assumptions in weighting the results of the income approach and market approach valuation techniques. A change in these assumptions would have had a significant effect on the determined fair value of our NGM reporting unit and could have resulted in an estimated fair value of our NGM reporting unit that was less than our NGM reporting unit’s carrying value. If we had performed the second step of comparing the carrying value of our NGM’s reporting unit’s assigned goodwill to the implied fair value of goodwill, using a theoretical purchase price allocation, the outcome of our analysis might have resulted in a material goodwill impairment charge.

In addition, any changes to our key assumptions about our businesses and our prospects, or changes in market conditions, could cause the fair value of one of our reporting units to fall below that of its carrying value, resulting in an impairment charge. Such a charge could have a material effect on our consolidated financial statements because of the significance of goodwill and intangible assets to our consolidated balance sheet. As of December 31, 2009, we had $96.1 million and $22.3 million, respectively, in goodwill for our Clearinghouse reporting unit and our NGM reporting unit.

In 2008, changes to our key assumptions in determining the fair value of our NGM reporting unit resulted in two goodwill impairment charges. Specifically, late in the first quarter of 2008, there were changes in the market and identified customer-related events that caused us to change certain of our assumptions underlying the financial forecast relating to NGM, most notably our assumptions about end-user adoption rates. Projections of future cash flows for the NGM business are particularly sensitive to these assumptions. As a result, when the events of the first quarter caused us to reduce our projections relating to the rate at which new end users would begin using mobile instant messaging, those changed assumptions had a dramatic impact on our financial forecast for that business and the estimated fair value of our NGM business. As a result, we recorded a $29.0 million impairment charge in the first quarter of the 2008 fiscal year.

35

In the fourth quarter of 2008, in response to lower than anticipated adoption rates and the resulting underperformance of our NGM business, as well as the manner in which the mobile data market had evolved and was evolving, we added new leadership and conducted a strategic evaluation of our NGM business. The goal of this strategic evaluation was to position NGM for future long-term success in the mobile instant messaging market. During the course of this evaluation, we conducted a thorough review of the NGM business, including our experience in the mobile instant messaging market since our acquisition of Followap Inc. in November 2006, the current state of the mobile instant messaging market and related markets, the performance of our competitors for these services and consumer demand. Following this evaluation, we decided to change the direction of our NGM business to offer enhanced end user experiences, faster deployments, and greater operator control, all of which would be delivered from a common infrastructure. Associated with this decision, we began to realign the NGM organization, and we announced a restructuring plan in December 2008 to leverage our existing operational resources to support our NGM initiatives. In addition, consistent with our new strategic direction, we began development of a new technology platform that would serve as the common infrastructure for each of our NGM customers. This repositioning of our NGM business has resulted in a delay in market penetration and delayed growth in end user adoption rates. The NGM business will require continued investment and we will continue to experience net cash outflows until that market penetration and growth occurs. The revisions to the financial forecast to reflect this new strategic direction resulted in a decline in the estimated fair value of the NGM business in 2008. As a result, we recorded an additional goodwill impairment charge of $64.6 million in the fourth quarter of 2008.

Impairment of Long-Lived Assets

Our long-lived assets primarily consist of property and equipment and intangible assets. We review long-lived assets and certain identifiable intangibles for impairment whenever events or changes in circumstances indicate the carrying amount of an asset may not be recoverable. Recoverability of assets to be held and used is measured by a comparison of the carrying amount of an asset to future undiscounted net cash flows expected to be generated by the assets. Recoverability measurement and estimation of undiscounted cash flows is done at the lowest possible level for which there are identifiable cash flows. If such assets fail the recoverability test, the impairment to be recognized is measured by the amount by which the carrying amount of assets exceeds the fair value of the assets. Assets to be disposed of are recorded at the lower of the carrying amount or fair value less costs to sell. Management must exercise judgment in determining whether an event has occurred that may impair the value of the long-lived assets. Factors that could indicate that impairment may exist include significant underperformance relative to a plan or long-term projections, significant changes in business strategy, significant negative industry or economic trends or a significant decline in our stock price or in the value of our reporting units for a sustained period of time.

During the fourth quarter of 2008, we made the determination that our strategic decision to reposition the NGM business and the resulting change in our projected results served as an indicator of impairment for long-lived assets in our NGM reporting unit. As a result, in the fourth quarter of 2008, we recorded an $18.2 million impairment charge for impairment of long-lived assets in our NGM reporting unit, the largest component of which consisted of technology and customer relationships. In August 2009, we announced the extension of the restructuring plan initiated in the fourth quarter of 2008 to include further headcount reductions and the closure of certain facilities.

Due to our extension of our NGM restructuring plan and the resulting change in our projected results, we performed a recoverability test of our long-lived assets in the NGM asset group and determined that the assets were recoverable from the undiscounted cash flows. As of December 31, 2009, we had $66.8 million and $15.9 million, respectively, in long-lived assets for our Clearinghouse reporting unit and our NGM reporting unit.

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 NAPM, 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. Beginning July 1, 2005, the RRC fee was 1% of monthly billings. On July 1, 2008, the RRC fee was reduced to 0.75%. Any accrued RRC fees in excess of uncollectible receivables are paid back to the customers annually on a pro rata basis. All other receivables related to services not covered by the RRC fees are evaluated and, if deemed not collectible, are appropriately reserved.

36

Investments

We have approximately $37.7 million par value in investments related to auction rate securities, or ARS, all of which are classified as current as of December 31, 2009. In November 2008, we accepted a settlement offer in the form of a rights offering, or ARS Rights, from the investment firm that brokered the original purchases of the ARS, which provides us with the right to sell these securities at par value to the investment firm during a period beginning on June 30, 2010. As of December 31, 2009, the ARS and ARS Rights are recorded at fair value of $37.6 million in our financial statements. Changes in the fair value of the ARS and the ARS Rights are recognized as gains or losses in our current period earnings until settlement under the rights offering.

For each of our ARS and the associated ARS Rights, we determined the fair value using discounted cash flow methods. The discounted cash flow valuation methods involved management’s judgment and assumptions regarding discount rates, coupon rates, estimated maturity for each of the ARS, and judgment regarding the selection of comparable securities. We determined the fair value of the ARS Rights using a discounted cash flow method which involves judgment and assumptions regarding the timing of cash flows under the ARS Rights, fair value of the underlying ARS and the ability of the investment firm to disburse the cash anticipated under the terms of the rights offering. Changes in our assumptions used to determine the fair value each period, particularly the ability of the investment firm to disburse the cash anticipated at the time we expect to exercise our ARS Rights in June 2010, could have a material impact on results of our operations.

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.

Our income tax provision includes U.S. federal, state, local and foreign income taxes and was based on pre-tax income or loss. In determining the annual effective income tax rate, we analyzed various factors, including our annual earnings and taxing jurisdictions in which the earnings were generated, the impact of state and local income taxes and our ability to use tax credits and net operating loss carryforwards.

We assess uncertain tax positions and recognize income tax benefits when, based on the technical merits of a tax position, we believe that if a dispute arose with the taxing authority and were taken to a court of last resort, it is more likely than not (i.e., a probability of greater than 50 percent) that the tax position would be sustained as filed. If a position is determined to be more likely than not of being sustained, the reporting enterprise should recognize the largest amount of tax benefit that is greater than 50 percent likely of being realized upon ultimate settlement with the taxing authority. Our practice is to recognize interest and penalties related to income tax matters in income tax expense.

Tax years 2005 through 2009 remain open to examination by the major taxing jurisdictions to which we are subject. The Internal Revenue Service, or IRS, has completed an examination of our federal income tax returns for the years 2005 and 2006. The audit resulted in no material adjustments.

Stock-Based Compensation

We recognize share-based compensation expense in accordance with the Compensation — Stock Compensation Topic of the FASB ASC which requires the measurement and recognition of compensation

37

expense for share-based awards based on estimated fair values on the date of grant. We estimate the fair value of each option-based award on the date of grant using the Black-Scholes option-pricing model. This option pricing model requires that we make several estimates, including the option’s expected life and the price volatility of the underlying stock.

Because share-based compensation expense is based on awards that are ultimately expected to vest, the amount of expense takes into account estimated forfeitures at the time of grant, which estimate may be revised, if necessary, in subsequent periods if actual forfeitures differ from the estimates. Changes in these estimates and assumptions can materially affect the measure of estimated fair value of our share-based compensation. See Note 15 to our Consolidated Financial Statements in Item 8 of Part II of this report for information regarding our assumptions related to share-based compensation and the amount of share-based compensation expense we incurred for the periods covered in this report. As of December 31, 2009, total unrecognized compensation expense was $28.5 million, which relates to unvested stock options, unvested restricted stock units, unvested restricted stock and unvested performance vested restricted stock units, and is expected to be recognized over a weighted-average period of 1.54 years.

We estimate the fair value of our restricted stock unit awards based on the fair value of our common stock on the date of grant. Our outstanding restricted stock unit awards are subject to service-based vesting conditions and/or performance-based vesting conditions. We recognize the estimated fair value of service-based awards, net of estimated forfeitures, as share-based expense over the vesting period on a straight-line basis. Awards with performance-based vesting conditions require the achievement of specific financial targets at the end of the specified performance period and the employee’s continued employment. We recognize the estimated fair value of performance-based awards, net of estimated forfeitures, as share-based expense over the performance period, which considers each performance period or tranche separately, based upon our determination of whether it is probable that the performance targets will be achieved. At each reporting period, we reassess the probability of achieving the performance targets and the performance period required to meet those targets. Determining whether the performance targets will be achieved involves judgment, and the estimate of stock-based compensation expense may be revised periodically based on changes in the probability of achieving the performance targets. If any performance goals are not met, no compensation cost is ultimately recognized against that goal, and, to the extent previously recognized, compensation cost is reversed. Based upon our assessment in the fourth quarter of 2008 of the probability of achieving specific financial targets related to our performance vested restricted stock units granted during 2007 and 2008, we revised our estimate of achievement from 125% of target to 50% of target. In the third quarter of 2009, we revised our estimate of achievement of the performance targets related to the performance vested restricted stock units granted during 2007 from 50% of target to 0%. The change in this assumption resulted in a reduction of approximately $2.6 million in compensation expense in the year ended 2009. Our consolidated net income for the year ended December 31, 2009 was $101.1 million and diluted earnings per share was $1.34 per share. If we had continued to use the previous estimate of achievement of 50% of the performance target related to the performance vested restricted stock units granted during 2007, our as adjusted net income would have been approximately $99.5 million and the as adjusted diluted earnings per share would have had been approximately $1.32 per share. We currently estimate achievement of 50% of target and 100% of target related to our performance vested restricted stock units granted during 2008 and 2009, respectively. Further changes in our assumptions regarding the achievement of specific financial targets could have a material effect on our consolidated financial statements.

38

Consolidated Results of Operations

Year Ended December 31, 2008 Compared to the Year Ended December 31, 2009

The following table presents an overview of our results of operations for the years ended December 31, 2008 and 2009.

	2008			2009			2008 vs. 2009
	$			$			$ Change			% Change
	(In thousands, except per share data)
Revenue:
Addressing	$	130,736		$	134,253		$	3,517			2.7	%
Interoperability		64,305			58,723			(5,582	)		(8.7	)%
Infrastructure and other		293,804			287,409			(6,395	)		(2.2	)%
Total revenue		488,845			480,385			(8,460	)		(1.7	)%
Operating expense:
Cost of revenue (excludes depreciation and amortization shown separately below)		105,589			113,260			7,671			7.3	%
Sales and marketing		74,182			83,371			9,189			12.4	%
Research and development		27,527			16,160			(11,367	)		(41.3	)%
General and administrative		58,407			55,974			(2,433	)		(4.2	)%
Depreciation and amortization		40,582			38,040			(2,542	)		(6.3	)%
Restructuring charges		1,691			6,022			4,331			256.1	%
Impairment of goodwill		93,602			—			(93,602	)		(100.0	)%
Impairment of long-lived assets		18,159			—			(18,159	)		(100.0	)%
		419,739			312,827			(106,912	)		(25.5	)%
Income from operations		69,106			167,558			98,452			142.5	%
Other (expense) income:
Interest and other expense		(16,237	)		(6,071	)		10,166			(62.6	)%
Interest and other income		13,112			7,519			(5,593	)		(42.7	)%
Income before income taxes		65,981			169,006			103,025			156.1	%
Provision for income taxes		61,687			67,865			6,178			10.0	%
Net income	$	4,294		$	101,141		$	96,847			2,255.4	%
Net income per common share:
Basic	$	0.06		$	1.36
Diluted	$	0.06		$	1.34
Weighted average common shares outstanding:
Basic		74,350			74,301
Diluted		76,107			75,465

39

Revenue

Total revenue.  Total revenue decreased $8.5 million primarily due to a decrease of $28.5 million in revenue as a result of a reduction in the effective price per transaction under our seven regional contracts in the United States with NAPM effective as of January 2009. The pricing model for the use of existing telephone number portability services under the NAPM contracts changed from a transaction-based model in effect in 2008 to an annual fixed-fee with price escalators. This decrease was partially offset by a $20.0 million increase in revenue from services provided outside of our NAPM contracts to provide telephone number portability services in the United States as a result of increased internet traffic and increased demand for our secure, reliable and scalable Ultra Services.

Addressing.  Addressing revenue increased $3.5 million due to the expanded range of DNS services, consisting of a $12.0 million increase in revenue from our Ultra Services resulting from an increase in demand from customers who rely on us to meet their increasingly complex DNS requirements and a $2.1 million increase in revenue from an increased number of domain names under management. These increases were partially offset by a decrease of $10.5 million in revenue as a result of a lower effective price per transaction under our contracts to provide telephone number portability services in the United States.

Interoperability.  Interoperability revenue decreased $5.6 million due to a decrease of $5.2 million in revenue from our Clearinghouse business segment and a decrease of $0.4 million in revenue from our NGM business segment. The decrease in our Clearinghouse revenue of $5.2 million was primarily due a decrease of $3.4 million in revenue as a result of a lower effective price per transaction under our contracts to provide telephone number portability services in the United States. In addition, revenue decreased $1.0 million from our revenue from telephone number portability services in Canada and decreased $0.9 million from our order management services. The decrease in NGM revenue of $0.4 million was driven by a decrease in the inter-carrier mobile messaging services our customers are utilizing.

Infrastructure and other.  Infrastructure and other revenue decreased $6.4 million, of which $5.2 million was attributable to our Clearinghouse business segment and $1.2 million was attributable to our NGM business segment. The decrease in our Clearinghouse revenue of $5.2 million was driven by a decrease in revenue of $14.6 million as a result of a lower effective price per transaction under our contracts to provide telephone number portability services in the United States. This decrease was partially offset by a $9.4 million increase in other revenue comprised of revenue from on-going support services for telephone number portability solutions outside of the United States and one-time functionality improvements requested by our customers. The decrease in NGM revenue of $1.2 million was due to a decrease in the intra-carrier mobile messaging services our customers are utilizing.

Expense

Cost of revenue.  Cost of revenue increased $7.7 million due to a $9.8 million increase in cost of revenue of our Clearinghouse business segment, partially offset by a $2.1 million decrease in cost of revenue of our NGM business segment. The increase in Clearinghouse cost of revenue of $9.8 million was primarily driven by an increase of $6.8 million in personnel and personnel-related expense and an increase of $1.7 million due to outsourced services. In addition, royalty expense related to U.S. Common Short Code services increased $1.0 million. The $2.1 million decrease in NGM cost of revenue was due primarily to a decrease of $1.5 million in personnel and personnel-related expense primarily as a result of headcount reductions related to our NGM restructuring.

Sales and marketing.  Sales and marketing expense increased $9.2 million. Our Clearinghouse business segment sales and marketing expense increased $18.1 million, partially offset by an $8.9 million decrease attributable to our NGM business segment. The increase in Clearinghouse sales and marketing expense of $18.1 million was primarily driven by an increase of $10.6 million in personnel and personnel-related expense and a $7.1 million increase in professional fees, both primarily related to our focus on branding and our expanded service offerings. The $8.9 million decrease in NGM sales and marketing expense was due to a decrease in personnel and personnel-related expense primarily as a result of headcount reductions related to our NGM restructuring.

Research and development.  Research and development expense decreased $11.4 million, of which $3.2 million was attributable to our Clearinghouse business segment and $8.2 million was attributable to our

40

NGM business segment. Clearinghouse research and development expense decreased primarily from reductions in personnel and personnel-related expense of $2.6 million due to decreased headcount and $0.4 million due to reductions in contractor costs. The $8.2 million decrease in NGM research and development expense was primarily attributable to a $6.8 million decrease in personnel and personnel-related expenses as a result of headcount reductions pursuant to our NGM restructuring and a decrease of $1.0 million due to a reduction in contractor costs.

General and administrative.  General and administrative expense decreased $2.4 million. Our Clearinghouse business segment general and administrative expense increased $2.8 million, offset by a $5.3 million decrease attributable to our NGM business segment. Clearinghouse general and administrative expense increased $2.8 million primarily as a result of a $1.3 million increase in personnel and personnel-related expense and $2.3 million increase in general facility costs. The $5.3 million decrease in NGM general and administrative expense was due primarily to a decrease of $2.8 million in personnel and personnel-related expense as a result of headcount reductions primarily related to our NGM restructuring and a decrease of $1.6 million in general facility costs and a decrease of $0.9 million in professional fees.

Depreciation and amortization.  Depreciation and amortization expense decreased $2.5 million, of which $0.1 million was attributable to our Clearinghouse business segment and $2.4 million was attributable to our NGM business segment. Our NGM business segment depreciation and amortization expense decreased $2.4 million due to a $4.0 million decrease in amortization as a result of a write-down in the book value of our intangible assets resulting from an impairment charge recorded in the fourth quarter of 2008. This decrease was partially offset by a $1.3 million increase in the depreciation of capital assets.

Restructuring charges.  Restructuring charges increased $4.3 million, of which $1.0 million was attributable to our Clearinghouse business segment and $3.3 million was attributable to our NGM business segment. Clearinghouse restructuring charges of $1.0 million were recorded for severance and severance-related expense attributable to a plan initiated in the fourth quarter of 2009. NGM restructuring charges increased $3.3 million primarily due to an increase of $3.6 million in severance and severance related expenses, offset by a decrease of $0.3 million in lease and facilities exit costs attributable to our NGM restructuring plan originally announced in the fourth quarter of 2008.

Impairment of goodwill.  We recorded total impairment charges of $93.6 million to write-down the value of goodwill from our NGM business segment in 2008. There was no corresponding expense for the year ended December 31, 2009.

Impairment of long-lived assets.  In the fourth quarter of 2008, we recorded an impairment charge of $18.2 million to write-down our NGM business segment intangible assets by $12.9 million and property and equipment assets by $5.3 million. There was no corresponding expense for the year ended December 31, 2009.

Interest and other expense.  Interest and other expense decreased $10.2 million primarily due to a $10.2 million decrease in other-than-temporary impairment charges and trading losses recorded for our ARS in 2008.

Interest and other income.  Interest and other income decreased $5.6 million primarily due a decrease of $8.5 million in gains on our ARS rights and a $2.7 million decrease in interest income due to lower yields on our investments as compared to the year ended December 31, 2008. These decreases were partially offset by a $4.5 million increase in realized gains on our short-term investments and the receipt of $1.2 million in payment on indemnification claims made in connection with our 2006 acquisition of Followap Inc.

Provision for income taxes.  Our annual effective tax rate decreased to 40.2% for the year ended December 31, 2009 from 93.5% for the year ended December 31, 2008 due primarily to the impact of the $93.6 million non-cash impairment charges during 2008 related to our write-down of goodwill, none of which is deductible for tax purposes. The income tax provision for the year ended December 31, 2009 increased $6.2 million as compared to the year ended December 31, 2008 due primarily to an increase in income from operations excluding the goodwill impairment charges during 2008 and gains from the reduction of reserves associated with uncertain tax positions during 2008.

41

Year Ended December 31, 2007 Compared to the Year Ended December 31, 2008

The following table presents an overview of our results of operations for the years ended December 31, 2007 and 2008.

	2007			2008			2007 vs. 2008
	$			$			$ Change			% Change
	(In thousands, except per share data)
Revenue:
Addressing	$	109,799		$	130,736		$	20,937			19.1	%
Interoperability		61,679			64,305			2,626			4.3	%
Infrastructure and other		257,694			293,804			36,110			14.0	%
Total revenue		429,172			488,845			59,673			13.9	%
Operating expense:
Cost of revenue (excludes depreciation and amortization shown separately below)		94,948			105,589			10,641			11.2	%
Sales and marketing		70,833			74,182			3,349			4.7	%
Research and development		27,381			27,527			146			0.5	%
General and administrative		48,633			58,407			9,774			20.1	%
Depreciation and amortization		37,731			40,582			2,851			7.6	%
Restructuring charges		—			1,691			1,691			100.0	%
Impairment of goodwill		—			93,602			93,602			100.0	%
Impairment of long-lived assets		—			18,159			18,159			100.0	%
		279,526			419,739			140,213			50.2	%
Income from operations		149,646			69,106			(80,540	)		(53.8	)%
Other (expense) income:
Interest and other expense		(1,147	)		(16,237	)		(15,090	)		1,315.6	%
Interest and other income		4,612			13,112			8,500			184.3	%
Income before income taxes		153,111			65,981			(87,130	)		(56.9	)%
Provision for income taxes		60,776			61,687			911			1.5	%
Net income	$	92,335		$	4,294		$	(88,041	)		(95.3	)%
Net income per common share:
Basic	$	1.21		$	0.06
Diluted	$	1.16		$	0.06
Weighted average common shares outstanding:
Basic		76,038			74,350
Diluted		79,300			76,107

Revenue

Total revenue.  Total revenue increased $59.7 million due primarily to increases in infrastructure transactions under our contracts to provide telephone number portability services in the United States, our expanded range of DNS services, and growth in the use of U.S. Common Short Codes.

Addressing.  Addressing revenue increased $20.9 million due to the expanded range of DNS services we offer and the continued increase in the use of U.S. Common Short Codes. Specifically, revenue from DNS services increased $17.4 million, consisting of a $13.0 million increase in revenue from our Ultra Services due to increased demand from customers who rely on us to manage their increasingly complex DNS requirements and a $4.4 million

42

increase in revenue due to an increased number of domain names under management. In addition, revenue from U.S. Common Short Codes increased $5.5 million due to an increased number of codes under management. These increases were offset by a decrease of $1.7 million in revenue under our contracts to provide telephone number portability services in the United States.

Interoperability.  Interoperability revenue increased $2.6 million. Our Clearinghouse business segment revenue decreased $3.6 million, offset by a $6.2 million increase attributable to our NGM business segment. Clearinghouse revenue decreased primarily due to a decrease in revenue of $2.6 million under our contracts to provide telephone number portability services in the United States due to decreased competitive churn and lower annual average price per transaction. In addition, our revenue from telephone number portability services in Canada decreased $4.8 million resulting from a return to normal use patterns in 2008 as compared to the elevated transaction levels we experienced in early 2007 in advance of the introduction of wireless number portability in Canada. These decreases were offset by a $4.4 million increase in revenue from our order management services. The increase in NGM business segment revenue of $6.2 million was driven by an increase in the number of end users utilizing our services.

Infrastructure and other.  Infrastructure and other revenue increased $36.1 million, of which $35.8 million was attributable to our Clearinghouse business segment and $0.3 million was attributable to our NGM business segment. Clearinghouse revenue increased primarily due to increased demand for our network management services, principally due 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, such as wireless technology upgrades and network optimization. In addition, infrastructure revenue from our NGM business segment increased $0.3 million, which was driven by an increase in the number of carrier customers utilizing our services.

Expense

Cost of revenue.  Cost of revenue increased $10.6 million, of which $1.9 million was attributable to our Clearinghouse business segment and $8.7 million was attributable to our NGM business segment. Clearinghouse cost of revenue increased due to an increase of $4.0 million in royalty expenses related to U.S. Common Short Code services and expense related to new deployments. This increase was offset by a reduction of $2.8 million in personnel and personnel-related expense as a result of increased operating efficiencies in support of our platforms. The $8.7 million increase in NGM cost of revenue was due primarily to an increase of $3.6 million in personnel and personnel-related expense, an increase of $2.7 million in consultants and professional fees, and $2.4 million increase in general support costs associated with additional deployments for the carrier customers utilizing our services.

Sales and marketing.  Sales and marketing expense increased $3.3 million, of which $2.1 million was attributable to our Clearinghouse business segment and $1.2 million was attributable to our NGM business segment. Clearinghouse sales and marketing expense increased $1.6 million due to personnel and personnel-related expense as a result of additions to our sales and marketing team to focus on branding, product launches, and expanded DNS service offerings. The increase in NGM sales and marketing expense was due predominantly to an increase of $0.7 million in personnel and personnel-related expense to expand our sales force for NGM services and increased sales activities for new business development opportunities.

Research and development.  Total research and development expense remained relatively flat. Research and development expense for our Clearinghouse business segment decreased $2.2 million, which was offset by a $2.3 million increase attributable to our NGM business segment. Clearinghouse research and development expense decreased $1.3 million due to reductions in personnel and personnel-related expense and decreased $0.8 million due to reductions in consultants and professional fees. The $2.3 million increase in NGM research and development expense was attributable to a $1.6 million increase in personnel and personnel-related expenses due to increased headcount and a $0.7 million increase related to consulting fees to support NGM service offerings.

General and administrative.  General and administrative expense increased $9.8 million, of which $8.8 million was attributable to our Clearinghouse business segment and $1.0 million was attributable to our NGM business segment. Clearinghouse general and administrative expense increased $4.6 million in personnel and

43

personnel-related expense due to increased headcount and $2.5 million increase in general facility costs. In addition, consulting fees to support business growth increased $1.8 million. The $1.0 million increase in NGM general and administrative expense was due primarily to personnel and personnel-related expense to increase headcount to support business growth.

Depreciation and amortization.  Depreciation and amortization expense increased $2.9 million, of which $1.7 million was attributable to our Clearinghouse business segment and $1.2 million was attributable to our NGM business segment. These increases in each of our segments were due predominantly to an increase in capital assets purchased and held during the period.

Restructuring charges.  In December 2008, we recorded restructuring charges for our NGM business segment consisting of $1.2 million in severance related costs, primarily due to a workforce reduction, and $0.5 million in lease and facilities exit costs. There was no corresponding expense for the year ended December 31, 2007.

Impairment of goodwill.  We recorded total impairment charges of $93.6 million to write down the value of goodwill from our NGM business segment in 2008. There was no corresponding expense for the year ended December 31, 2007.

Impairment of long-lived assets.  In the fourth quarter of 2008, we recorded an impairment charge of $18.2 million to write down our NGM business segment intangible assets by $12.9 million and property and equipment assets by $5.3 million. There was no corresponding expense for the year ended December 31, 2007.

Interest and other expense.  Interest and other expense for the year ended December 31, 2008 increased $15.1 million as compared to the year ended December 31, 2007 due primarily to other-than-temporary impairment charges taken on our ARS of $1.6 million and cash reserve fund investments of $2.7 million, and losses on our ARS of $9.0 million in the fourth quarter of 2008 due to the change in categorization of the ARS from available-for-sale to trading. There was no corresponding other-than-temporary impairment charges or losses in the year ended December 31, 2007.

Interest and other income.  Interest and other income for the year ended December 31, 2008 increased $8.5 million as compared to the year ended December 31, 2007 due primarily to the gain on our ARS rights offering of $9.4 million recognized in fourth quarter of 2008, offset by a decrease in interest income due to lower yields on lower average cash and short-term investment balances as compared to the year ended December 31, 2007.

Provision for income taxes.  Our annual effective tax rate increased to 93.5% for the year ended December 31, 2008 from 39.7% for the year ended December 31, 2007 due primarily to the impact of the $93.6 million non-cash impairment charges related to our write-down of goodwill, none of which is deductible for tax purposes. The income tax provision for the year ended December 31, 2008 increased $0.9 million as compared to the year ended December 31, 2007 due primarily to an increase in income from operations excluding the goodwill impairment charges in 2008.

Consolidated Results of Operations

We operate in two business segments — Clearinghouse and NGM. We have provided consolidated results of operations for our Clearinghouse business segment and our NGM business segment. For further discussion of the operating results of our Clearinghouse business segment and our NGM business segment, including revenue, income (loss) from operations, total assets, goodwill, and intangible assets, see Note 17 to the Consolidated Financial Statements in Item 8.

Liquidity and Capital Resources

Our principal source of liquidity is cash provided by operating activities. Our principal uses of cash have been to fund stock repurchases, facility expansions, capital expenditures, working capital, acquisitions and debt service requirements. We anticipate that our principal uses of cash in the future will be for working capital, capital expenditures, acquisitions, facility expansion and stock repurchases.

44

Total cash, cash equivalents and short-term investments were $342.2 million at December 31, 2009, an increase from $161.7 million at December 31, 2008. This increase was due primarily to cash provided by operating activities and the reclassification of $37.6 million of investments from long-term to short-term due to our right to sell our ARS at par value beginning on June 30, 2010 to the investment firm that brokered the original investments. We intend to exercise the ARS Rights in June 2010. Of the $342.2 million included in total cash, cash equivalents and short-term investments, $30.7 million is invested in ARS that may be settled at par value beginning June 30, 2010, and $6.9 million is related to our ARS rights.

We have a credit facility that is available for cash borrowings up to $100 million that may be used for working capital, capital expenditures, general corporate purposes and to finance acquisitions. Our credit agreement contains customary representations and warranties, affirmative and negative covenants, and events of default. Our credit agreement requires us to maintain a minimum consolidated earnings before interest, taxes, depreciation and amortization, or EBITDA, to consolidated interest charge ratio and a maximum consolidated senior funded indebtedness to consolidated EBITDA ratio. As of and for the year ended December 31, 2009, we were in compliance with these covenants. As of December 31, 2009, we had no borrowings under the credit facility and we utilized $9.0 million of the availability under the facility for outstanding letters of credit.

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.

Discussion of Cash Flows

2009 compared to 2008

Cash flows from operations

Net cash provided by operating activities for the year ended December 31, 2009 was $175.3 million, as compared to $167.6 million for the year ended December 31, 2008. This $7.7 million increase in net cash provided by operating activities was principally the result of an increase in net income of $96.8 million and an increase in net changes in operating assets and liabilities of $14.3 million. These increases were partially offset by a decrease in non-cash adjustments of $103.4 million. The increase in net changes in operating assets and liabilities of $14.3 million was primarily due to an increase of $7.7 million in our accounts payable and accrued expenses and an increase of $6.0 million in our income taxes payable. Non-cash adjustments decreased $103.4 million, primarily due to a decrease of $93.6 million in goodwill impairment charges and a decrease of $18.2 million in a long-lived assets impairment charge, both recorded in the year ended December 31, 2008. The decreases of impairment charges included non-cash adjustments were partially offset by an increase in the net gains of $5.0 million related to our short-term investments.

Cash flows from investing

Net cash used investing activities for the year ended December 31, 2009 was $10.6 million, as compared to net cash provided by investing activities of $5.9 million for the year ended December 31, 2008. This $16.5 million increase in net cash used in investing activities was principally due to a $30.6 million decrease in cash provided by short-term investment sales that was partially offset by a $13.8 million decrease in cash paid for acquisitions.

Cash flows from financing

Net cash used in financing activities was $11.1 million for the year ended December 31, 2009, as compared to net cash used in financing activities of $119.9 million for the year ended December 31, 2008. The $108.8 million decrease in net cash used in financing activities was principally the result of $124.9 million used in 2008 to repurchase our Class A common stock; there were no corresponding repurchases in 2009. This decrease in net cash used was partially offset by a $7.6 million decrease in excess tax benefits from stock-based compensation, a reduction of $4.4 million in proceeds from the exercise of stock options, and an increase of $3.9 million in principal repayments on capital lease obligations.

45

2008 compared to 2007

Cash flows from operations

Net cash provided by operating activities for the year ended December 31, 2008 was $167.6 million, as compared to $145.9 million for the year ended December 31, 2007. This $21.7 million increase in net cash provided by operating activities was principally the result of an increase in non-cash adjustments of $121.5 million, including goodwill impairment charges of $93.6 million, a long-lived assets impairment charge of $18.2 million, $12.9 million loss on investments held as of December 31, 2008, and a decrease of $12.6 million relating to excess tax benefits from stock-based compensation resulting from decreased sales by employees of stock-based awards. These non-cash increases were offset by a non-cash gain of $9.4 million related to our auction rate securities rights offering. This overall increase of $121.5 million in non-cash adjustments was offset by a decrease in net income for the corresponding periods of $88.0 million and a decrease in net changes in operating assets and liabilities of $11.7 million.

Cash flows from investing

Net cash provided by investing activities for the year ended December 31, 2008 was $5.9 million, as compared to net cash used in investing activities of $110.5 million for the year ended December 31, 2007. This $116.4 million increase in net cash provided by investing activities was principally due to a $127.5 million increase in cash provided by investments of $45.8 million from redemptions of our investment in a cash reserve fund as compared to net purchases of $81.7 million of investments in 2007, and a decrease of $1.5 million in purchases of property and equipment. This increase was offset by a $12.5 million decrease in cash paid for acquisitions during 2008.

Cash flows from financing

Net cash used in financing activities was $119.9 million for the year ended December 31, 2008, as compared to net cash provided by financing activities of $23.6 million for the year ended December 31, 2007. This $143.5 million increase in net cash used in financing activities was principally the result of $124.9 million used to repurchase our Class A common stock, a $12.6 million decrease in excess tax benefits from stock-based compensation and a reduction of $8.2 million in proceeds from the exercise of stock options.

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

Payments Due by Period

			Less Than		2-3		4-5		More Than
	Total		1 Year		Years		Years		5 Years
	(In thousands)
Capital lease obligations	$	22,806	$	11,349	$	10,582	$	875	$	—
Operating lease obligations		45,669		8,536		12,326		7,598		17,209
Total	$	68,475	$	19,885	$	22,908	$	8,473	$	17,209

Some of our commercial commitments are secured by standby letters of credit. The following is a summary of our commercial commitments secured by standby letters of credit by commitment date as of December 31, 2009 (in thousands):

			Less Than		1-3		4-5		More Than
	Total		1 Year		Years		Years		5 Years
	(In thousands)
Standby letters of credit	$	9,015	$	8,525	$	490	$	—	$	—

46

The amounts presented in the table above may not necessarily reflect our actual future cash funding requirements, because the actual timing of the future payments made may vary from the stated contractual obligation. In addition, due to the uncertainty with respect to the timing of future cash flows associated with our unrecognized tax benefits at December 31, 2009, we are unable to make reasonably reliable estimates of the period of cash settlement with the respective taxing authority. Therefore, $1.1 million of unrecognized tax benefits have been excluded from the contractual obligations table above. See Note 14 to the consolidated financial statements for a discussion on income taxes.

On January 20, 2010, we entered into a new lease relating to our corporate headquarters in Sterling, Virginia. The lease commences October 1, 2010 and terminates January 31, 2021. The amounts presented in the table above do not reflect our future lease obligations under the new lease entered into on January 20, 2010. The future lease commitments under this lease are $0.0 million, $2.1 million, $2.4 million, $2.5 million, and $2.6 million for the years ended December 31, 2010, 2011, 2012, 2013 and 2014, respectively, and $17.3 million for the year ended 2015 and thereafter.

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, 2007, 2008 and 2009.

Recent Accounting Pronouncements

See Note 2 to our Consolidated Financial Statements in Item 8 of Part II of this report for a discussion of the effects of recent accounting pronouncements.

Off-Balance Sheet Arrangements

We had no off-balance sheet arrangements as of December 31, 2008 and 2009.

ITEM 7A.   QUANTITATIVE AND QUALITATIVE DISCLOSURES ABOUT MARKET RISK

We are exposed to a variety of market risks, including changes in interest rates affecting the return on our investments and foreign currency fluctuations.

Exposure to market rate risk for changes in interest rates affects the value of our investment portfolio. We have not used derivative financial instruments to hedge against such risk in our investment portfolio. We invest in securities of highly-rated issuers and follow investment policies limiting, among other things, the amount of credit exposure to any one issuer. We seek to limit default risk by purchasing only investment-grade securities. We do not actively manage the risk of interest rate fluctuations on our short-term investments; however, our exposure to this risk is mitigated by the relatively short-term nature of these investments. Based on a hypothetical 10% adverse movement in interest rates, our interest income on our short-term investments for the year ended December 31, 2009 would have been reduced by approximately $79,000.

We have accounts on our foreign subsidiaries’ ledgers which are maintained in the respective subsidiary’s local foreign currency and remeasured into the United States dollar. As a result, we are exposed to movements in the exchange rates of various currencies against the United States dollar and against the currencies of other countries in which we sell services. As of December 31, 2009, our assets and liabilities related to non-dollar denominated currencies were primarily related to intercompany payables and receivables. We do not expect that an increase or decrease of 10% in foreign exchange rate would have a material impact on our financial position.

Because our sales and expense are primarily denominated in local currency, the impact of foreign currency fluctuations on sales and expenses has not been material, and we do not employ measures intended to manage foreign exchange rate risk.

47

ITEM 8.   FINANCIAL STATEMENTS AND SUPPLEMENTARY DATA

INDEX TO CONSOLIDATED FINANCIAL STATEMENTS

	Page
Report of Independent Registered Public Accounting Firm		49
Consolidated Balance Sheets as of December 31, 2008 and 2009		50
Consolidated Statements of Operations for the years ended December 31, 2007, 2008 and 2009		52
Consolidated Statements of Stockholders’ Equity for the years ended December 31, 2007, 2008 and 2009		53
Consolidated Statements of Cash Flows for the years ended December 31, 2007, 2008 and 2009		54
Notes to Consolidated Financial Statements		55

48

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, 2008 and 2009, and the related consolidated statements of operations, stockholders’ equity, and cash flows for each of the three years in the period ended December 31, 2009. 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. An audit includes examining, on a test basis, evidence supporting the amounts and disclosures in the financial statements. An audit also includes assessing the accounting principles used and significant estimates made by management, as well as 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, 2008 and 2009, and the consolidated results of its operations and its cash flows for each of the three years in the period ended December 31, 2009, 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, presents fairly in all material respects the information set forth therein.

We also have audited, in accordance with the standards of the Public Company Accounting Oversight Board (United States), NeuStar, Inc.’s internal control over financial reporting as of December 31, 2009, based on criteria established in Internal Control — Integrated Framework issued by the Committee of Sponsoring Organizations of the Treadway Commission and our report dated February 26, 2010 expressed an unqualified opinion thereon.

/s/  Ernst & Young LLP

McLean, Virginia

February 26, 2010

49

NEUSTAR, INC.

CONSOLIDATED BALANCE SHEETS

(In thousands, except share and per share data)

	December 31,
	2008		2009
ASSETS
Current assets:
Cash and cash equivalents	$	150,829	$	304,581
Restricted cash		496		512
Short-term investments		10,824		37,610
Accounts receivable, net of allowance for doubtful accounts of $1,209 and $1,425 respectively		71,805		64,019
Unbilled receivables		830		2,986
Notes receivable		759		—
Prepaid expenses and other current assets		8,928		11,171
Deferred costs		8,518		6,916
Income taxes receivable		4,621		—
Deferred tax assets		11,079		6,973
Total current assets		268,689		434,768
Investments, long-term		40,506		—
Property and equipment, net		64,160		73,881
Goodwill		118,067		118,417
Intangible assets, net		16,594		8,789
Deferred costs, long-term		3,333		1,731
Deferred tax assets, long-term		4,244		5,124
Other assets		3,573		5,094
Total assets	$	519,166	$	647,804

See accompanying notes.

50

NEUSTAR, INC.

CONSOLIDATED BALANCE SHEETS

(In thousands, except share and per share data)

	December 31,
	2008			2009
LIABILITIES AND STOCKHOLDERS’ EQUITY
Current liabilities:
Accounts payable	$	6,901		$	11,872
Accrued expenses		52,202			60,180
Income taxes payable		—			2,764
Deferred revenue		32,530			26,117
Notes payable		2,587			987
Capital lease obligations		7,536			10,235
Accrued restructuring reserve		1,867			2,459
Other liabilities		430			3,891
Total current liabilities		104,053			118,505
Deferred revenue, long-term		11,657			8,923
Notes payable, long-term		1,777			—
Capital lease obligations, long-term		10,156			10,766
Accrued restructuring reserve, long-term		1,589			1,111
Other liabilities, long-term		3,281			4,062
Total liabilities		132,513			143,367
Commitments and contingencies		—			—
Stockholders’ equity:
Preferred stock, $0.001 par value; 100,000,000 shares authorized; no shares issued and outstanding as of December 31, 2008 and 2009		—			—
Class A common stock, par value $0.001; 200,000,000 shares authorized; 78,925,222 and 79,425,095 shares issued and outstanding at December 31, 2008 and 2009, respectively		79			79
Class B common stock, par value $0.001; 100,000,000 shares authorized; 4,538 and 3,082 shares issued and outstanding at December 31, 2008 and 2009, respectively		—			—
Additional paid-in capital		321,528			338,109
Treasury stock, 4,949,771 and 4,967,979 shares at December 31, 2008 and 2009, respectively, at cost		(128,403	)		(128,757	)
Accumulated other comprehensive loss		(879	)		(463	)
Retained earnings		194,328			295,469
Total stockholders’ equity		386,653			504,437
Total liabilities and stockholders’ equity	$	519,166		$	647,804

See accompanying notes.

51

NEUSTAR, INC.

CONSOLIDATED STATEMENTS OF OPERATIONS

(In thousands, except per share data)

	Year Ended December 31,
	2007			2008			2009
Revenue:
Addressing	$	109,799		$	130,736		$	134,253
Interoperability		61,679			64,305			58,723
Infrastructure and other		257,694			293,804			287,409
Total revenue		429,172			488,845			480,385
Operating expense:
Cost of revenue (excluding depreciation and amortization shown separately below)		94,948			105,589			113,260
Sales and marketing		70,833			74,182			83,371
Research and development		27,381			27,527			16,160
General and administrative		48,633			58,407			55,974
Depreciation and amortization		37,731			40,582			38,040
Restructuring charges		—			1,691			6,022
Impairment of goodwill		—			93,602			—
Impairment of long-lived assets		—			18,159			—
		279,526			419,739			312,827
Income from operations		149,646			69,106			167,558
Other (expense) income:
Interest and other expense		(1,147	)		(16,237	)		(6,071	)
Interest and other income		4,612			13,112			7,519
Income before income taxes		153,111			65,981			169,006
Provision for income taxes		60,776			61,687			67,865
Net income	$	92,335		$	4,294		$	101,141
Net income per share:
Basic	$	1.21		$	0.06		$	1.36
Diluted	$	1.16		$	0.06		$	1.34
Weighted average common shares outstanding:
Basic		76,038			74,350			74,301
Diluted		79,300			76,107			75,465

See accompanying notes.

52

NEUSTAR, INC.

CONSOLIDATED STATEMENT OF STOCKHOLDERS’ EQUITY

(In thousands)

															Accumulated
	Class A				Class B					Additional					Other					Total
	Common Stock				Common Stock					Paid-in		Treasury			Comprehensive			Retained		Stockholders’
	Shares		Amount		Shares			Amount		Capital		Stock			Loss			Earnings		Equity
Balance at December 31, 2006		74,351	$	74		18		$	—	$	243,395	$	(22	)	$	—		$	97,699	$	341,146
Common stock options exercised		2,493		2		—			—		14,319		—			—			—		14,321
Stock-based compensation expense		—		—		—			—		15,265		—			—			—		15,265
Conversion of Class B common stock to Class A common stock		14		—		(14	)		—		—		—			—			—		—
Common stock issued upon vesting of phantom stock units		224		1		—			—		—		—			—			—		1
Common stock received for tax withholding		—		—		—			—		—		(3,199	)		—			—		(3,199	)
Excess tax benefit from stock option exercises		—		—		—			—		20,806		—			—			—		20,806
Net income		—		—		—			—		—		—			—			92,335		92,335
Other comprehensive income (loss)
Unrealized loss on short-term investments, net of tax of $247		—		—		—			—		—		—			(381	)		—		(381	)
Foreign currency translation adjustment, net of tax of $125		—		—		—			—		—		—			241			—		241
Comprehensive income																					92,195
Balance at December 31, 2007		77,082		77		4			—		293,785		(3,221	)		(140	)		190,034		480,535
Common stock options exercised		1,613		2		—			—		6,132		—			—			—		6,134
Stock-based compensation expense		—		—		—			—		13,373		—			—			—		13,373
Restricted stock granted (forfeited)		230		—		—			—		—		—			—			—		—
Common stock repurchase		—		—		—			—		—		(124,855	)		—			—		(124,855	)
Common stock received for tax withholding		—		—		—			—		—		(327	)		—			—		(327	)
Excess tax benefit from stock option exercises		—		—		—			—		8,238		—			—			—		8,238
Net income		—		—		—			—		—		—			—			4,294		4,294
Other comprehensive income (loss)
Unrealized gain on of tax investments, net of $237		—		—		—			—		—		—			364			—		364
Foreign currency translation adjustment, net of tax of $380		—		—		—			—		—		—			(1,103	)		—		(1,103	)
Comprehensive income		—		—		—			—		—		—			—			—		3,555
Balance at December 31, 2008		78,925		79		4			—		321,528		(128,403	)		(879	)		194,328		386,653
Common stock options exercised		344		—		—			—		1,706		—			—			—		1,706
Stock-based compensation expense		—		—		—			—		14,279		—			—			—		14,279
Conversion of Class B common stock to Class A common stock		1		—		(1	)		—		—		—			—			—		—
Restricted stock granted (forfeited)		155		—		—			—		—		—			—			—		—
Common stock received for tax withholding		—		—		—			—		—		(354	)		—			—		(354	)
Excess tax benefit from stock option exercises		—		—		—			—		596		—			—			—		596
Net income		—		—		—			—		—		—			—			101,141		101,141
Other comprehensive income (loss)
Unrealized gain on investments, net of tax of $170		—		—		—			—		—		—			141			—		141
Foreign currency translation adjustment, net of tax of $114		—		—		—			—		—		—			275			—		275
Comprehensive income		—		—		—			—		—		—			—			—		101,557
Balance at December 31, 2009		79,425	$	79		3		$	—	$	338,109	$	(128,757	)	$	(463	)	$	295,469	$	504,437

See accompanying notes.

53

NEUSTAR, INC.

CONSOLIDATED STATEMENTS OF CASH FLOWS

(In thousands)

	Year Ended December 31,
	2007			2008			2009
Operating activities:
Net income	$	92,335		$	4,294		$	101,141
Adjustments to reconcile net income to net cash provided by operating activities:
Depreciation and amortization		37,731			40,582			38,040
Stock-based compensation		15,265			13,373			14,279
Amortization of deferred financing costs		158			182			169
Excess tax benefits from stock option exercises		(20,806	)		(8,238	)		(596	)
Deferred income taxes		3,585			(3,488	)		3,248
Impairment of goodwill		—			93,602			—
Impairment of long-lived assets		—			18,159			—
Provision for doubtful accounts		2,601			2,387			3,045
Other-than-temporary loss on available-for-sale investments and loss (gain) on trading securities		—			12,905			(4,078	)
(Gain) loss on auction rate securities rights		—			(9,416	)		2,524
Changes in operating assets and liabilities, net of acquisitions:
Accounts receivable		(27,743	)		2,536			3,621
Unbilled receivables		427			(447	)		(2,156	)
Notes receivable		1,994			2,159			759
Prepaid expenses and other current assets		(59	)		877			(1,060	)
Deferred costs		(1,413	)		5			3,204
Income taxes receivable		21,699			3,618			5,217
Other assets		211			1,309			(383	)
Other liabilities		1,119			(488	)		4,242
Accounts payable and accrued expenses		7,098			2,737			10,397
Income taxes payable		3,254			(3,254	)		2,764
Accrued restructuring reserve		(368	)		1,250			114
Deferred revenue		8,782			(7,018	)		(9,147	)
Net cash provided by operating activities		145,870			167,626			175,344
Investing activities:
Purchases of property and equipment		(27,244	)		(25,780	)		(25,497	)
(Purchases) sales of investments, net		(81,666	)		45,830			15,274
Businesses acquired, net of cash acquired		(1,569	)		(14,112	)		(350	)
Net cash (used in) provided by investing activities		(110,479	)		5,938			(10,573	)
Financing activities:
Disbursement of restricted cash		(488	)		(8	)		(16	)
Principal repayments on notes payable		(3,323	)		(3,343	)		(3,377	)
Principal repayments on capital lease obligations		(4,486	)		(5,721	)		(9,657	)
Proceeds from exercise of common stock options		14,321			6,134			1,706
Excess tax benefits from stock-based compensation		20,806			8,238			596
Repurchase of restricted stock awards		(3,199	)		(327	)		(354	)
Repurchase of common stock		—			(124,855	)		—
Net cash provided by (used in) financing activities		23,631			(119,882	)		(11,102	)
Effect of foreign exchange rates on cash and cash equivalents		366			(1,483	)		83
Net increase in cash and cash equivalents		59,388			52,199			153,752
Cash and cash equivalents at beginning of year		39,242			98,630			150,829
Cash and cash equivalents at end of year	$	98,630		$	150,829		$	304,581
Supplemental cash flow information:
Cash paid for interest	$	1,056		$	1,417		$	1,413
Cash paid for income taxes	$	30,953		$	65,859		$	56,996

See accompanying notes.

54

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS

1.   DESCRIPTION OF BUSINESS AND ORGANIZATION

NeuStar, Inc. (the Company or Neustar) was incorporated as a Delaware corporation in 1998. The Company provides essential clearinghouse services to the communications industry and enterprise customers. Its customers use the databases the Company contractually maintains in its clearinghouse to obtain data required to successfully route telephone calls in North America, to exchange information with other communications service providers (CSPs) and to manage technological changes in their own networks. The Company operates the authoritative directories that manage virtually all telephone area codes and numbers, and it enables the dynamic routing of calls among thousands of competing CSPs, in the United States and Canada. All CSPs that offer telecommunications services to the public at large, or telecommunications service providers, must access the Company’s clearinghouse to properly route virtually all of their customers’ calls. The Company also provides clearinghouse services to emerging CSPs, including Internet service providers, mobile network operators, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, the Company provides domain name services, including internal and external managed DNS solutions that play a key role in directing and managing traffic on the Internet, and it also manages the authoritative directories for the .us and .biz Internet domains. The Company operates the authoritative directory for U.S. Common Short Codes, which is part of the short messaging service relied upon by the U.S. wireless industry, and provides solutions used by mobile network operators throughout Europe and Asia to enable mobile instant messaging for their end users.

The Company was founded to meet the technical and operational challenges of the communications industry when the U.S. government mandated local number portability in 1996. While the Company remains the provider of the authoritative solution that the communications industry relies upon to meet this mandate, the Company has developed a broad range of innovative services to meet an expanded range of customer needs. The Company provides critical technology services that solve the addressing, interoperability and infrastructure needs of CSPs and enterprises. These services are now used by CSPs and enterprises to manage a range of their technical and operating requirements, including:

•  Addressing.  The Company enables CSPs and enterprises to use critical, shared addressing resources, such as telephone numbers, Internet top-level 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 their networks by centrally managing certain critical data they use to route communications over their own networks.

2.   SUMMARY OF SIGNIFICANT ACCOUNTING POLICIES

Basis of Presentation and Consolidation

The consolidated financial statements include the accounts of the Company and its wholly owned subsidiaries. All material intercompany transactions and accounts have been eliminated in consolidation. The Company consolidates investments where it has a controlling financial interest. 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. The Company does not have any variable interest entities or investments accounted for under the equity method of accounting.

In connection with preparation of the consolidated financial statements and in accordance with the Subsequent Events Topic of the Financial Accounting Standards Board (FASB) Accounting Standards Codification (ASC), the Company evaluated subsequent events after the balance sheet date of December 31, 2009 through February 26, 2010, the issuance date of these consolidated financial statements.

55

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Reclassification

Certain prior period amounts have been reclassified to conform to current period presentation.

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. Significant estimates and assumptions are inherent in the analysis and the measurement of deferred tax assets; the identification and quantification of income tax liabilities due to uncertain tax positions; restructuring liabilities; valuation of investments; recoverability of intangible assets, other long-lived assets and goodwill; and the determination of the allowance for doubtful accounts. The Company bases its estimates on historical experience and assumptions that it believes are reasonable. Actual results could differ from those estimates.

Fair Value of Financial Instruments

The FASB ASC Topic 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, 2008, the Company determined the carrying amount of its long-term debt approximated its fair value because the fixed and variable interest rates of the debt approximated a market rate. The Company’s long-term debt balance as of December 31, 2009 is zero. The fair value of the Company’s cash reserve fund included in short-term investments was primarily determined using pricing models that utilized recent trades for securities in active markets, dealer quotes for those securities considered to be inactive, and assumptions surrounding contractual terms, maturity and liquidity (see Note 3). The Company determined the fair value of its auction rate securities using an average of discounted cash flow models (see Note 4). The Company has rights to sell its auction rate securities at par beginning June 30, 2010, to the investment firm that brokered the original purchases (ARS Rights). The fair value of the Company’s ARS Rights is based on the estimated discounted cash flow of the associated auction rate securities (see Note 4). As permitted under the FASB ASC Topic Financial Instruments, the Company elected fair value measurement for the auction rate securities rights.

The estimated fair values of the Company’s financial instruments are as follows (in thousands):

	December 31,
	2008				2009
	Carrying		Fair		Carrying		Fair
	Amount		Value		Amount		Value
Cash and cash equivalents	$	150,829	$	150,829	$	304,581	$	304,581
Restricted cash (current assets)	$	496	$	496	$	512	$	512
Short-term investments	$	10,824	$	10,824	$	37,610	$	37,610
Investments, long-term	$	40,506	$	40,506	$	—	$	—
Marketable securities (long-term other assets)	$	268	$	268	$	1,665	$	1,665
Deferred compensation (long-term other liabilities)	$	284	$	284	$	1,682	$	1,682
Notes payable, long-term	$	1,777	$	1,777	$	—	$	—

56

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,
	2007		2008		2009
	(In thousands)
Fixed assets acquired through capital leases	$	5,597	$	14,150	$	10,787
Fixed assets acquired through notes payable		10,049		—		—
Accounts payable incurred to purchase fixed assets		345		294		3,672

Restricted Cash

At December 31, 2008 and 2009, approximately $496,000 and $512,000, respectively, of cash was held with a local bank in the form of a bank guarantee as security for the Company’s performance under a noncancelable operating lease agreement and was classified as restricted cash on the consolidated balance sheets.

Concentrations of Credit Risk

Financial instruments that are potentially subject to a concentration of credit risk consist principally of cash, cash equivalents, investments, and accounts receivable. The Company’s cash management and investment policies are in place to restrict placement of these instruments with only 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 the North American Portability Management LLC are charged a Revenue Recovery Collection fee (See Accounts Receivable, Revenue Recovery Collection and Allowance for Doubtful Accounts).

Investments

The Company’s investments classified as available-for-sale are carried at estimated fair value, as determined by quoted market prices or other valuation methods, with unrealized gains and losses reported as a separate component of accumulated other comprehensive income. Realized gains and losses and declines in value judged to be other-than-temporary, if any, on available-for-sale securities are included in other (expense) income. The cost of available-for-sale investments sold was based on the specific identification method for the year ended December 31, 2007 and for the three months ended March 31, 2008. Because of other-than-temporary impairment charges related to short-term investments recognized in earnings subsequent to the first quarter of 2008, the cost of securities sold subsequent to March 31, 2008 is reduced by a pro-rata allocation of other-than-temporary losses previously recognized as a charge to earnings. Interest and dividends on these securities is included in interest and other income.

The Company periodically evaluates whether any declines in the fair value of its investments are other-than-temporary. This evaluation consists of a review of several factors, including but not limited to: the length of time and extent that a security has been in an unrealized loss position; the existence of an event that would impair the issuer’s future earnings potential; the near-term prospects for recovery of the market value of a security; the Company’s intent to sell an impaired security; and the probability that the Company will be required to sell the security before the market value recovers. Prior to April 1, 2009, declines in value below cost for investments which the Company had the ability and intent to hold the investment for a period of time sufficient to allow for a market recovery, were not recognized as an other-than temporary charge in earnings. Beginning April 1, 2009, if an

57

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

investment which the Company does not intend to sell prior to recovery declines in value below its amortized cost basis and it is not more likely than not that the Company will be required to sell the related security before the recovery of its amortized cost basis, the Company recognizes the difference between the present value of the cash flows expected to be collected and the amortized cost basis, or credit loss, as an other-than temporary charge in interest and other expense. The difference between the estimated fair value and the security’s amortized cost basis at the measurement date related to all other factors is reported as a separate component of accumulated other comprehensive loss.

The Company’s investments classified as trading are carried at estimated fair value with unrealized gains and losses reported in other (expense) income. At December 31, 2008 and 2009, the Company classified its auction rate securities as trading pursuant to the Investments — Debt and Equity Securities Topic of the FASB ASC, with changes in the fair value of these securities recorded in earnings (see Note 3). Interest and dividends on these securities are included in interest and other income.

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 (NAPM), 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. Beginning July 1, 2005, the RRC fee was 1% of monthly billings. On July 1, 2008, the RRC fee was reduced to 0.75%. 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 $3.3 million and $2.6 million are included in accrued expenses as of December 31, 2008 and 2009, 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 $1.2 million and $1.4 million as of December 31, 2008 and 2009, respectively. Bad debt expense amounted to $2.6 million, $2.4 million and $3.0 million for the years ended December 31, 2007, 2008 and 2009, 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 assets acquired through capital leases 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. Impairments of long-lived assets are determined in accordance with the Property, Plant and Equipment Topic of the FASB ASC.

58

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

The Company capitalizes software development and acquisition costs in accordance with the Intangibles — Goodwill and Other, Internal-Use Software Topic of the FASB ASC, which 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, 2008 and 2009, the Company capitalized costs related to internal use software of $17.0 million and $19.3 million, respectively. Amortization expense related to internal use software for the years ended December 31, 2007, 2008 and 2009 was $9.4 million, $11.1 million and $12.4 million, respectively, and is included in depreciation and amortization expense in the consolidated statements of operations.

Goodwill

Goodwill represents the excess of the purchase price over the fair value of assets acquired, as well as other definite-lived intangible assets. In accordance with the Intangibles — Goodwill and Other Topic of the FASB ASC, goodwill and indefinite-lived intangible assets are not amortized, but are reviewed for impairment at least annually and upon the occurrence of events or changes in circumstances that would reduce the fair value of such assets below their carrying amount. For purposes of the Company’s annual impairment test completed on October 1st of each year, the Company has identified and assigned goodwill to two reporting units, Clearinghouse and Next Generation Messaging (NGM).

Goodwill is tested for impairment at the reporting unit level using a two-step approach. The first step is to compare the fair value of a reporting unit’s net assets, including assigned goodwill, to the book value of its net assets, including assigned goodwill. Fair value of the reporting unit is determined using both an income and market approach. To assist in the process of determining if a goodwill impairment exists, the Company performs internal valuation analyses and considers other market information that is publicly available, and the Company may obtain valuations from external advisors. If the fair value of the reporting unit is greater than its net book value, the assigned goodwill is not considered impaired. If the fair value is less than the reporting unit’s net book value, the Company performs a second step to measure the amount of the impairment, if any. The second step is to compare the book value of the reporting unit’s assigned goodwill to the implied fair value of the reporting unit’s goodwill, using a theoretical purchase price allocation. If the carrying value of goodwill exceeds the implied fair value, an impairment has occurred and the Company is required to record a write-down of the carrying value and charge the impairment as an operating expense in the period the determination is made. In 2008, the Company recorded goodwill impairment charges of $93.6 million related to the NGM reporting unit (see Note 7). There was no impairment charge related to the Company’s Clearinghouse reporting unit in the year ended December 31, 2008. There were no impairment charges recognized during the years ended December 31, 2007 and 2009.

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 and are periodically reviewed for impairment. In 2008, the Company recorded an intangible asset impairment of $12.9 million related to the NGM reporting unit (see Note 7). There were no impairment charges recognized during the years ended December 31, 2007 and 2009.

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

	Years		Method
Acquired technologies		3-5	Straight-line
Customer lists and relationships		3-7	Various
Trade name		3	Straight-line

59

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Amortization expense related to identifiable intangible assets is included in depreciation and amortization expense in the consolidated statements of operations.

Impairment of Long-Lived Assets

In accordance with Property, Plant and Equipment Topic of the FASB ASC, the Company reviews long-lived assets and certain identifiable intangible assets for impairment whenever events or changes in circumstances indicate the carrying amount of an asset may not be recoverable. Recoverability of assets to be held and used is measured by a comparison of the carrying amount of the assets to future undiscounted net cash flows expected to be generated by the assets. Recoverability measurement and estimating of undiscounted cash flows is done at the lowest possible level for which there are identifiable cash flows. If the carrying amount of the assets exceeds the future undiscounted cash flows expected to be generated by those assets, such assets fail the recoverability test and an impairment would be recognized, measured as the amount by which the carrying amount of the assets exceeds its fair value. Assets to be disposed of are recorded at the lower of the carrying amount or fair value less costs to sell.

In connection with the interim and annual goodwill impairment tests of the NGM reporting unit in the first and fourth quarters of 2008, the Company performed a recoverability test of the long-lived assets of the NGM reporting unit. For purposes of recognition and measurement of an impairment, the Company determined that the lowest level of identifiable cash flows is at the NGM reporting unit level. This asset grouping at the NGM reporting unit level was determined as the NGM long-lived assets do not have identifiable cash flows that are independent of the cash flows of other NGM assets and liabilities.

The Company concluded that the future undiscounted cash flows of the NGM asset group exceeded its carrying amount as of March 31, 2008 and no asset impairment charge was recognized at such time. The Company determined that the undiscounted cash flows of the NGM asset group were below the carrying amount as of October 1, 2008, and an impairment of long-lived assets charge of $18.2 million was recognized during the fourth quarter of 2008 in the consolidated statements of operations (see Notes 7 and 8).

In August 2009, the Company announced the extension of the restructuring plan initiated in the fourth quarter of 2008 to include further headcount reductions and the closure of certain facilities. Due to the Company’s extension of its NGM restructuring plan and the resulting change in the projected results, the Company performed a recoverability test of its long-lived assets, including intangible assets, in the NGM asset group and determined that the assets were recoverable from the undiscounted cash flows.

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 Revenue Recognition Topic of the FASB ASC. Pursuant to various private commercial and government contracts, the Company provides addressing, interoperability and infrastructure services.

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 (NAPM), an industry group that represents all telecommunications service providers in the United States. In 2007 and 2008, the Company recognized revenue under its contracts with NAPM primarily on a per-transaction basis. The aggregate fees for transactions processed under these contracts were determined by the total number of transactions, and these fees were billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share was based on each respective telecommunications service provider’s share of the aggregate end-user services revenues of all

60

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

U.S. telecommunications service providers, as determined by the Federal Communications Commission. In January 2009, the Company amended its seven regional contracts with NAPM under which it provides telephone portability and other clearinghouse services to CSPs in the United States. These amendments provide for an annual fixed-fee pricing model under which the annual fixed-fee (Base Fee) was set at $340.0 million in 2009 and is subject to an annual price escalator of 6.5% in subsequent years. The amendments also provide for a fixed credit of $40.0 million in 2009, $25.0 million in 2010 and $5.0 million in 2011, which will be applied to reduce the Base Fee for the applicable year. Additional credits of up to $15.0 million annually in 2009, 2010 and 2011 may be earned if the customer reaches certain levels of aggregate telephone number inventories and adopts and implements certain Internet Protocol (IP) fields and functionality. To the extent any available additional credits expire unused, they will be recognized in revenue at that time. During 2009, the Company’s customers adopted and implemented the IP fields and functionality, and earned $7.5 million of the additional credits as a result. However, the customers did not reach the levels of aggregate telephone number inventories required to earn additional credits and as a result, $7.5 million of additional revenue was recognized in the fourth quarter of 2009. The amendments also enable the Company’s customers to earn credits if the volume of transactions in a given year is above or below the contractually established volume range for that year. The determination of credits earned based on transaction volume is done annually at the end of the year and these credits are applied to the following year’s invoices. There were no credits earned in 2009 by the Company’s customers for transaction volumes above or below the contractually established volume range for 2009. The Company determines the fixed and determinable fee under the amended contracts on an annual basis and recognizes such fee on a straight-line basis over twelve months. For 2009, the Company concluded that the fixed and determinable fee equaled $285.0 million, which represents the Base Fee of $340.0 million reduced by the $40.0 million fixed credit and $15.0 million of available additional credits. The Company records the fixed and determinable fee amongst addressing, interoperability and infrastructure based on the relative volume of transactions in each of these service offerings processed during the applicable period.

The amount of revenue derived under the Company’s contracts with NAPM was approximately $301.8 million, $331.8 million and $306.1 million for the years ended December 31, 2007, 2008 and 2009, respectively.

Under the Company’s contracts with NAPM, the Company also bills a Revenue Recovery Collections fee equal to 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.

During 2007, per-transaction pricing under the contracts with NAPM was $0.91 per transaction regardless of transaction volume. During 2008, per-transaction pricing was derived on a straight-line basis using an effective rate calculation formula based on annualized transaction volume between 200 million and 587.5 million. For annualized transaction volumes less than or equal to 200 million, the price per-transaction was equal to a flat rate of $0.95 per transaction. For annualized volumes greater than or equal to 587.5 million, the price per transaction was equal to a flat rate of $0.75 per transaction. For the year ended December 31, 2008, the average price per transaction was $0.86.

For the year ended December 31, 2009, the effective price per transaction under the contracts with NAPM was $0.74. The effective price per transaction is calculated by dividing the straight-line portion of the fixed and determinable fee by the number of transactions during the corresponding period.

Addressing

The Company’s addressing services include telephone number administration, implementing the allocation of pooled blocks of telephone numbers, directory services for Internet domain names and U.S. Common Short Codes, and internal and external managed domain name services. 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

61

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

straight-line basis as services are provided. Under the Company’s contract to serve as the National Pooling Administrator, the Company earns a fixed price associated with administration of the pooling system. The Company recognizes revenue for this contract on a straight-line basis over the term of the contract. In the event the Company estimates losses on its fixed price contracts, the Company recognizes these losses in the period in which a loss becomes apparent.

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 its long-term contracts with NAPM. In 2007 and 2008, the Company recognized revenue on a per-transaction fee basis as the services were performed. As discussed above under the heading “Revenue Recognition — Significant Contracts,” beginning January 1, 2009, the Company determines the fixed and determinable fee on an annual basis and recognizes such fee on a straight-line basis over twelve months. 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 term of the related customer contracts.

The Company generates revenue through internal and external managed domain name services. The Company’s revenue consists of customer set-up fees, monthly recurring fees and per-transaction fees for transactions in excess of pre-established monthly minimums under contracts with terms ranging from one to three years. Customer set-up fees are not considered a separate deliverable and are deferred and recognized on a straight-line basis over the term of the contract. Under the Company’s contracts to provide its managed domain name services, customers have contractually established monthly transaction volumes for which they are charged a recurring monthly fee. Transactions processed in excess of the pre-established monthly volume are billed at a contractual per-transaction rate. Each month, the Company recognizes the recurring monthly fee and usage in excess of the established monthly volume on a per-transaction basis as services are provided. The Company generates revenue from its U.S. 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 providing telephone number portability services under its long-term contracts with NAPM. In 2007 and 2008, the Company recognized revenue on a per-transaction fee basis as the services were performed. As discussed above under the heading “Revenue Recognition — Significant Contracts,” beginning January 1, 2009, the Company determines the fixed and determinable fee on an annual basis and recognizes such fee on a straight-line basis over twelve months.

Under its long-term contract with 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 for these services 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. The Company generates revenue from its inter-carrier mobile instant messaging services under contracts with mobile operators that range from one to three years. These contracts consist of user subscription fees based on the number of subscribers that use mobile instant messaging services, as well as fees for set-up and implementation. The Company recognizes user subscription fee revenue on a monthly basis over the term of the contract after completion of customer set-up and implementation. Customer set-up and implementation is not considered a separate deliverable; accordingly, the fees for these services are deferred and recognized as revenue on a straight-line basis over the remaining term of the contract following delivery of the set-up and implementation services.

62

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Infrastructure and Other

The Company’s infrastructure services consist primarily of network management and connection services. The Company generates revenue from network management services under its long-term contracts with NAPM. In 2007 and 2008, the Company recognized revenue on a per-transaction fee basis as the services were performed. As discussed above under the heading “Revenue Recognition - Significant Contracts,” beginning January 1, 2009, the Company determines the fixed and determinable fee on an annual basis and recognizes such fee on a straight-line basis over twelve months. In addition, the Company generates revenue from connection fees and system enhancements under its contracts with NAPM. The Company recognizes 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. The Company generates revenue from its intra-carrier mobile instant messaging services under contracts with mobile operators that range from one to three years. These contracts consist of license fees based on the number of subscribers that use mobile instant messaging services, as well as fees for set-up and implementation. The Company recognizes license fee revenue on a straight-line basis over the term of the contract after completion of customer set-up and implementation. Customer set-up and implementation is not considered a separate deliverable; accordingly, the fees for these services are deferred and recognized as revenue on a straight-line basis over the remaining term of the contract following delivery of the set-up and implementation services.

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 have not been met, triggering the requirement to pay a penalty, 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 generation of revenue such as indirect labor, materials and supplies and facilities cost. The Company’s primary cost of revenue is related to personnel costs associated with service implementation, product maintenance, customer deployment and customer care, including salaries, stock-based compensation and other personnel-related expense. In addition, cost of revenue includes costs relating to maintaining the Company’s existing technology and services, as well as royalties paid related to the Company’s U.S. Common Short Code services. Cost of revenue also includes the costs incurred by the Company’s information technology and systems department, including network costs, data center maintenance, database management, data processing costs, and facilities costs.

Deferred costs represent direct labor related to professional services incurred for the setup and implementation of contracts. These costs are recognized in cost of revenue on a straight-line basis over the contract term. Deferred costs also include royalties paid related to the Company’s U.S. Common Short Code services, which are recognized in cost of revenue on a straight-line basis over the contract term. Deferred costs are classified as such on the consolidated balance sheets.

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.

63

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Advertising

The Company expenses advertising as incurred. Advertising expense was approximately $2.7 million, $3.4 million and $5.3 million for the years ended December 31, 2007, 2008 and 2009, respectively.

Stock-Based Compensation

The Company accounts for its stock-based compensation plans under the recognition and measurement provisions of the Compensation — Stock Compensation Topic of the FASB ASC. The Company estimates the value of stock-based awards on the date of grant using the Black-Scholes option-pricing models. For stock-based awards subject to graded vesting, the Company has utilized the “straight-line” method for allocating compensation cost by period.

The Company presents benefits of tax deductions in excess of the compensation cost recognized (excess tax benefits) as a financing cash inflow with a corresponding operating cash outflow. For the years ended December 31, 2007, 2008 and 2009, the Company included $20.8 million, $8.2 million and $0.6 million, respectively, of excess tax benefits as a financing cash inflow with a corresponding operating cash outflow.

Basic and Diluted Net Income per Common Share

In 2009, the Company adopted and retrospectively applied the FASB standard which updated the Earnings Per Share Topic of the FASB ASC for determining whether instruments granted in share-based payment transactions should be included in the computation of earnings per share. The authoritative literature effective in 2009 clarifies that unvested share-based payment awards that contain non-forfeitable rights to dividends or dividend equivalents (whether paid or unpaid) are participating securities that should be included in the computation of earnings per share under the two-class method. The Company’s restricted stock awards are considered to be participating securities because they contain non-forfeitable rights to cash dividends, if declared and paid. In lieu of presenting earnings per share pursuant to the two-class method, the Company has included shares of unvested restricted stock awards in the computation of basic net income per common share as the resulting earnings per share would be the same under both methods. Diluted net income per common share for the year ended December 31, 2007 decreased from $1.17 to $1.16 as a result of the adoption and retrospective application of the provisions effective in 2009. Diluted net income per common share for the year ended December 31, 2008 was not materially affected.

Basic net income per common share is computed by dividing net income by the weighted-average number of common shares and participating securities outstanding during the period. Unvested restricted stock units and performance vested restricted stock units (PVRSU) are excluded from the computation of basic net income per common share because the underlying shares have not yet been earned by the shareholder and are not participating securities. Shares underlying stock options are also excluded because they are not considered outstanding shares. Diluted net income per common share assumes dilution and is computed based on the weighted-average number of common shares outstanding after consideration of the dilutive effect of stock options, unvested restricted stock units and PVRSU. The effect of dilutive securities is computed using the treasury stock method and average market prices during the period. Dilutive securities with performance conditions are excluded from the computation until the performance conditions are met.

Income Taxes

The Company accounts for income taxes in accordance with the Income Taxes Topic of FASB ASC. Deferred tax assets and liabilities are determined based on temporary differences between the financial reporting bases and the tax bases of assets and liabilities. Deferred tax assets are also recognized for tax net operating loss carryforwards. 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 be reversed or utilized. Valuation allowances are provided to reduce such deferred tax assets to amounts more likely than not to be ultimately realized.

64

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Income tax provision includes U.S. federal, state, local and foreign income taxes and is based on pre-tax income or loss. In determining the annual effective income tax rate, the Company analyzed various factors, including the Company’s annual earnings and taxing jurisdictions in which the earnings were generated, the impact of state and local income taxes and the ability of the Company to use tax credits and net operating loss carryforwards.

The Company assesses uncertain tax positions in accordance with income tax accounting standards. Under these standards, income tax benefits should be recognized when, based on the technical merits of a tax position, the Company believes that if a dispute arose with the taxing authority and were taken to a court of last resort, it is more likely than not (i.e., a probability of greater than 50 percent) that the tax position would be sustained as filed. If a position is determined to be more likely than not of being sustained, the reporting enterprise should recognize the largest amount of tax benefit that is greater than 50 percent likely of being realized upon ultimate settlement with the taxing authority. The Company’s practice is to recognize interest and penalties related to income tax matters in income tax expense.

Foreign Currency

Assets and liabilities of consolidated foreign subsidiaries, whose functional currency is the local currency, are translated to U.S. dollars at fiscal year end exchange rates. Revenue and expense items are translated to U.S. dollars at the average rates of exchange prevailing during the fiscal year. The adjustment resulting from translating the financial statements of such foreign subsidiaries to U.S. dollars is reflected as a foreign currency translation adjustment and reported as a component of accumulated other comprehensive loss in the consolidated statements of stockholders’ equity.

Transactions denominated in currencies other than the functional currency are recorded based on exchange rates at the time such transactions arise. Subsequent changes in exchange rates result in transaction gains or losses, which are reflected within interest and other expense in the consolidated statements of operations.

Comprehensive Income

Comprehensive income is comprised of net earnings and other comprehensive income, which includes certain changes in equity that are excluded from income. The Company includes unrealized holding gains and losses on available-for-sale securities, if any, and foreign currency translation adjustments in other comprehensive income (loss) in the consolidated statements of stockholders’ equity. Comprehensive income was approximately $92.2 million, $3.6 million and $101.6 million for the years ended December 31, 2007, 2008 and 2009, respectively.

Recent Accounting Pronouncements

In April 2009, the FASB issued guidance for the initial recognition and measurement, subsequent measurement and accounting, and disclosures for assets and liabilities arising from contingencies in business combinations. This new guidance, included in FASB ASC Topic Business Combinations, eliminates the distinction between contractual and non-contractual contingencies, including the initial recognition and measurement criteria for acquired contingencies, and is effective for contingent assets and contingent liabilities acquired in business combinations for which the acquisition date is on or after the first annual reporting period beginning on or after December 15, 2008. The Company expects the new guidance will have an impact on its consolidated financial statements, but the nature and magnitude of the specific effects will depend upon the nature, term and size of any contingencies acquired subsequent to January 1, 2009.

In June 2009, the FASB issued new guidance to (i) require an entity to perform an analysis to determine whether an entity’s variable interest or interests give it a controlling financial interest in a variable interest entity; (ii) require ongoing reassessments of whether an entity is the primary beneficiary of a variable interest entity and

65

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

eliminate the quantitative approach previously required for determining the primary beneficiary of a variable interest entity; (iii) amend certain guidance for determining whether an entity is a variable interest entity; and (iv) require enhanced disclosure that will provide users of financial statements with more transparent information about an entity’s involvement in a variable interest entity. The Company is required to adopt the new guidance for its annual and interim periods beginning after November 15, 2009. The Company does not expect the adoption to have a material impact on its consolidated financial statements.

In September 2009, the FASB ratified Accounting Standard Update 2009-13, Revenue Recognition Topic 605 — Multiple-Deliverable Revenue Arrangements (ASU 2009-13). When vendor specific objective evidence or third party evidence for deliverables in an arrangement cannot be determined, the Company will be required to develop a best estimate of the selling price to separate deliverables and allocate arrangement consideration using the relative selling price method. ASU 2009-13 is effective for revenue arrangements entered into or materially modified beginning January 1, 2011, with earlier application permitted. The Company is currently evaluating the impact of adoption on its consolidated financial statements.

3.   INVESTMENTS

Cash Reserve Fund

In December 2007, the Company was advised that its investment in a cash reserve fund, classified as an available-for-sale investment, would be closed to new investments and subject to scheduled redemptions as determined by the cash reserve fund. During 2008, the Company evaluated and determined that any unrealized losses on the cash reserve fund represented an other-than-temporary impairment and recorded a $2.7 million charge to earnings. At December 31, 2008, the amortized cost and estimated fair value of the Company’s investments in the cash reserve fund was $10.8 million, respectively. During the year ended December 31, 2008, $35.4 million was redeemed from this cash reserve fund and the Company recognized losses from redemptions of $0.9 million.

During the year ended December 31, 2009, $11.3 million was redeemed from this cash reserve fund and the Company recognized gains from redemptions of $0.5 million. The Company’s investment in this fund was completely liquidated as of December 31, 2009.

Auction Rate Securities and Rights

As of December 31, 2009, the Company held investments with an original par value of $37.7 million and an estimated fair value of $30.7 million that consist of auction rate securities (ARS) whose underlying assets are student loans, the majority of which are guaranteed by the federal government. ARS are intended to provide liquidity via an auction process that resets the applicable interest rate approximately every 30 days and investors can either roll over their holdings or sell the ARS at par. As a result of negative conditions in the global credit markets, auctions for the $30.7 million investment in these securities have failed to settle and may continue to fail to settle on their respective settlement dates. Consequently, the investments are not currently liquid and the Company will not be able to access these funds until a future auction of these investments is successful, issuers redeem the securities or a buyer is found outside of the auction process.

In November 2008, the Company accepted a settlement offer in the form of a rights offering (ARS Rights) from the investment firm that brokered the original purchases of the ARS, which provides the Company with rights to sell these securities at par value to the investment firm during a two year period beginning June 30, 2010. The Company elected to measure the ARS Rights at their fair value pursuant to the Financial Instruments Topic of the FASB ASC and classify the associated ARS as trading securities. The Company believes the changes in fair value of ARS will substantially offset changes in the fair value of the ARS Rights, subject to the continued expected performance by the investment firm of its obligations under the ARS Rights offering. The Company intends to exercise its rights to sell these securities to the investment firm on June 30, 2010. At December 31, 2008, the estimated fair value of these ARS Rights of $9.4 million was classified in long-term investments in the Company’s consolidated balance sheets.

66

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

At December 31, 2009, the estimated fair value of the ARS Rights of $6.9 million is classified in short-term investments in the Company’s consolidated balance sheets. During the years ended December 31, 2008 and 2009, the Company recorded a gain of $9.4 million and a loss of $2.5 million related to the change in estimated fair value of the ARS Rights.

During the years ended December 31, 2008 and 2009, the Company recorded losses of $10.6 million and gains of $2.4 million for changes in the estimated fair value of the ARS. Under the terms of the ARS Rights, if the investment firm is successful in selling the ARS prior to June 30, 2010, the investment firm is obligated to pay the Company par value for the related ARS sold. During the year ended December 31, 2009, the investment firm sold certain ARS with an original par value of $4.0 million; the Company received this amount in cash from the investment firm and recognized realized gains of $1.2 million.

4.   FAIR VALUE MEASUREMENTS

The Company adopted the Fair Value Measurements and Disclosures Topic of FASB ASC on January 1, 2008, with respect to its financial assets and liabilities, and on January 1, 2009, with respect to its nonfinancial assets and nonfinancial liabilities that are recognized and disclosed at fair value on a nonrecurring basis. Fair value is the price that would be received to sell an asset or paid to transfer a liability in an orderly transaction between market participants at the measurement date. The Fair Value Measurements and Disclosure Topic of FASB ASC establishes a fair value hierarchy that prioritizes the inputs to valuation techniques used to measure fair value and requires that assets and liabilities carried at fair value be classified and disclosed in one of the following three categories:

•  Level 1. Observable inputs, such as quoted prices in active markets;

•  Level 2. Inputs, other than the quoted prices in active markets, that are observable either directly or indirectly; and

•  Level 3. Unobservable inputs in which there is little or no market data, which require the reporting entity to develop its own assumptions.

The Company evaluates assets and liabilities subject to fair value measurements on a recurring and non-recurring basis to determine the appropriate level to classify them for each reporting period. This determination requires significant judgments to be made.

Assets and Liabilities Measured at Fair Value on a Recurring Basis

The following table sets forth the Company’s financial and non-financial assets and liabilities that are measured at fair value on a recurring basis as of December 31, 2008 and 2009, by level within the fair value hierarchy (in thousands):

	December 31, 2008
	Level 1		Level 2		Level 3		Total
Cash reserve fund — available-for-sale securities (short-term investments)	$	—	$	—	$	10,824	$	10,824
Auction rate securities — trading securities (long-term investments)	$	—	$	—	$	31,090	$	31,090
Auction rate securities rights (long-term investments)	$	—	$	—	$	9,416	$	9,416
Marketable securities(1)	$	268	$	—	$	—	$	268
Deferred compensation liability(2)	$	284	$	—	$	—	$	284

67

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

	December 31, 2009
	Level 1		Level 2		Level 3		Total
Auction rate securities — trading securities (short-term investments)	$	—	$	—	$	30,718	$	30,718
Auction rate securities rights (short-term investments)	$	—	$	—	$	6,892	$	6,892
Marketable securities(1)	$	1,665	$	—	$	—	$	1,665
Deferred compensation(2)	$	1,682	$	—	$	—	$	1,682

(1)	In June 2008, the Company established the NeuStar, Inc. Deferred Compensation Plan (the Plan) to provide directors and certain employees with the ability to defer a portion of their compensation. The assets of the Plan are invested in marketable securities that are held in a Rabbi Trust and reported at market value in other assets.
(2)	Obligations to pay benefits under the Plan are included in other long-term liabilities.

The following table provides a reconciliation of the beginning and ending balances for the major class of assets measured at fair value using significant unobservable inputs (Level 3) (in thousands):

	Cash Reserve			Auction Rate			ARS
	Fund			Securities			Rights
Balance on December 31, 2008	$	10,824		$	31,090		$	9,416
Transfers in and/or (out) of Level 3		—			—			—
Total gains (losses) realized / unrealized included in earnings		450			3,628			(2,524	)
Total unrealized gains included in accumulated other comprehensive loss		—			—			—
Purchases, sales, issuances and settlements, net		(11,274	)		(4,000	)		—
Balance on December 31, 2009	$	—		$	30,718		$	6,892

The valuation technique used to measure fair value for the Level 3 ARS asset is the average of the values obtained using discounted cash flow methods. The discounted cash flow valuation methods involve management’s judgment and assumptions regarding discount rates, coupon rates, estimated maturity for each of the ARS, and judgment regarding the selection of comparable transactions in a secondary market.

As described in Note 3, in November 2008, the Company accepted a settlement offer in the form of a rights offering from an investment firm which provides the Company with the right to sell the ARS at par to the investment firm during a two year period beginning June 30, 2010. The valuation technique used to measure fair value of the ARS rights is the discounted cash flow method, which involves judgment and assumptions surrounding the timing of cash flows, fair value of the underlying ARS and the ability of the investment firm to settle its obligation in accordance with ARS rights offering.

5.   ACQUISITIONS

I-View.com

On January 8, 2007, the Company acquired certain assets of I-View.com, Inc. (d/b/a MetaInfo) for cash consideration of $1.7 million. The acquisition of MetaInfo expanded the Company’s enterprise Domain Name Services. The acquisition was accounted for as a purchase business combination and the results of operations of MetaInfo have been included within the Clearinghouse segment in the Company’s consolidated statements of operations since the date of acquisition. Of the total purchase price, $0.1 million was allocated to net tangible liabilities assumed, $0.5 million to definite-lived intangible assets and $1.3 million to goodwill. Definite-lived intangible assets consist of customer intangibles and acquired technology. The Company is amortizing the value of

68

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

the customer intangibles in proportion to the discounted cash flows over an estimated useful life of 3 years. Acquired technology is being amortized on a straight-line basis over 3 years.

Webmetrics, Inc.

On January 10, 2008, the Company acquired Webmetrics, Inc. (Webmetrics) for cash consideration of $12.5 million, subject to certain purchase price adjustments and contingent cash consideration of up to $6.0 million, and acquisition costs of approximately $0.7 million. The acquisition of Webmetrics, a provider of web and network performance testing, monitoring and measurement services, expanded the Company’s internet and infrastructure services. The acquisition was accounted for as a purchase business combination and the results of operations of Webmetrics have been included within the Clearinghouse segment in the Company’s consolidated statements of operations since the date of acquisition. Of the total purchase price, $0.4 million was allocated to net tangible assets acquired, $6.4 million to definite-lived intangible assets and $7.2 million to goodwill. Definite-lived intangible assets consist of customer relationships and acquired technology. The Company is amortizing the value of the customer relationships in proportion to the discounted cash flows over an estimated useful life of 3 years. Acquired technology is being amortized on a straight-line basis over 5 years.

In 2008 and 2009, the Company recorded $1.2 million and $0.4 million, respectively, in purchase price adjustments to goodwill related to earn-out consideration in accordance with the original purchase agreement.

6.   DEFERRED FINANCING COSTS

In 2007 the Company paid $0.9 million of loan origination fees related to its 2007 credit facility. Total amortization expense was approximately $0.2 million, $0.2 million and $0.2 for the years ended December 31, 2007, 2008 and 2009, respectively, and is reported as interest expense in the consolidated statements of operations. As of December 31, 2008 and 2009, the balance of unamortized deferred financing fees was $0.5 million and $0.3 million, respectively.

69

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

7.   GOODWILL AND INTANGIBLE ASSETS

Goodwill

The changes in the carrying amount of goodwill by reportable segment during the years ended December 31, 2008 and 2009 are as follows (in thousands):

	Clearinghouse		NGM			Total
Balance at December 31, 2007
Goodwill	$	88,148	$	115,945		$	204,093
Accumulated impairment losses		—		—			—
		88,148		115,945			204,093
Acquisitions		6,379		—			6,379
Purchase price adjustments		1,197		—			1,197
Impairment charge		—		(93,602	)		(93,602	)
Balance at December 31, 2008
Goodwill		95,724		115,945			211,669
Accumulated impairment losses		—		(93,602	)		(93,602	)
		95,724		22,343			118,067
Acquisitions		—		—			—
Purchase price adjustments		350		—			350
Impairment charge		—		—			—
Balance at December 31, 2009
Goodwill		96,074		115,945			212,019
Accumulated impairment losses		—		(93,602	)		(93,602	)
	$	96,074	$	22,343		$	118,417

In January 2008, the Company recorded $6.4 million of goodwill related to its acquisition of Webmetrics. During 2008 and 2009, in connection with the Company’s 2008 Webmetrics acquisition, the Company recorded $1.2 million and $0.4 million, respectively, in purchase price adjustments related to earn-out consideration in accordance with the original purchase agreement.

In 2008, changes to the Company’s key assumptions in determining the fair value of the NGM reporting unit resulted in two goodwill impairment charges for a total of $93.6 million. Late in the first quarter of 2008, NGM experienced certain changes in market conditions and customer-related events that caused NGM to revise its business forecast, triggering the requirement to perform an interim goodwill impairment test. First, the Company compared the estimated fair value of the NGM reporting unit’s net assets, including assigned goodwill, to the book value of these net assets. The estimated fair value for the reporting unit was calculated using a combination of discounted cash flow projections, market values for comparable businesses, and terms, prices and conditions found in sales of comparable businesses. The Company determined that the fair value of the reporting unit was less than its net book value. The Company then performed a theoretical purchase price allocation to compare the carrying value of NGM’s assigned goodwill to its implied fair value and recorded an impairment charge of $29.0 million in the first quarter of 2008.

In the fourth quarter of 2008, in response to lower than anticipated adoption rates and the resulting underperformance of the NGM business, as well as the manner in which the mobile data market had evolved and was evolving, the Company added new leadership and conducted a strategic evaluation of the NGM business. The goal of this strategic evaluation was to position NGM for future long-term success in the mobile instant

70

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

messaging market. Associated with the Company’s strategic re-assessment and due to the underperformance in the NGM business, certain key assumptions and estimates regarding the NGM business had fundamentally changed, resulting in a new business forecast for the NGM business which was used in connection with the annual goodwill impairment test. First, the Company compared the fair value of the NGM’s reporting unit’s net assets, including assigned goodwill, to the book value of these net assets. The estimated fair value for the reporting unit was calculated using a combination of discounted cash flow projections, market values for comparable businesses, and terms, prices and conditions found in sales of comparable businesses. The Company determined that the estimated fair value of the reporting unit was less than its net book value as of the annual impairment test date. As such, the Company then performed a theoretical purchase price allocation to compare the carrying value of NGM’s assigned goodwill to its implied fair value and recorded an impairment charge of $64.6 million in the fourth quarter of 2008.

These 2008 goodwill impairment charges have been recorded in Impairment of Goodwill in the consolidated statements of operations.

The Company’s 2009 annual goodwill impairment analysis, which was performed for each of its reporting units during the fourth quarter of 2009, did not result in an impairment charge. The Company believes that the assumptions and estimates used to determine the estimated fair values of each of its reporting units are reasonable; however, these estimates are inherently subjective, and there are a number of factors, including factors outside of the Company’s control that could cause actual results to differ from estimates. Changes in estimates and assumptions could have a significant impact on whether or not an impairment charge is recognized and also the magnitude of any such charge. Specifically, for the Company’s NGM reporting unit as of October 1, 2009, the annual testing date, the estimated fair value exceeded the carrying value by approximately 10%. The assumptions and estimates used by management to value the NGM reporting unit have a high degree of subjectivity due to the early stage of operations and the emerging nature of mobile instant messaging technology, and are thus more likely to change over time. In addition, because relatively few carriers control a substantial portion of the end users who will drive the success of mobile instant messaging, the activities of NGM’s largest customers could have a significant impact on these assumptions and estimates. The Company’s assumptions and estimates regarding the NGM reporting unit could change due to further delays resulting from changes in strategy by participants in the mobile instant messaging market, lack of effective marketing efforts to promote mobile instant messaging to end users, unforeseen changes in the market or other factors.

The key assumptions used in the 2009 annual goodwill impairment test to determine the fair value of the Company’s NGM reporting unit included: (a) cash flow projections, which include growth assumptions for forecasted revenue and expenses; (b) a terminal multiple of 7.0 times based upon the expected proceeds resulting from a sale of the NGM business unit at the end of the cash flow projection period; (c) a discount rate of 35%, which was based upon the NGM business unit’s weighted cost of capital adjusted for the risks associated with the operations at the time of the annual goodwill impairment test; (d) selection of comparable companies and transactions used in the market approach; and (e) assumptions in weighting the results of the income approach and market approach valuation techniques. A change in these assumptions would have had a significant effect on the determined fair value of the NGM reporting unit and could have resulted in an estimated fair value of the NGM reporting unit that was less than the NGM reporting unit’s carrying value. If the Company had performed the second step of comparing the carrying value of the NGM’s reporting unit’s assigned goodwill to the implied fair value using a theoretical purchase price allocation, the outcome of the Company’s analysis might have resulted in a material goodwill impairment charge.

In addition, any changes to the Company’s key assumptions about its businesses and its prospects, or changes in market conditions, could cause the fair value of one of its reporting units to fall below that of its carrying value, resulting in an impairment charge. Such a charge could have a material effect on its consolidated financial statements because of the significance of goodwill and intangible assets to the Company’s consolidated balance sheet.

71

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Intangible Assets

During the fourth quarter of 2008, the Company made the determination that its strategic decision to reposition the NGM business and the resulting change in its projected results served as an indicator of impairment for long-lived assets in the NGM business reporting unit. The Company performed an impairment analysis of the NGM reporting unit’s long-lived assets and concluded that the carrying amount of the NGM asset group exceeded the estimated future undiscounted cash flows of the NGM asset group. The Company performed a recoverability test, determined that the fair value of these long-lived assets was less than the carrying value, and recorded a total impairment charge of $18.2 million in the fourth quarter of 2008, consisting of a charge of $12.9 million to write down the carrying value of the NGM reporting unit’s intangible assets and a charge of $5.3 million to write down the carrying value of the NGM reporting unit’s property and equipment (see Note 8). The NGM intangible assets impairment charge of $12.9 million includes a $10.9 million impairment charge related to customer lists and relationships and a $2.0 million impairment charge related to acquired technology. The valuation techniques utilized by the Company in its fair value estimates primarily included the discounted cash flow method and the relief from royalty method.

In August 2009, the Company announced the extension of the restructuring plan initiated in the fourth quarter of 2008 to include further headcount reductions and the closure of certain facilities. Due to the Company’s extension of the NGM restructuring plan and the resulting change in the projected results, the Company performed a recoverability test of its long-lived assets, including intangible assets, in the NGM asset group and determined that the assets were recoverable from the undiscounted cash flows.

There were no asset impairment charges recognized in the year ended December 31, 2007. Intangible assets consist of the following (in thousands):

							Weighted-
							Average
							Amortization
	December 31,						Period
	2008			2009			(in years)
Intangible assets:
Customer lists and relationships	$	36,659		$	36,659			5.6
Accumulated amortization		(24,196	)		(29,483	)
Customer lists and relationships, net		12,463			7,176
Acquired technology		17,744			17,744			3.3
Accumulated amortization		(13,633	)		(16,131	)
Acquired technology, net		4,111			1,613
Trade name		200			200			3.0
Accumulated amortization		(180	)		(200	)
Trade name, net		20			—
Intangible assets, net	$	16,594		$	8,789

Amortization expense related to intangible assets for the years ended December 31, 2007, 2008 and 2009 of approximately $14.9 million, $13.9 million and $7.8 million, respectively, is included in depreciation and amortization expense. Amortization expense related to intangible assets for the years ended December 31, 2010, 2011, 2012 and 2013 is expected to be approximately $4.7 million, $2.4 million, $1.5 million and $0.2 million, respectively. Intangible assets as of December 31, 2009 will be fully amortized during the year ended December 31, 2013.

72

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

8.   PROPERTY AND EQUIPMENT

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

	December 31,
	2008			2009
Computer hardware	$	68,955		$	82,121
Equipment		2,142			1,700
Furniture and fixtures		2,729			3,821
Leasehold improvements		20,321			20,757
Construction in-progress		7,690			10,649
Capitalized software		46,954			64,426
		148,791			183,474
Accumulated depreciation and amortization		(84,631	)		(109,593	)
Property and equipment, net	$	64,160		$	73,881

The Company entered into capital lease obligations of $14.2 million and $10.8 million for the years ended December 31, 2008 and 2009, respectively, primarily for computer hardware.

Depreciation and amortization expense related to property and equipment for the years ended December 31, 2007, 2008 and 2009 was $22.8 million, $26.7 million and $30.2 million, respectively.

In the fourth quarter of 2008, the Company recorded a $5.3 million impairment charge to write-down the carrying value of property and equipment of the NGM reporting unit (see Note 7).

9.   ACCRUED EXPENSES

Accrued expenses consist of the following (in thousands):

	December 31,
	2008		2009
Accrued compensation	$	28,555	$	39,419
RRC reserve		3,295		2,594
Other		20,352		18,167
Total	$	52,202	$	60,180

73

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

10.   NOTES PAYABLE

Notes payable consist of the following (in thousands):

	December 31,
	2008			2009
Promissory note payable to vendor; principal and interest payable quarterly at 5.58% per annum with a maturity date of April 1, 2010; secured by the equipment financed	$	459		$	187
Promissory note payable to vendor; non-interest bearing, principal payable quarterly with a maturity date of April 1, 2010; secured by the equipment financed		3,905			800
		4,364			987
Less: current portion		(2,587	)		(987	)
Notes payable, long-term	$	1,777		$	—

Revolving Credit Facility

On February 6, 2007, the Company entered into a credit agreement which provides for a revolving credit facility in an aggregate principal amount of up to $100 million (Credit Facility). Borrowings under the Credit Facility bear interest, at the Company’s option, at either a Eurodollar rate plus a spread ranging from 0.625% to 1.25%, or at a base rate plus a spread ranging from 0.0% to 0.25%, with the amount of the spread in each case depending on the ratio of the Company’s consolidated senior funded indebtedness to consolidated earnings before interest, taxes, depreciation and amortization (EBITDA). The Credit Facility expires on February 6, 2012. Borrowings under the Credit Facility may be used for working capital, capital expenditures, general corporate purposes and to finance acquisitions. There were no borrowings outstanding under the Credit Facility as of December 31, 2008 and 2009, but available borrowings were reduced by outstanding letters of credit of $8.8 million and $9.0 million, respectively.

The Credit Facility contains customary representations and warranties, affirmative and negative covenants, and events of default. The Credit Facility requires the Company to maintain a minimum consolidated EBITDA to consolidated interest charge ratio and a maximum consolidated senior funded indebtedness to consolidated EBITDA ratio. If an event of default occurs and is continuing, the Company may be required to repay all amounts outstanding under the Credit Facility. Lenders holding more than 50% of the loans and commitments under the Credit Facility may elect to accelerate the maturity of amounts due thereunder upon the occurrence and during the continuation of an event of default. As of and for the years ended December 31, 2008 and 2009, the Company was in compliance with these covenants.

74

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

11.   COMMITMENTS AND CONTINGENCIES

Capital Leases

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

2010	$	11,349
2011		7,863
2012		2,719
2013		875
Thereafter		—
Total minimum lease payments		22,806
Less: amounts representing interest		(1,805	)
Present value of minimum lease payments		21,001
Less: current portion		(10,235	)
Capital lease obligation, long-term	$	10,766

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

	December 31,
	2008			2009
Equipment and hardware	$	35,856		$	41,540
Furniture and fixtures		334			334
Subtotal		36,190			41,874
Less: accumulated amortization		(20,717	)		(24,305	)
Net assets under capital leases	$	15,473		$	17,569

Operating Leases

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

2010	$	8,536
2011		6,585
2012		5,741
2013		4,391
2014		3,207
Thereafter		17,209
	$	45,669

On January 20, 2010, the Company entered into a new lease relating to its corporate headquarters in Sterling, Virginia. The lease commences October 1, 2010 and terminates January 31, 2021. The amounts presented in the table above do not reflect the future lease obligations under the new lease entered into on January 20, 2010. The future lease commitments under this lease are $0.0 million, $2.1 million, $2.4 million, $2.5 million, and

75

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

$2.6 million for the years ended December 31, 2010, 2011, 2012, 2013 and 2014, respectively, and $17.3 million for the year ended 2015 and thereafter.

Rent expense was $6.7 million, $7.5 million and $7.4 million for the years ended December 31, 2007, 2008 and 2009, respectively.

Contingencies

Currently, and from time to time, the Company is involved in litigation incidental to the conduct 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.

12.   RESTRUCTURING CHARGES

Clearinghouse

At December 31, 2008 and 2009, the total accrued liability associated with restructuring and other related charges was $3.5 million and $3.6 million, respectively. The accrued restructuring liability relating to the Company’s Clearinghouse lease and facilities exit costs was $1.8 million and $1.3 million at December 31, 2008 and 2009, respectively. The Company paid approximately $0.4 million, $0.4 million, and $0.5 million, net of sublease payments, in each of the years ended December 31, 2007, 2008 and 2009, respectively. Amounts related to lease terminations due to the closure of excess facilities will be paid over the respective lease terms, the longest of which extends through 2011.

In October 2009, the Company adopted a plan to relocate certain operations and support functions to Louisville, Kentucky. The Company estimates it will incur approximately $3.0 million to $3.5 million of employee severance and related costs through the second quarter of 2010 under this plan. During the fourth quarter of 2009, the Company recorded restructuring charges of $1.0 million and paid $0.8 million related to severance and related costs under this plan. The accrued restructuring liability relating to the Company’s Clearinghouse severance and related costs was $0.2 million at December 31, 2009.

NGM

During the fourth quarter of 2008, management committed to and implemented a restructuring plan for the NGM business to more appropriately allocate resources to the Company’s key mobile instant messaging initiatives. The restructuring plan involved the reduction in and closure of specific leased facilities in some of the Company’s international locations. The Company has recorded severance and related costs of $1.2 million, and lease and facilities exit costs of $0.5 million, in the fourth quarter of 2008. The Company has not made any cash payments or recorded adjustments to the NGM restructuring estimates during 2008. In August 2009, the Company announced the extension of the restructuring plan to include further headcount reductions and closure of certain facilities. The Company anticipates that the restructuring plan will be completed by the end of the second quarter of 2010. Restructuring charges under this plan for the year ended December 31, 2009 were $4.8 million of severance and related costs and $0.2 million of lease and facility exit costs. The Company expects to incur additional pre-tax cash restructuring charges of approximately $2.5 million to $3.0 million, in addition to the restructuring charges recorded in 2008 and 2009. The Company estimates that these additional costs will consist primarily of employee severance and related costs of approximately $1.7 million to $2.2 million, and lease and facility exit costs of approximately $0.8 million.

76

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

The activity and balance of NGM’s restructuring liability accounts for the year ended December 31, 2009 are as follows (in thousands):

	Severance			Lease and
	and Related			Facilities Exit
	Costs			Costs			Total
Balance at December 31, 2008	$	1,187		$	460		$	1,647
Additional restructuring cost		4,912			249			5,161
Adjustments		(113	)		—			(113	)
Cash payments		(4,357	)		(246	)		(4,603	)
Balance at December 31, 2009	$	1,629		$	463		$	2,092

Amounts related to the lease and facilities exit costs will be paid over the respective lease terms, the longest of which extends through 2012.

13.   OTHER (EXPENSE) INCOME

Other (expense) income consists of the following (in thousands):

	Year Ended December 31,
	2007			2008			2009
Interest and other expense:
Interest expense	$	1,694		$	1,944		$	2,320
(Gain) loss on asset disposals		(149	)		(74	)		203
Loss on ARS Rights		—			—			3,410
Foreign currency transaction loss (gain)		(398	)		109			(272	)
Impairments and realized losses cash reserve fund		—			3,623			—
ARS impairments and trading losses		—			10,635			410
Total	$	1,147		$	16,237		$	6,071
Interest and other income:
Interest income	$	4,612		$	3,696		$	965
Realized gains on cash reserve fund		—			—			450
ARS trading gains		—			—			4,038
Gain on ARS Rights		—			9,416			886
Gain on indemnification claims		—			—			1,180
Total	$	4,612		$	13,112		$	7,519

During 2009, the Company received $1.2 million in payment of indemnification claims related to the acquisition of Followap Inc. in 2006.

77

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

14.   INCOME TAXES

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

	Year Ended December 31,
	2007			2008			2009
Current:
Federal	$	47,478		$	53,555		$	55,141
State		10,837			10,319			12,249
Total current		58,315			63,874			67,390
Deferred:
Federal		2,572			(1,355	)		1,109
State		(111	)		(832	)		(634	)
Total deferred		2,461			(2,187	)		475
Total provision for income taxes	$	60,776		$	61,687		$	67,865

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

	Year Ended December 31,
	2007			2008			2009
Tax at statutory rate		35.0	%		35.0	%		35.0	%
State taxes		4.6			9.3			4.4
Impairment of goodwill		—			49.7			—
Other		(0.1	)		(2.2	)		0.9
Change in valuation allowance		0.2			1.7			(0.1	)
Effective tax rate		39.7	%		93.5	%		40.2	%

The Company’s annual effective tax rate decreased to 40.2% for the year ended December 31, 2009 from 93.5% for the year ended December 31, 2008 due primarily to the impact of the $93.6 million non-cash impairment charge recorded in 2008 related to the impairment of goodwill, which is not deductible for tax purposes.

The Company realized certain tax benefits related to nonqualified and incentive stock option exercises in the amounts of $20.8 million, $8.2 million and $0.6 million for the years ended December 31, 2007, 2008 and 2009, respectively.

78

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,
	2008			2009
Deferred tax assets:
Domestic NOL carryforwards	$	10,525		$	7,329
Foreign NOL carryforwards		633			586
Restructuring accrual		952			1,539
Deferred revenue		6,998			4,696
Accrued compensation		1,058			1,398
Stock-based compensation expense		9,532			14,118
Other reserves		92			45
Unrealized losses on investments		5,212			3,821
Realized losses on investments		353			178
Other		2,374			2,381
Total deferred tax assets		37,729			36,091
Valuation allowance		(2,864	)		(2,610	)
Total deferred tax assets, net		34,865			33,481
Deferred tax liabilities:
Unbilled receivables		(324	)		(1,173	)
Depreciation and amortization		(7,341	)		(13,199	)
Identifiable intangibles		(3,894	)		(881	)
Deferred expenses		(4,174	)		(3,272	)
Unrealized gains on investments		(3,675	)		(2,708	)
Other		(134	)		(151	)
Total deferred tax liabilities		(19,542	)		(21,384	)
Net deferred tax assets	$	15,323		$	12,097

As of December 31, 2009, the Company had U.S. net operating loss carryforwards for federal tax purposes of approximately $16.1 million which expire, if unused, in various years from 2023 to 2026. As of December 31, 2009, the Company had foreign net operating loss carryforwards of approximately $3.4 million, of which $3.2 million can be carried forward indefinitely under current local tax laws and $0.2 million which expire, if unused, in years beginning 2017.

As of December 31, 2009, the amount of earnings from foreign subsidiaries that the Company considers permanently reinvested and for which deferred taxes have not been provided was approximately $2.1 million. United States income taxes have not been provided on earnings that are planned to be reinvested indefinitely outside the United States and determination of the amount of such taxes is not practicable.

79

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

At December 31, 2008 and 2009, the Company had unrecognized tax benefits of $1.1 million and $1.1 million, respectively, of which $0.6 million and $1.1 million, respectively, would affect the Company’s effective tax rate if recognized. The net increase in the liability for unrecognized income tax benefits is as follows (in thousands):

Balance at January 1, 2007	$	825
Increase related to tax positions of prior years		1,215
Other		(70	)
Balance at December 31, 2007		1,970
Increase related to current year tax positions		75
Increase related to prior year tax positions		329
Reductions for prior year tax positions		(1,320	)
Balance at December 31, 2008		1,054
Increase related to current year tax positions		48
Increase related to prior year tax positions		353
Reductions due to lapse in statutes of limitations		(158	)
Settlements		(225	)
Balance at December 31, 2009	$	1,072

The Company recognizes interest and penalties related to uncertain tax positions in income tax expense. During the years ended December 31, 2007, 2008 and 2009, the Company recognized potential interest and penalties of $220,000, $78,000 and $66,000, respectively. As of December 31, 2008 and 2009, the Company had established reserves of approximately $80,000 and $60,000, respectively, for accrued potential interest and penalties related to uncertain tax positions. To the extent interest and penalties are not assessed with respect to uncertain tax positions, amounts accrued will be reduced and reflected as a reduction of the overall income tax provision. During the year ended December 31, 2009, accrued interest and penalties decreased by $37,000 due to the expiration of certain statutes of limitations and the payment of approximately $49,000 of accrued interest and penalties.

The Company files income tax returns in the United States Federal jurisdiction and in many state and foreign jurisdictions. The tax years 2005 through 2009 remain open to examination by the major taxing jurisdictions to which the Company is subject. The Internal Revenue Service (“IRS”) has completed an examination of the Company’s federal income tax returns for the years 2005 and 2006. The audit resulted in no material adjustments.

The Company does not anticipate that total unrecognized tax benefits will decrease over the next 12 months due to the expiration of certain statutes of limitations.

15.   STOCKHOLDERS’ 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. As of December 31, 2008 and 2009, there are no preferred stock shares issued or outstanding.

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

80

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

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 time and in the amounts as the Company’s board of directors may from time to time determine.

Stock-Based Compensation

The Company has three stock incentive plans, the NeuStar, Inc. 1999 Equity Incentive Plan (1999 Plan), the NeuStar, Inc. 2005 Stock Incentive Plan (2005 Plan), and the NeuStar, Inc. 2009 Stock Incentive Plan (2009 Plan). The Company may grant to its directors, employees and consultants awards under the 2009 Plan in the form of incentive stock options, nonqualified stock options, stock appreciation rights, shares of restricted stock, restricted stock units, PVRSUs 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 2009 Plan is 10,950,000, plus the number of shares underlying awards granted under the 1999 Plan and the 2005 Plan that remain undelivered following any expiration, cancellation or forfeiture of such awards. As of December 31, 2009, 10,641,598 shares were available for grant or award under the 2009 Plan.

The term of any stock option granted under the 1999 Plan, 2005 Plan, and 2009 Plan may not exceed ten years. The exercise price per share for options granted under these Plans may not be 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 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 seven to ten years from the date of issuance and are forfeitable upon termination of an option holder’s service.

The board of directors or Compensation Committee of the board of directors has granted and may in the future grant restricted stock to directors, employees and consultants. The board of directors or Compensation Committee of the board of directors determines the vesting of the restricted stock, with a maximum vesting period of ten years. Restricted stock issued generally vests in equal annual installments over a four-year term.

Stock-based compensation expense recognized for the years ended December 31, 2007, 2008 and 2009 was $15.3 million, $13.4 million and $14.3 million, respectively. As of December 31, 2009, total unrecognized compensation expense related to non-vested stock options, non-vested restricted stock and non-vested PVRSUs granted prior to that date is estimated at $28.5 million, which the Company expects to recognize over a weighted average period of approximately 1.54 years. Total unrecognized compensation expense as of December 31, 2009 is estimated based on outstanding non-vested stock options, non-vested restricted stock and non-vested PVRSUs, and may be increased or decreased in future periods for subsequent grants or forfeitures.

Stock Options

The Company utilizes the Black-Scholes option pricing model for estimating the fair value of stock options granted. The weighted-average grant date fair value of options granted during the years ended December 31, 2007, 2008 and 2009 was $11.60, $8.24 and $6.47, respectively. The following are the weighted-average assumptions used in valuing the stock options granted during the years ended December 31, 2007, 2008 and 2009, and a discussion of the Company’s assumptions.

	Year Ended December 31,
	2007			2008			2009
Dividend yield		—	%		—	%		—	%
Expected volatility		33.27	%		36.46	%		43.37	%
Risk-free interest rate		4.39	%		2.57	%		1.60	%
Expected life of options (in years)		4.59			4.37			4.42

81

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Dividend yield — The Company has never declared or paid dividends on its common stock and does not anticipate paying dividends in the foreseeable future.

Expected volatility — Volatility is a measure of the amount by which a financial variable such as a share price has fluctuated (historical volatility) or is expected to fluctuate (expected volatility) during a period. Given the Company’s limited historical stock data since its initial public offering in June 2005, the Company considered the implied volatility and historical volatility of its stock price over a term similar to the expected life of the grant in determining its expected volatility.

Risk-free interest rate — The risk-free interest rate is based on U.S. Treasury bonds issued with similar life terms to the expected life of the grant.

Expected life of the options — The expected life is the period of time that options granted are expected to remain outstanding. The Company determined the expected life of stock options based on the weighted average of (a) the time-to-settlement from grant of historically settled options and (b) a hypothetical holding period for the outstanding vested options as of the date of fair value estimation. The hypothetical holding period is the amount of time the Company assumes a vested option will be held before the option is exercised. To determine the hypothetical holding period, the Company assumes that a vested option will be exercised at the midpoint of the time between the date of fair value estimation and the remaining contractual life of the unexercised vested option.

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

								Weighted
								Average
				Weighted-		Aggregate		Remaining
				Average		Intrinsic		Contractual
				Exercise		Value		Life
	Shares			Price		(In millions)		(in years)
Outstanding at December 31, 2006		7,916,728		$	10.83
Options granted		932,030			32.78
Options exercised		(2,492,811	)		5.75
Options forfeited		(687,446	)		21.14
Outstanding at December 31, 2007		5,668,501			15.42
Options granted		1,400,840			25.21
Options exercised		(1,612,596	)		3.80
Options forfeited		(796,180	)		28.49
Outstanding at December 31, 2008		4,660,565			20.15
Options granted		2,237,649			17.33
Options exercised		(344,183	)		4.96
Options forfeited		(602,773	)		26.08
Outstanding at December 31, 2009		5,951,258			19.37	$	36.6		4.85
Exercisable at December 31, 2009		3,079,893			18.82	$	24.5		3.73
Exercisable at December 31, 2008		2,782,015			15.27	$	23.9		4.20
Exercisable at December 31, 2007		3,501,651		$	8.54	$	72.0		4.62

The aggregate intrinsic value of options exercised for the years ended December 31, 2007, 2008 and 2009 was $62.5 million, $32.3 million and $4.2 million, respectively.

82

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

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

					Weighted-
	Options Outstanding				Average		Options Exercisable
	Number		Weighted-		Remaining		Number		Weighted-
	of		Average		Contractual		of		Average
	Options		Exercise		Life		Options		Exercise
Range of Exercise Price	Outstanding		Price		(in years)		Exercisable		Price
$ 0.00 - $ 3.48		449,933	$	0.67		1.11		449,933	$	0.67
$ 3.49 - $ 6.97		778,835		6.05		3.86		778,835		6.05
$ 6.98 - $10.45		3,984		8.39		4.88		3,984		8.39
$10.46 - $13.94		58,543		10.86		5.13		58,543		10.86
$13.95 - $17.42		1,370,510		15.43		6.15		10,168		16.69
$17.43 - $20.90		419,929		19.11		6.26		30,453		18.53
$20.91 - $24.39		661,263		22.40		6.87		155,850		21.94
$24.40 - $27.87		814,744		26.44		5.14		398,080		26.50
$27.88 - $31.36		670,933		30.23		3.16		640,683		30.23
$31.37 - $34.84		722,584		32.89		4.32		553,364		32.88
		5,951,258	$	19.37		4.85		3,079,893	$	18.82

Restricted Stock

The following table summarizes the Company’s non-vested restricted stock activity:

				Weighted-		Aggregate
				Average		Intrinsic
				Grant Date		Value
	Shares			Fair Value		(In millions)
Outstanding at December 31, 2006		103,223		$	31.41
Restricted stock granted		18,800			31.78
Restricted stock vested		(27,538	)		31.48
Restricted stock forfeited		(18,825	)		31.13
Outstanding at December 31, 2007		75,660			31.55
Restricted stock granted		286,920			24.57
Restricted stock vested		(45,827	)		28.16
Restricted stock forfeited		(56,455	)		27.07
Outstanding at December 31, 2008		260,298			25.50
Restricted stock granted		192,000			20.69
Restricted stock vested		(61,375	)		25.90
Restricted stock forfeited		(37,766	)		27.11
Outstanding at December 31, 2009		353,157		$	22.64	$	8.1

The total aggregate intrinsic value of restricted stock vested during the years ended December 31, 2007, 2008 and 2009 was approximately $0.8 million, $1.0 million and $1.3 million, respectively. During the years ended December 31, 2007, 2008 and 2009, the Company repurchased 6,817, 13,375, and 18,208 shares of common stock, respectively, for an aggregate purchase price of $0.2 million, $0.3 million, and $0.4 million, respectively, pursuant to the participants’ rights under the Company’s stock incentive plans to elect to use common stock to satisfy their tax withholding obligations.

83

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Performance Vested Restricted Stock Units

During the years ended 2007, 2008 and 2009, the Company granted 322,290, 291,083, and 532,943 PVRSUs, respectively, to certain employees with an aggregate fair value of $10.5 million, $7.6 million, and $8.3 million, respectively. The vesting of these stock awards is contingent upon the Company achieving specified financial targets at the end of the specified performance period and an employee’s continued employment. The level of achievement of the performance conditions affects the number of shares that will ultimately be issued. The range of possible stock-based award vesting is between 0% and 150% of the initial target. Compensation expense related to these awards is being recognized over the requisite service period based on the Company’s estimate of the achievement of the performance target. The Company currently estimates that 0%, 50% and 100%, of the performance target for its PVRSUs granted during 2007, 2008 and 2009, respectively will be achieved. In the third quarter of 2009, the Company revised its estimate of achievement of the performance targets related to the PVRSUs granted during 2007 from 50% of target to 0%. The change in this assumption resulted in a reduction of approximately $2.6 million in compensation expense in the year ended 2009. The Company’s consolidated net income for the year ended December 31, 2009 was $101.1 million and diluted earnings per share was $1.34 per share. If the Company had continued to use the previous estimate of achievement of 50% of the performance target, the as adjusted net income would have been approximately $99.5 million and the as adjusted diluted earnings per share would have had been approximately $1.32 per share. The fair value of a PVRSU is measured by reference to the closing market price of the Company’s common stock on the date of the grant. Compensation expense is recognized on a straight-line basis over the requisite service period based on the number of PVRSUs expected to vest.

The following table summarizes the Company’s non-vested PVRSU activity:

				Weighted-		Aggregate
				Average		Intrinsic
				Grant Date		Value
	Shares			Fair Value		(In millions)
Non-vested December 31, 2006		—		$	—
Granted		322,290			32.59
Vested		—			—
Forfeited		(19,210	)		32.59
Non-vested December 31, 2007		303,080			32.59
Granted		291,083			26.21
Vested		—			—
Forfeited		(181,020	)		30.60
Non-vested December 31, 2008		413,143			28.98
Granted		532,943			15.57
Vested		—			—
Forfeited		(106,300	)		23.38
Non-vested December 31, 2009		839,786		$	21.17	$	19.3

84

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Restricted Stock Units

The following table summarizes the Company’s restricted stock units activity:

				Weighted-		Aggregate
				Average		Intrinsic
				Grant Date		Value
	Shares			Fair Value		(In millions)
Outstanding at December 31, 2006		23,911
Granted		34,170
Vested		—
Forfeited		(3,259	)
Outstanding at December 31, 2007		54,822
Granted		55,777
Vested		—
Forfeited		—
Outstanding at December 31, 2008		110,599		$	26.21
Granted		52,512			22.85
Vested		—			—
Forfeited		—			—
Outstanding at December 31, 2009		163,111		$	25.13	$	3.8

In August and November 2007, the Compensation Committee of the board of directors issued 30,828 and 3,342 restricted stock units to its non-management directors, respectively, with an aggregate intrinsic value on the grant date of approximately $0.9 million and $0.1 million, respectively. In June and July 2008, the Company’s non-management directors were issued 1,089 and 54,688 restricted stock units, respectively, with an aggregate intrinsic value on the grant date of approximately $25,000 and $1.2 million, respectively. In July 2009, the Company’s non-management directors were issued 52,512 restricted stock units with an aggregate intrinsic value on the grant date of approximately $1.2 million.

These restricted stock units issued to non-management directors of the Company’s board of directors will fully vest on the first anniversary of the date of grant. Upon vesting, each director’s restricted stock units will be automatically converted into deferred stock units, which will be delivered to the director in shares of the Company’s stock six months following the director’s termination of Board service.

Phantom Stock Units

In July 2004, the board of directors granted 350,000 phantom stock units to one of the Company’s executive officers. Effective March 1, 2007, the officer was no longer employed with the Company. On that date, 224,383 phantom stock units vested in accordance with the terms of the officer’s phantom stock agreement, which had an aggregate intrinsic value of approximately $7.3 million. Of the 224,383 shares of the Company’s common stock issuable to the officer in respect of his vested phantom stock units, the Company repurchased 91,713 shares on March 1, 2007 for an aggregate purchase price of approximately $3.0 million pursuant to the officer’s right under the applicable stock incentive plan to elect to use common stock to satisfy his tax withholding obligations.

85

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

16.   BASIC AND DILUTED NET INCOME PER COMMON SHARE

The following table provides a reconciliation of the numerators and denominators used in computing basic and diluted net income per common share (in thousands, except per share data):

	Year Ended December 31,
	2007		2008		2009
Computation of basic net income per common share:
Net income	$	92,335	$	4,294	$	101,141
Weighted average common shares and participating securities outstanding — basic		76,038		74,350		74,301
Basic net income per common share	$	1.21	$	0.06	$	1.36
Computation of diluted net income per common share:
Net income	$	92,335	$	4,294	$	101,141
Weighted average common shares and participating securities outstanding — basic		76,038		74,350		74,301
Effect of dilutive securities:
Stock-based awards		3,262		1,757		1,164
Weighted average common shares outstanding — diluted		79,300		76,107		75,465
Diluted net income per common share	$	1.16	$	0.06	$	1.34

Diluted earnings per common share reflects the potential dilution of common stock equivalents such as options and warrants, to the extent the impact is dilutive.

The following table summarizes the shares excluded from the calculation of the denominator for diluted net income per common share due to their anti-dilutive effect for the periods indicated (in thousands):

	Year Ended December 31,
	2007		2008		2009
Shares excluded from EPS denominator due to anti-dilutive effect:
Common stock options		2,026		3,039		3,965

17.   SEGMENT INFORMATION

The Company has two reportable operating segments: Clearinghouse and NGM.

The Company’s Clearinghouse business segment provides critical technology services to the communications industry and enterprise customers, including telephone number administration, telephone number pooling, internet domain name services, common short code registry services, wireline and wireless number portability, order management services and network management services.

The Company’s NGM business segment provides next-generation communications solutions for mobile network operators by delivering instant messaging, presence, multimedia gateways and inter-carrier messaging hubs.

The Company reports segment information based on the “management” approach. The management approach designates the internal reporting used by the chief operating decision maker for making decisions and assessing performance.

86

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Information for the years ended December 31, 2007, 2008 and 2009 regarding the Company’s reportable segments is as follows (in thousands):

	Year Ended December 31,
	2007			2008			2009
Revenue:
Clearinghouse	$	421,062		$	474,141		$	467,256
NGM		8,110			14,704			13,129
Total revenue	$	429,172		$	488,845		$	480,385
Depreciation and amortization:
Clearinghouse	$	28,241		$	29,978		$	29,852
NGM		9,490			10,604			8,188
Total depreciation and amortization	$	37,731		$	40,582		$	38,040
Income (loss) from operations:
Clearinghouse	$	184,955		$	225,700		$	190,458	(b)
NGM		(35,309	)		(156,594	)(a)		(22,900	)(c)
Income (loss) from operations	$	149,646		$	69,106		$	167,558

(a)	Includes $1.7 million of restructuring charges, $93.6 million of goodwill impairment charges, and $18.2 million of long-lived assets impairment charges.
(b)	Includes $1.0 million of restructuring charges.
(c)	Includes $5.0 million of restructuring charges.

Information as of December 31, 2008 and 2009 regarding the Company’s reportable segments is as follows (in thousands):

	December 31,
	2008		2009
Total assets:
Clearinghouse	$	458,689	$	602,406
NGM		60,477		45,398
Total assets	$	519,166	$	647,804
Goodwill:
Clearinghouse	$	95,724	$	96,074
NGM		22,343		22,343
Goodwill	$	118,067	$	118,417
Intangible assets:
Clearinghouse	$	13,552	$	7,700
NGM		3,042		1,089
Intangible assets	$	16,594	$	8,789

87

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

Geographic area revenues from external customers for the years ended December 31, 2007, 2008 and 2009, and long-lived assets as of December 31, 2008 and 2009 were as follows (in thousands):

	Year Ended December 31,
	2007		2008		2009
Revenues:
North America	$	403,536	$	443,921	$	440,480
Europe, Middle East and Africa		17,004		34,274		27,546
Other regions		8,632		10,650		12,359
Total revenues	$	429,172	$	488,845	$	480,385

	December 31,
	2008		2009
Long-lived assets, net:
North America	$	69,227	$	77,785
Europe, Middle East and Africa		10,755		4,350
Other regions		772		535
Total long-lived assets, net	$	80,754	$	82,670

18.   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 Company makes matching and other discretionary contributions under this plan, as determined by the board of directors. The Company recognized contribution expense totaling $4.3 million, $5.2 million and $4.3 million for the years ended December 31, 2007, 2008 and 2009, respectively.

In June 2008, the Company established the NeuStar, Inc. Deferred Compensation Plan (the “Deferred Compensation Plan”). The Deferred Compensation Plan allows directors and key employees to defer a portion of their salary and up to 100% of their bonus, commissions, incentive awards, directors’ fees, and certain equity-based cash compensation, as applicable. The assets of the Deferred Compensation Plan are held in a Rabbi Trust, and are therefore available to satisfy the claims of creditors in the event of bankruptcy or insolvency of the Company. The assets of the Rabbi Trust are invested in marketable securities and reported at market value. Changes in the fair value of the securities are reflected in accumulated other comprehensive loss. The assets of the Rabbi Trust are recorded within other assets on the consolidated balance sheets. As of December 31, 2008 and 2009, the assets held in the Rabbi Trust were approximately $0.3 million and $1.7 million, respectively. As of December 31, 2008, the Company’s unrealized loss was approximately $27,000 and as of December 31, 2009, the Company’s unrealized gain was approximately $0.2 million, attributable to the securities held in the Rabbi Trust.

The Deferred Compensation Plan participants make investment allocation decisions on amounts deferred under the Deferred Compensation Plan solely for the purpose of adjusting the value of a participant’s account balance. The participant does not have a real or beneficial ownership interest in any securities held in the Rabbi Trust. Obligations to pay benefits under the Deferred Compensation Plan are reported at fair value as deferred compensation in other long-term liabilities. As of December 31, 2008 and 2009, deferred compensation obligation related to the Deferred Compensation Plan was approximately $0.3 million and $1.7 million, respectively. Changes in the fair value of the deferred compensation obligation are reflected in deferred compensation expense. The Company recognized gains of approximately $33,000 and losses of $0.4 million in compensation expense for changes in the fair value of the deferred compensation obligation during the years ended December 31, 2008 and 2009, respectively.

88

NEUSTAR, INC.

NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)

19.   RELATED PARTY TRANSACTIONS

During the year ended December 31, 2007, 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, 2007 and 2008 were approximately $227,000 and $2,000, respectively.

20.   QUARTERLY FINANCIAL INFORMATION (UNAUDITED)

	Quarter Ended
	Mar. 31,			Jun. 30,		Sep. 30,		Dec. 31,
	2008			2008		2008		2008
	(In thousands, except per share data)
Summary consolidated statement of operations:
Total revenue	$	117,413		$	120,209	$	123,810	$	127,413
Income (loss) from operations		11,029			39,988		45,163		(27,074	)
Net (loss) income		(4,460	)		22,856		28,374		(42,476	)
Net (loss) income per common share — basic	$	(0.06	)	$	0.31	$	0.38	$	(0.57	)
Net (loss) income per common share — diluted	$	(0.06	)	$	0.30	$	0.38	$	(0.57	)

	Quarter Ended
	Mar. 31,		Jun. 30,		Sep. 30,		Dec. 31,
	2009		2009		2009		2009
	(In thousands, except per share data)
Summary consolidated statement of operations:
Total revenue	$	113,188	$	115,764	$	117,203	$	134,230
Income from operations		38,779		40,042		40,436		48,301
Net income		24,353		24,466		24,519		27,803
Net income per common share — basic	$	0.33	$	0.33	$	0.33	$	0.37
Net income per common share — diluted	$	0.32	$	0.32	$	0.32	$	0.37

89

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

Not applicable.

ITEM 9A.   CONTROLS AND PROCEDURES

Attached as exhibits to this Form 10-K are certifications of our Chief Executive Officer and Chief Financial Officer, which are required in accordance with Rule 13a-14 of the Securities Exchange Act of 1934, as amended. This “Controls and Procedures” section includes information concerning the controls and controls evaluation referred to in the certifications. The report of Ernst & Young LLP, our independent registered public accounting firm, regarding its audit of our internal control over financial reporting is set forth below in this section. This section should be read in conjunction with the certifications and the Ernst & Young report for a more complete understanding of the topics presented.

Evaluation of Disclosure Controls and Procedures

We conducted an evaluation of the effectiveness of the design and operation of our “disclosure controls and procedures” as of the end of the period covered by this Form 10-K. The controls evaluation was conducted under the supervision and with the participation of management, including our Chief Executive Officer and Chief Financial Officer. Disclosure controls are controls and procedures designed to reasonably assure that information required to be disclosed in our reports filed under the Securities Exchange Act of 1934, such as this Form 10-K, is recorded, processed, summarized and reported within the time periods specified in the SEC’s rules and forms. Disclosure controls are also designed to reasonably assure that such information is accumulated and communicated to our management, including the Chief Executive Officer and Chief Financial Officer, as appropriate to allow timely decisions regarding required disclosure. Our quarterly evaluation of disclosure controls includes an evaluation of some components of our internal control over financial reporting, and internal control over financial reporting is also separately evaluated on an annual basis for purposes of providing the management report which is set forth below.

The evaluation of our disclosure controls included a review of the controls’ objectives and design, our implementation of the controls and their effect on the information generated for use in this Form 10-K. In the course of the controls evaluation, we reviewed identified data errors, control problems or indications of potential fraud and, where appropriate, sought to confirm that appropriate corrective actions, including process improvements, were being undertaken. This type of evaluation is performed on a quarterly basis so that the conclusions of management, including the Chief Executive Officer and Chief Financial Officer, concerning the effectiveness of the disclosure controls can be reported in our periodic reports on Form 10-Q and Form 10-K. Many of the components of our disclosure controls are also evaluated on an ongoing basis by our finance organization. The overall goals of these various evaluation activities are to monitor our disclosure controls, and to modify them as necessary. Our intent is to maintain the disclosure controls as dynamic systems that change as conditions warrant.

Based upon the controls evaluation, our Chief Executive Officer and Chief Financial Officer have concluded that, as of the end of the period covered by this Form 10-K, our disclosure controls were effective to provide reasonable assurance that information required to be disclosed in our Securities Exchange Act reports is recorded, processed, summarized and reported within the time periods specified by the SEC, and that material information related to NeuStar and its consolidated subsidiaries is made known to management, including the Chief Executive Officer and Chief Financial Officer, particularly during the period when our periodic reports are being prepared. We reviewed the results of management’s evaluation with the Audit Committee of our Board of Directors.

Management Report on Internal Control Over Financial Reporting

Our management is responsible for establishing and maintaining effective internal control over financial reporting to provide reasonable assurance regarding the reliability of our financial reporting and the preparation of financial statements for external purposes in accordance with U.S. generally accepted accounting principles. Internal control over financial reporting includes those policies and procedures that (i) pertain to the maintenance of records that in reasonable detail accurately and fairly reflect the transactions and dispositions of the assets of the

90

company; (ii) provide reasonable assurance that transactions are recorded as necessary to permit preparation of financial statements in accordance with U.S. generally accepted accounting principles; and (iii) provide reasonable assurance regarding authorization to effect the acquisition, use or disposition of company assets, as well as the prevention or timely detection of unauthorized acquisition, use or disposition of the company’s assets that could have a material effect on the financial statements.

Management assessed our internal control over financial reporting as of December 31, 2009, the end of our fiscal year. Management based its assessment on criteria established in Internal Control — Integrated Framework issued by the Committee of Sponsoring Organizations of the Treadway Commission. Management’s assessment included evaluation of such elements as the design and operating effectiveness of key financial reporting controls, process documentation, accounting policies and our overall control environment. This assessment is supported by testing and monitoring performed by our finance organization.

Based on this assessment, management has concluded that our internal control over financial reporting was effective as of the end of the fiscal year to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external reporting purposes in accordance with U.S. generally accepted accounting principles.

Our independent registered public accounting firm, Ernst & Young LLP, independently assessed the effectiveness of the company’s internal control over financial reporting. Ernst & Young has issued an attestation report, which is included at the end of this section.

Inherent Limitations on Effectiveness of Controls

A control system, no matter how well designed and operated, can provide only reasonable, not absolute, assurance that the control system’s objectives will be met. The design of a control system must reflect the fact that there are resource constraints, and the benefits of controls must be considered relative to their costs. Other inherent limitations include the realities that judgments in decision-making can be faulty and that breakdowns can occur because of simple error or mistake. Controls can also be circumvented by the individual acts of some persons, by collusion of two or more people, or by management override of the controls. Projections of any evaluation of controls effectiveness to future periods are subject to risks. Over time, controls may become inadequate because of changes in conditions or deterioration in the degree of compliance with policies or procedures.

Changes in Internal Control over Financial Reporting

On a quarterly basis we evaluate any changes to our internal control over financial reporting to determine if material changes occurred. There were no changes in our internal controls over financial reporting during the quarterly period ended December 31, 2009 that have materially affected, or are reasonably likely to materially affect, our internal control over financial reporting.

91

REPORT OF INDEPENDENT REGISTERED PUBLIC ACCOUNTING FIRM

Board of Directors and Stockholders

NeuStar, Inc.

We have audited NeuStar, Inc.’s internal control over financial reporting as of December 31, 2009, based on criteria established in Internal Control — Integrated Framework issued by the Committee of Sponsoring Organizations of the Treadway Commission (the COSO criteria). NeuStar, Inc.’s management is responsible for maintaining effective internal control over financial reporting, and for its assessment of the effectiveness of internal control over financial reporting included in the accompanying Management Report on Internal Control Over Financial Reporting. Our responsibility is to express an opinion on the company’s internal control over financial reporting based on our audit.

We conducted our audit 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 effective internal control over financial reporting was maintained in all material respects. Our audit included obtaining an understanding of internal control over financial reporting, assessing the risk that a material weakness exists, testing and evaluating the design and operating effectiveness of internal control based on the assessed risk, and performing such other procedures as we considered necessary in the circumstances. We believe that our audit provides a reasonable basis for our opinion.

A company’s internal control over financial reporting is a process designed to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with generally accepted accounting principles. A company’s internal control over financial reporting includes those policies and procedures that (1) pertain to the maintenance of records that, in reasonable detail, accurately and fairly reflect the transactions and dispositions of the assets of the company; (2) provide reasonable assurance that transactions are recorded as necessary to permit preparation of financial statements in accordance with generally accepted accounting principles, and that receipts and expenditures of the company are being made only in accordance with authorizations of management and directors of the company; and (3) provide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use, or disposition of the company’s assets that could have a material effect on the financial statements.

Because of its inherent limitations, internal control over financial reporting may not prevent or detect misstatements. Also, projections of any evaluation of effectiveness to future periods are subject to the risk that controls may become inadequate because of changes in conditions, or that the degree of compliance with the policies or procedures may deteriorate.

In our opinion, NeuStar, Inc. maintained, in all material respects, effective internal control over financial reporting as of December 31, 2009 based on the COSO criteria.

We also have audited, in accordance with the standards of the Public Company Accounting Oversight Board (United States), the consolidated balance sheets of NeuStar, Inc. as of December 31, 2008 and 2009, and the related consolidated statements of operations, shareholders’ equity, and cash flows for each of the three years in the period ended December 31, 2009 and our report dated February 26, 2010 expressed an unqualified opinion thereon.

/s/  Ernst & Young LLP

McLean, Virginia

February 26, 2010

92

ITEM 9B.   OTHER INFORMATION

None.

PART III

ITEM 10.   DIRECTORS AND EXECUTIVE OFFICERS OF THE REGISTRANT AND CORPORATE GOVERNANCE

Information about our directors and executive officers and our corporate governance is incorporated by reference to our definitive proxy statement for our 2010 Annual Meeting of Stockholders, or our 2010 Proxy Statement, which is anticipated to be filed with the Securities and Exchange Commission within 120 days of December 31, 2009, under the headings “Board of Directors,” “Executive Officers and Management” and “Governance of the Company.” Information about compliance with Section 16(a) of the Exchange Act is incorporated by reference to our 2010 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 2010 Proxy Statement under the heading “Governance of the Company.” 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 2010 Proxy Statement under the heading “Governance of the Company.”

ITEM 11.   EXECUTIVE COMPENSATION

Information about director and executive officer compensation is incorporated by reference to our 2010 Proxy Statement, under the headings “Governance of the Company.”

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 2010 Proxy Statement, under the headings “Beneficial Ownership of Shares of Common Stock” and “Equity Compensation Plan Information.”

ITEM 13.   CERTAIN RELATIONSHIPS AND RELATED TRANSACTIONS AND DIRECTOR INDEPENDENCE

The information required by Item 13 of this report is incorporated by reference to our 2010 Proxy Statement, under the heading “Governance of the Company.”

ITEM 14.   PRINCIPAL ACCOUNTING FEES AND SERVICES

Information about the fees for professional services rendered by our independent auditors in 2008 and 2009 is incorporated by reference to the discussion under the heading “Audit and Non-Audit Fees” in our 2010 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 “Governance of the Company.”

93

PART IV

ITEM 15.   EXHIBITS, FINANCIAL STATEMENT SCHEDULES

(a) Documents filed as part of this report:

(1)

	Page
Report of Independent Registered Public Accounting Firm		49
Consolidated Financial Statements covered by the Report of Independent Registered Public Accounting Firm:
Consolidated Balance Sheets as of December 31, 2008 and 2009		50
Consolidated Statements of Operations for the years ended December 31, 2007, 2008 and 2009		52
Consolidated Statements of Stockholders’ Equity for the years ended December 31, 2007, 2008 and 2009		53
Consolidated Statements of Stockholders’ Equity for the years ended December 31, 2007, 2008 and 2009		53
Consolidated Statements of Cash Flows for the years ended December 31, 2007, 2008 and 2009		54
Notes to the Consolidated Financial Statements		55

(2)

Schedule for the three years ended December 31, 2007, 2008 and 2009:
II — Valuation and Qualifying Accounts	95

(a) (3) and (b) Exhibits required by Item 601 of Regulation S-K:

94

NEUSTAR, INC.

SCHEDULE II — VALUATION AND QUALIFYING ACCOUNTS

	As of December 31,
	2007			2008			2009
	(In thousands)
Allowance for Doubtful Accounts
Beginning Balance	$	1,103		$	1,654		$	1,209
Additions		2,601			2,387			3,045
Reductions(1)		(2,050	)		(2,832	)		(2,829	)
Ending Balance	$	1,654		$	1,209		$	1,425
Deferred Tax Asset Valuation Allowance
Beginning Balance	$	1,011		$	1,787		$	2,864
Additions		776			1,420			15
Reductions		—			(343	)		(269	)
Ending Balance	$	1,787		$	2,864		$	2,610

(1) Includes the reinstatement and subsequent collections of account receivable that were previously written-off.

95

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
	(2	.1)	Agreement and Plan of Merger, dated as of April 19, 2006, by and among NeuStar, Inc., UDNS Merger Sub, Inc., UltraDNS Corporation, and Ron Lachman as the Holder Representative, incorporated herein by reference to Exhibit 2.1 to our Current Report on Form 8-K, filed April 25, 2006.
	(2	.2)	Agreement and Plan of Merger, dated as of November 27, 2006, by and among Neustar, Inc., Followap Inc., B&T Merger Sub, Inc. and Carmel V.C. Ltd. And Sequoia Seed Capital II L.P. (Israel), as Holder Representatives, incorporated herein by reference to Exhibit 2.1 to our Current Report on Form 8-K, filed November 27, 2006.
	(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 NeuStar’s Current Report on Form 8-K, filed September 16, 2008.
	(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 (a) Exhibit 10.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005; (b) Exhibit 10.1.1. to our Annual Report on Form 10-K, filed March 29, 2006; (c) Exhibit 10.1.2 to our Quarterly Report on Form 10-Q, filed August 14, 2006; (d) Exhibit 10.1.3 to our Quarterly Report on Form 10-Q, filed August 14, 2006**; (e) Exhibit 99.1 to our Current Report on Form 8-K, filed September 22, 2006; (f) Exhibit 10.1.1 to our Annual Report on Form 10-K, filed March 1, 2007; (g) Exhibit 10.1.2 to our Quarterly Report on Form 10-Q, filed November 5, 2007**, (h) Exhibit 10.1.1 to our Annual Report on Form 10-K, filed February 28, 2008, (i) Exhibit 10.1.2 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (j) Exhibit 99.1 to our Current Report on Form 8-K, filed on January 28, 2009; (k) Exhibit 10.1.3 to our Quarterly Report on Form 10-Q, filed on August 4, 2009; and (l) Exhibit 10.1.4 to our Quarterly Report on Form 10-Q, filed on October 30, 2009.
	10	.1.1	Amendment 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); (b) Exhibit 10.2.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005; (c) Exhibit 10.2.1 to our Annual Report on Form 10-K, filed March 29, 2006**; (d) Exhibit 10.2.2 to our Annual Report on Form 10-K filed March 29, 2006**; (e) Exhibit 10.2.3. to our Quarterly Report on Form 10-Q, filed August 14, 2006**; (f) Exhibit 10.2.1. to our Annual Report on Form 10-K, filed March 1, 2007**; (g) Exhibit 10.2.2 to our Annual Report on Form 10-K, filed March 1, 2007**; (h) Exhibit 10.2.3 to our Annual Report on Form 10-K, filed March 1, 2007**; (i) Exhibit 10.2.4 to our Quarterly Report on Form 10-Q, filed August 8, 2007**; (j) Exhibit 10.2.5 to our Quarterly Report on Form 10-Q, filed August 8, 2007**; (k) Exhibit 10.2.1 to our Annual Report on Form 10-K, filed February 28, 2008**; (l) Exhibit 10.2.2 to our Annual Report on Form 10-K, filed February 28, 2008**; (m) Exhibit 10.2.3 to our Quarterly Report on Form 10-Q, filed August 11, 2008; (n) Exhibit 10.2.4 to our Quarterly Report on Form 10-Q, filed August 11, 2008**; (o) Exhibit 10.2.5 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (p) Exhibit 10.2.6 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (q) Exhibit 10.2.2 to our Quarterly Report on Form 10-Q, filed August 4, 2009; and (r) Exhibit 10.2.3 to our Quarterly Report on Form 10-Q, filed August 4, 2009**.
	10	.2.1	Amendment to the contractor services agreement by and between Canadian LNP Consortium Inc. and NeuStar, Inc., as amended.

96

Exhibit Number			Description of Exhibit
	(10	.3)	National Thousands-Block Pooling Administration agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective August 14, 2007, incorporated herein by reference to (a) Exhibit 10.3 to our Quarterly Report on Form 10-Q, filed November 5, 2007**; (b) Exhibit 10.3.1 to our Annual Report on Form 10-K, filed February 28, 2008; (c) Exhibit 10.3.2 to our Quarterly Report on Form 10-Q, filed May 12, 2008; (d) Exhibit 10.3.3 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (e) Exhibit 10.3.2 to our Quarterly Report on Form 10-Q, filed May 11, 2009; (f) Exhibit 10.3.3 to our Quarterly Report on Form 10-Q, filed August 4, 2009; and (g) Exhibit 10.3.4 to our Quarterly Report on Form 10-Q, filed on October 30, 2009.
	(10	.4)	North American Numbering Plan Administrator agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective July 8, 2009, incorporated herein by reference to (a) Exhibit 10.4 to our Quarterly Report on Form 10-Q, filed on August 4, 2009; and (b) Exhibit 10.4.1 to our Quarterly Report on Form 10-Q, filed on October 30, 2009.
	(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 18, 2007, incorporated herein by reference to (a) Exhibit 10.5. to our Annual Report on Form 10-K, filed February 28, 2008, (b) Exhibit 10.5.1 to our Quarterly Report on Form 10-Q, filed May 12, 2008, (c) Exhibit 10.5.2 to our Quarterly Report on Form 10-Q, filed August 11, 2008, (d) Exhibit 10.5.3 to our Quarterly Report on Form 10-Q, filed November 10, 2008; and (e) Exhibit 10.5.1 to our Quarterly Report on Form 10-Q, filed August 4, 2009**.
	(10	.6)	Registry Agreement by and between the Internet Corporation for Assigned Names and Numbers and NeuStar, Inc., dated as of December 18, 2006, as amended, incorporated herein by reference to (a) Exhibit 10.6 to our Annual Report on Form 10-K, filed March 1, 2007; (b) Exhibit 10.6 to our Quarterly Report on Form 10-Q, filed August 8, 2007; (c) Exhibit 10.6.1 to our Quarterly Report on Form 10-Q, filed August 11, 2008; and (d) Exhibit 10.6.1 to our Quarterly Report on Form 10-Q, filed on August 4, 2009.
	(10	.7)	Amended and Restated Common Short Code License Agreement effective as of June 2, 2008, by and between the Cellular Telecommunications and Internet Association and NeuStar, Inc., incorporated herein by reference to (a) Exhibit 10.7 to our Quarterly Report on Form 10-Q, filed August 11, 2008** and (b) Exhibit 10.7.2 to our Quarterly Report on Form 10-Q, filed August 4, 2009.
	(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.51 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(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 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	.13)	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).†

97

Exhibit Number			Description of Exhibit
	(10	.14)	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).†
	(10	.15)	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	.16)	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	.17)	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	.18)	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	.19)	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	.20)	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	.21)	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).†
	(10	.22)	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	.23)	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	.24)	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	.25)	Credit Agreement, dated as of February 6, 2007, among NeuStar, Inc., JPMorgan Chase Bank, N.A., and other lenders, incorporated herein by reference to (a) Exhibit 10.1 to our Current Report on Form 8-K, filed February 9, 2007, and (b) Exhibit 10.31.1 to our Quarterly Report on Form 10-Q, filed November 5, 2007.
	(10	.26)	Guarantee Agreement dated February 6, 2007 among certain subsidiaries of NeuStar, Inc. in favor of JPMorgan Chase Bank, N.A., as administrative agent for the lenders, incorporated herein by reference to Exhibit 10.2 to our Current Report on Form 8-K, filed February 9, 2007.
	(10	.27)	NeuStar, Inc. Annual Performance Incentive Plan, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed July 13, 2007.†

98

Exhibit Number			Description of Exhibit
	(10	.28)	NeuStar, Inc. 2007 Key Employee Severance Pay Plan, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed July 13, 2007.†
	(10	.29)	Executive Relocation Policy, incorporated herein by reference to Exhibit 10.29 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†
	(10	.30)	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).†
	(10	.31)	Form of Nonqualified Stock Option Agreement under the 2005 Plan, incorporated herein by reference to Exhibit 99.4 to our Current Report on Form 8-K, filed March 5, 2007.†
	(10	.32)	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	.33)	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	.34)	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	.35)	Summary Description of Non-Management Director Compensation incorporated herein by reference to Exhibit 10.50 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(10	.36)	Form of Directors’ Restricted Stock Unit Agreement, incorporated herein by reference to (a) Exhibit 99.2 to our Current Report on Form 8-K, filed April 14, 2006 and (b) Exhibit 10.36 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†
	(10	.37)	Incentive Stock Option Agreement under the 1999 Plan, made as of November 18, 2004, by and between NeuStar, Inc. and John Spirtos, as amended as of May 20, 2005, incorporated herein by reference to Exhibit 10.52 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(10	.38)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of November 18, 2004, by and between NeuStar, Inc. and John Spirtos, as amended as of May 20, 2005, incorporated herein by reference to Exhibit 10.53 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(10	.39)	Agreement, dated December 8, 2008, by and between NeuStar, Inc. and Jeffrey E. Ganek, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed December 10, 2008.†
	(10	.40)	Employment Agreement, made as of February 5, 2008, by and between NeuStar, Inc. and Jeffrey Babka, incorporated herein by reference to Exhibit 99.1 to NeuStar’s Current Report on Form 8-K, filed February 11, 2008.†
	(10	.41)	Restricted Stock Agreement under the 2005 Stock Incentive Plan, made as of February 8, 2008, by and between NeuStar, Inc. and Jeffrey Babka, incorporated herein by reference to Exhibit 99.2 to NeuStar’s Current Report on Form 8-K, filed February 11, 2008.†
	(10	.42)	Performance Award Agreement under the 2005 Stock Incentive Plan, made as of February 8, 2008, by and between NeuStar, Inc. and Jeffrey Babka, incorporated herein by reference to Exhibit 99.3 to NeuStar’s Current Report on Form 8-K, filed February 11, 2008.†
	(10	.43)	Form of Performance Award Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.1 to NeuStar’s Current Report on Form 8-K/A, filed February 28, 2008.†
	(10	.44)	Form of Restricted Stock Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.2 to NeuStar’s Current Report on Form 8-K/A, filed February 28, 2008.†
	(10	.45)	Second Form of Restricted Stock Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.3 to NeuStar’s Current Report on Form 8-K/A, filed February 28, 2008.†

99

Exhibit Number			Description of Exhibit
	(10	.46)	Letter Agreement, dated May 5, 2008, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.50 to our Quarterly Report on Form 10-Q, filed August 11, 2008.**†
	(10	.47)	Senior Advisor Services Agreement, dated May 5, 2008, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.51 to our Quarterly Report on Form 10-Q, filed August 11, 2008.**†
	(10	.48)	Agreement Respecting Noncompetition and Nonsolicitation, dated May 5, 2008, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.52 to our Quarterly Report on Form 10-Q, filed August 11, 2008.
	(10	.49)	NeuStar, Inc. Deferred Compensation Plan, incorporated herein by reference to Exhibit 10.53 to our Quarterly Report on Form 10-Q, filed August 11, 2008.†
	(10	.50)	Incentive Stock Option Agreement under the 1999 Plan, made as of December 13, 2003, by and between NeuStar, Inc. and Martin Lowen, as amended as of June 22, 2004 and May 20, 2005, incorporated herein by reference to Exhibit 10.42 to our Quarterly Report on Form 10-Q, filed May 12, 2008.†
	(10	.51)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of December 13, 2003, by and between NeuStar, Inc. and Martin Lowen, as amended as of June 22, 2004 and May 20, 2005, incorporated herein by reference to Exhibit 10.43 to our Quarterly Report on Form 10-Q, filed May 12, 2008.†
	(10	.52)	Form of Agreement Respecting Noncompetition, Nonsolicitation and Confidentiality, incorporated herein by reference to Exhibit 10.41 to our Quarterly Report on Form 10-Q, filed May 12, 2008.
	(10	.53)	Employment Agreement, made as of January 15, 2009, by and between NeuStar, Inc. and Paul Lalljie, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed January 15, 2009, as superseded by Compensation Agreement, made as of December 9, 2009, by and between Neustar, Inc. and Paul Lalljie, incorporated herein by reference to Exhibit 99.1 to our Current Report on From 8-K, filed on December 15, 2009.†
	(10	.54)	NeuStar, Inc. 2009 Performance Achievement Reward Plan, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed February 27, 2009.†
	(10	.55)	Form of Performance Award Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed February 27, 2009.†
	(10	.58)	NeuStar, Inc. 2009 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed on April 13, 2009.†
	(10	.59)	Form of Nonqualified Stock Option Agreement under the NeuStar, Inc. 2009 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed December 15, 2009.†
	(10	.60)	Form of Performance Award Agreement under the NeuStar, Inc. 2009 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.3 to our Current Report on Form 8-K, filed December 15, 2009.†
	(10	.61)	Lease by and between Ridgetop Three, L.L.C. and NeuStar, Inc., incorporated herein by reference to Exhibit 10.1 to our Current Report on Form 8-K, filed January 22, 2010.
	(10	.62)	Amended and Restated Office Lease, dated May 29, 2009, by and between Merritt-LI1, LLC and NeuStar, Inc., incorporated herein by reference from Exhibit 99.1 to NeuStar’s Current Report on Form 8-K, filed June 2, 2009.
	(10	.63)	Amended and Restated Office Lease, dated May 29, 2009, by and between Merritt-LT1, LLC and NeuStar, Inc., incorporated herein by reference from Exhibit 99.2 to NeuStar’s Current Report on Form 8-K, filed June 2, 2009.
	(10	.64)	Letter Agreement, dated January 29, 2008, by and between NeuStar, Inc. and Larry Bouman, incorporated herein by reference to Exhibit 10.56 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†

100

Exhibit Number			Description of Exhibit
	(10	.65)	Restricted Stock Agreement between NeuStar, Inc. and Larry Bouman, dated January 18, 2008, incorporated herein by reference to Exhibit 10.57 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†
	(10	.66)	Form of Restricted Stock Agreement under the NeuStar, Inc. 2005 Stock Incentive 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	.67)	Form of Performance Award Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.3 to our Current Report on Form 8-K, filed July 13, 2007.†
	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 of Chief Executive Officer and Chief Financial Officer 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.
	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.

†	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

101

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 February 26, 2010.

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 February 26, 2010.

Signature	Title
/s/  Jeffrey E. Ganek Jeffrey E. Ganek	Chairman of the Board of Directors and Chief Executive Officer (Principal Executive Officer)
/s/  Paul S. Lalljie Paul S. Lalljie	Senior Vice President and Chief Financial Officer (Principal Financial Officer and Principal Accounting Officer)
/s/  Gareth Chang Gareth Chang	Director
/s/  James G. Cullen James G. Cullen	Director
/s/  Joel P. Friedman Joel P. Friedman	Director
/s/  Ross K. Ireland Ross K. Ireland	Director
/s/  Paul A. Lacouture Paul A. Lacouture	Director
/s/  Dr. Kenneth A. Pickar Dr. Kenneth A. Pickar	Director
/s/  Michael J. Rowny Michael J. Rowny	Director
/s/  Hellene S. Runtagh Hellene S. Runtagh	Director

102

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
	(2	.1)	Agreement and Plan of Merger, dated as of April 19, 2006, by and among NeuStar, Inc., UDNS Merger Sub, Inc., UltraDNS Corporation, and Ron Lachman as the Holder Representative, incorporated herein by reference to Exhibit 2.1 to our Current Report on Form 8-K, filed April 25, 2006.
	(2	.2)	Agreement and Plan of Merger, dated as of November 27, 2006, by and among Neustar, Inc., Followap Inc., B&T Merger Sub, Inc. and Carmel V.C. Ltd. And Sequoia Seed Capital II L.P. (Israel), as Holder Representatives, incorporated herein by reference to Exhibit 2.1 to our Current Report on Form 8-K, filed November 27, 2006.
	(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 NeuStar’s Current Report on Form 8-K, filed September 16, 2008.
	(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 (a) Exhibit 10.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005; (b) Exhibit 10.1.1. to our Annual Report on Form 10-K, filed March 29, 2006; (c) Exhibit 10.1.2 to our Quarterly Report on Form 10-Q, filed August 14, 2006; (d) Exhibit 10.1.3 to our Quarterly Report on Form 10-Q, filed August 14, 2006**; (e) Exhibit 99.1 to our Current Report on Form 8-K, filed September 22, 2006; (f) Exhibit 10.1.1 to our Annual Report on Form 10-K, filed March 1, 2007; (g) Exhibit 10.1.2 to our Quarterly Report on Form 10-Q, filed November 5, 2007**, (h) Exhibit 10.1.1 to our Annual Report on Form 10-K, filed February 28, 2008, (i) Exhibit 10.1.2 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (j) Exhibit 99.1 to our Current Report on Form 8-K, filed on January 28, 2009; (k) Exhibit 10.1.3 to our Quarterly Report on Form 10-Q, filed on August 4, 2009; and (l) Exhibit 10.1.4 to our Quarterly Report on Form 10-Q, filed on October 30, 2009.
	10	.1.1	Amendment 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); (b) Exhibit 10.2.1 to our Quarterly Report on Form 10-Q, filed August 15, 2005; (c) Exhibit 10.2.1 to our Annual Report on Form 10-K, filed March 29, 2006**; (d) Exhibit 10.2.2 to our Annual Report on Form 10-K filed March 29, 2006**; (e) Exhibit 10.2.3. to our Quarterly Report on Form 10-Q, filed August 14, 2006**; (f) Exhibit 10.2.1. to our Annual Report on Form 10-K, filed March 1, 2007**; (g) Exhibit 10.2.2 to our Annual Report on Form 10-K, filed March 1, 2007**; (h) Exhibit 10.2.3 to our Annual Report on Form 10-K, filed March 1, 2007**; (i) Exhibit 10.2.4 to our Quarterly Report on Form 10-Q, filed August 8, 2007**; (j) Exhibit 10.2.5 to our Quarterly Report on Form 10-Q, filed August 8, 2007**; (k) Exhibit 10.2.1 to our Annual Report on Form 10-K, filed February 28, 2008**; (l) Exhibit 10.2.2 to our Annual Report on Form 10-K, filed February 28, 2008**; (m) Exhibit 10.2.3 to our Quarterly Report on Form 10-Q, filed August 11, 2008; (n) Exhibit 10.2.4 to our Quarterly Report on Form 10-Q, filed August 11, 2008**; (o) Exhibit 10.2.5 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (p) Exhibit 10.2.6 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (q) Exhibit 10.2.2 to our Quarterly Report on Form 10-Q, filed August 4, 2009; and (r) Exhibit 10.2.3 to our Quarterly Report on Form 10-Q, filed August 4, 2009**.
	10	.2.1	Amendment to the contractor services agreement by and between Canadian LNP Consortium Inc. and NeuStar, Inc., as amended.

103

Exhibit Number			Description of Exhibit
	(10	.3)	National Thousands-Block Pooling Administration agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective August 14, 2007, incorporated herein by reference to (a) Exhibit 10.3 to our Quarterly Report on Form 10-Q, filed November 5, 2007**; (b) Exhibit 10.3.1 to our Annual Report on Form 10-K, filed February 28, 2008; (c) Exhibit 10.3.2 to our Quarterly Report on Form 10-Q, filed May 12, 2008; (d) Exhibit 10.3.3 to our Quarterly Report on Form 10-Q, filed November 10, 2008; (e) Exhibit 10.3.2 to our Quarterly Report on Form 10-Q, filed May 11, 2009; (f) Exhibit 10.3.3 to our Quarterly Report on Form 10-Q, filed August 4, 2009; and (g) Exhibit 10.3.4 to our Quarterly Report on Form 10-Q, filed on October 30, 2009.
	(10	.4)	North American Numbering Plan Administrator agreement awarded to NeuStar, Inc. by the Federal Communications Commission, effective July 8, 2009, incorporated herein by reference to (a) Exhibit 10.4 to our Quarterly Report on Form 10-Q, filed on August 4, 2009; and (b) Exhibit 10.4.1 to our Quarterly Report on Form 10-Q, filed on October 30, 2009.
	(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 18, 2007, incorporated herein by reference to (a) Exhibit 10.5. to our Annual Report on Form 10-K, filed February 28, 2008, (b) Exhibit 10.5.1 to our Quarterly Report on Form 10-Q, filed May 12, 2008, (c) Exhibit 10.5.2 to our Quarterly Report on Form 10-Q, filed August 11, 2008, (d) Exhibit 10.5.3 to our Quarterly Report on Form 10-Q, filed November 10, 2008; and (e) Exhibit 10.5.1 to our Quarterly Report on Form 10-Q, filed August 4, 2009**.
	(10	.6)	Registry Agreement by and between the Internet Corporation for Assigned Names and Numbers and NeuStar, Inc., dated as of December 18, 2006, as amended, incorporated herein by reference to (a) Exhibit 10.6 to our Annual Report on Form 10-K, filed March 1, 2007; (b) Exhibit 10.6 to our Quarterly Report on Form 10-Q, filed August 8, 2007; (c) Exhibit 10.6.1 to our Quarterly Report on Form 10-Q, filed August 11, 2008; and (d) Exhibit 10.6.1 to our Quarterly Report on Form 10-Q, filed on August 4, 2009.
	(10	.7)	Amended and Restated Common Short Code License Agreement effective as of June 2, 2008, by and between the Cellular Telecommunications and Internet Association and NeuStar, Inc., incorporated herein by reference to (a) Exhibit 10.7 to our Quarterly Report on Form 10-Q, filed August 11, 2008** and (b) Exhibit 10.7.2 to our Quarterly Report on Form 10-Q, filed August 4, 2009.
	(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.51 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(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 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	.13)	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).†

104

Exhibit Number			Description of Exhibit
	(10	.14)	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).†
	(10	.15)	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	.16)	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	.17)	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	.18)	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	.19)	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	.20)	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	.21)	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).†
	(10	.22)	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	.23)	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	.24)	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	.25)	Credit Agreement, dated as of February 6, 2007, among NeuStar, Inc., JPMorgan Chase Bank, N.A., and other lenders, incorporated herein by reference to (a) Exhibit 10.1 to our Current Report on Form 8-K, filed February 9, 2007, and (b) Exhibit 10.31.1 to our Quarterly Report on Form 10-Q, filed November 5, 2007.
	(10	.26)	Guarantee Agreement dated February 6, 2007 among certain subsidiaries of NeuStar, Inc. in favor of JPMorgan Chase Bank, N.A., as administrative agent for the lenders, incorporated herein by reference to Exhibit 10.2 to our Current Report on Form 8-K, filed February 9, 2007.
	(10	.27)	NeuStar, Inc. Annual Performance Incentive Plan, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed July 13, 2007.†

105

Exhibit Number			Description of Exhibit
	(10	.28)	NeuStar, Inc. 2007 Key Employee Severance Pay Plan, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed July 13, 2007.†
	(10	.29)	Executive Relocation Policy, incorporated herein by reference to Exhibit 10.29 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†
	(10	.30)	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).†
	(10	.31)	Form of Nonqualified Stock Option Agreement under the 2005 Plan, incorporated herein by reference to Exhibit 99.4 to our Current Report on Form 8-K, filed March 5, 2007.†
	(10	.32)	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	.33)	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	.34)	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	.35)	Summary Description of Non-Management Director Compensation incorporated herein by reference to Exhibit 10.50 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(10	.36)	Form of Directors’ Restricted Stock Unit Agreement, incorporated herein by reference to (a) Exhibit 99.2 to our Current Report on Form 8-K, filed April 14, 2006 and (b) Exhibit 10.36 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†
	(10	.37)	Incentive Stock Option Agreement under the 1999 Plan, made as of November 18, 2004, by and between NeuStar, Inc. and John Spirtos, as amended as of May 20, 2005, incorporated herein by reference to Exhibit 10.52 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(10	.38)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of November 18, 2004, by and between NeuStar, Inc. and John Spirtos, as amended as of May 20, 2005, incorporated herein by reference to Exhibit 10.53 to our Quarterly Report on Form 10-Q, filed August 8, 2007.†
	(10	.39)	Agreement, dated December 8, 2008, by and between NeuStar, Inc. and Jeffrey E. Ganek, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed December 10, 2008.†
	(10	.40)	Employment Agreement, made as of February 5, 2008, by and between NeuStar, Inc. and Jeffrey Babka, incorporated herein by reference to Exhibit 99.1 to NeuStar’s Current Report on Form 8-K, filed February 11, 2008.†
	(10	.41)	Restricted Stock Agreement under the 2005 Stock Incentive Plan, made as of February 8, 2008, by and between NeuStar, Inc. and Jeffrey Babka, incorporated herein by reference to Exhibit 99.2 to NeuStar’s Current Report on Form 8-K, filed February 11, 2008.†
	(10	.42)	Performance Award Agreement under the 2005 Stock Incentive Plan, made as of February 8, 2008, by and between NeuStar, Inc. and Jeffrey Babka, incorporated herein by reference to Exhibit 99.3 to NeuStar’s Current Report on Form 8-K, filed February 11, 2008.†
	(10	.43)	Form of Performance Award Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.1 to NeuStar’s Current Report on Form 8-K/A, filed February 28, 2008.†
	(10	.44)	Form of Restricted Stock Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.2 to NeuStar’s Current Report on Form 8-K/A, filed February 28, 2008.†
	(10	.45)	Second Form of Restricted Stock Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.3 to NeuStar’s Current Report on Form 8-K/A, filed February 28, 2008.†

106

Exhibit Number			Description of Exhibit
	(10	.46)	Letter Agreement, dated May 5, 2008, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.50 to our Quarterly Report on Form 10-Q, filed August 11, 2008.**†
	(10	.47)	Senior Advisor Services Agreement, dated May 5, 2008, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.51 to our Quarterly Report on Form 10-Q, filed August 11, 2008.**†
	(10	.48)	Agreement Respecting Noncompetition and Nonsolicitation, dated May 5, 2008, by and between NeuStar, Inc. and Mark Foster, incorporated herein by reference to Exhibit 10.52 to our Quarterly Report on Form 10-Q, filed August 11, 2008.
	(10	.49)	NeuStar, Inc. Deferred Compensation Plan, incorporated herein by reference to Exhibit 10.53 to our Quarterly Report on Form 10-Q, filed August 11, 2008.†
	(10	.50)	Incentive Stock Option Agreement under the 1999 Plan, made as of December 13, 2003, by and between NeuStar, Inc. and Martin Lowen, as amended as of June 22, 2004 and May 20, 2005, incorporated herein by reference to Exhibit 10.42 to our Quarterly Report on Form 10-Q, filed May 12, 2008.†
	(10	.51)	Nonqualified Stock Option Agreement under the 1999 Plan, made as of December 13, 2003, by and between NeuStar, Inc. and Martin Lowen, as amended as of June 22, 2004 and May 20, 2005, incorporated herein by reference to Exhibit 10.43 to our Quarterly Report on Form 10-Q, filed May 12, 2008.†
	(10	.52)	Form of Agreement Respecting Noncompetition, Nonsolicitation and Confidentiality, incorporated herein by reference to Exhibit 10.41 to our Quarterly Report on Form 10-Q, filed May 12, 2008.
	(10	.53)	Employment Agreement, made as of January 15, 2009, by and between NeuStar, Inc. and Paul Lalljie, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed January 15, 2009, as superseded by Compensation Agreement, made as of December 9, 2009, by and between Neustar, Inc. and Paul Lalljie, incorporated herein by reference to Exhibit 99.1 to our Current Report on From 8-K, filed on December 15, 2009.†
	(10	.54)	NeuStar, Inc. 2009 Performance Achievement Reward Plan, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed February 27, 2009.†
	(10	.55)	Form of Performance Award Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed February 27, 2009.†
	(10	.58)	NeuStar, Inc. 2009 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.1 to our Current Report on Form 8-K, filed on April 13, 2009.†
	(10	.59)	Form of Nonqualified Stock Option Agreement under the NeuStar, Inc. 2009 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.2 to our Current Report on Form 8-K, filed December 15, 2009.†
	(10	.60)	Form of Performance Award Agreement under the NeuStar, Inc. 2009 Stock Incentive Plan, incorporated herein by reference to Exhibit 99.3 to our Current Report on Form 8-K, filed December 15, 2009.†
	(10	.61)	Lease by and between Ridgetop Three, L.L.C. and NeuStar, Inc., incorporated herein by reference to Exhibit 10.1 to our Current Report on Form 8-K, filed January 22, 2010.
	(10	.62)	Amended and Restated Office Lease, dated May 29, 2009, by and between Merritt-LI1, LLC and NeuStar, Inc., incorporated herein by reference from Exhibit 99.1 to NeuStar’s Current Report on Form 8-K, filed June 2, 2009.
	(10	.63)	Amended and Restated Office Lease, dated May 29, 2009, by and between Merritt-LT1, LLC and NeuStar, Inc., incorporated herein by reference from Exhibit 99.2 to NeuStar’s Current Report on Form 8-K, filed June 2, 2009.
	(10	.64)	Letter Agreement, dated January 29, 2008, by and between NeuStar, Inc. and Larry Bouman, incorporated herein by reference to Exhibit 10.56 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†

107

Exhibit Number			Description of Exhibit
	(10	.65)	Restricted Stock Agreement between NeuStar, Inc. and Larry Bouman, dated January 18, 2008, incorporated herein by reference to Exhibit 10.57 to our Quarterly Report on Form 10-Q, filed August 4, 2009.†
	(10	.66)	Form of Restricted Stock Agreement under the NeuStar, Inc. 2005 Stock Incentive 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	.67)	Form of Performance Award Agreement under the NeuStar, Inc. 2005 Stock Incentive Plan, as amended, incorporated herein by reference to Exhibit 99.3 to our Current Report on Form 8-K, filed July 13, 2007.†
	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 of Chief Executive Officer and Chief Financial Officer 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.
	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.

†	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

108

EX-10.1.1

Exhibit 10.1.1

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

STATEMENT OF WORK NO. 76

UNDER

CONTRACTOR SERVICES AGREEMENT

FOR

NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE
MANAGEMENT SYSTEM

IMPLEMENTATION OF NANC 438

CONFIDENTIAL

Page 1

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

STATEMENT OF WORK NO. 76

UNDER

CONTRACTOR SERVICES AGREEMENT
FOR
NUMBER PORTABILITY ADMINISTRATION CENTER/SERVICE MANAGEMENT SYSTEM

Implementation of NANC 438

1. PARTIES

This Statement of Work No. 76 (this “Statement of Work” or “SOW”) is entered into pursuant to Article 13 and Article 30, and upon execution shall be a part of, the Contractor Services Agreements for Number Portability Administration Center/Service Management System, as amended and in effect immediately prior to the SOW Effective Date (each such agreement referred to individually as the “Master Agreement” and collectively as the “Master Agreements”), by and between NeuStar, Inc., a Delaware corporation (“Contractor”), and the North American Portability Management LLC, a Delaware limited liability company (the “Customer”), as the successor in interest to and on behalf of the Northeast Carrier Acquisition Company, LLC (the “Subscribing Customer”).

2. EFFECTIVENESS AND SUBSCRIBING CUSTOMERS

This Statement of Work shall be effective as of the last date of execution below (the “SOW Effective Date”), conditioned upon execution by Contractor and Customer on behalf of all the limited liability companies listed below for the separate United States Service Areas (the “Subscribing Customers”).

• Mid-Atlantic Carrier Acquisition Company, LLC

• LNP, LLC (Midwest)

• 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

The number in the upper left-hand corner refers to this Statement of Work. Capitalized terms used herein without definition or which do not specifically reference another agreement shall have the meanings as defined in the Master Agreement.

3. CONSIDERATION RECITAL

In consideration of the terms and conditions set forth in this Statement of Work, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged,

CONFIDENTIAL

Page 2

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

Contractor and Customer agree as set forth in this Statement of Work.

4. APPLICABLE DOCUMENTS

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

þ	Functional Requirements Specifications
None	Requirements Traceability Matrix
None	System Design
þ	Detailed Design
None	Integration Test Plan
None	System Test Plan
None	NPAC Software Development Process Plan
þ	User Documentation

Effective on the SOW Completion Date (defined below), the term Specifications as used in the Master Agreements shall mean the Specifications as defined therein and as modified and amended pursuant to Statements of Work under the Master Agreements through and including the Software release contemplated by this Statement of Work.

5. IMPACTS ON MASTER AGREEMENT

None	Master Agreement
þ	Exhibit B Functional Requirements Specification
þ	Exhibit C Interoperable Interface Specification
þ	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit J User Agreement Form
None	Exhibit K External Design
None	Exhibit L Infrastructure/Hardware
None	Exhibit M Software Escrow Agreement
None	Exhibit N System Performance Plan for NPAC/SMS Services
None	Disaster Recovery
None	Back Up Plans
None	Gateway Evaluation Process (Article 32 of Master Agreement)

6. SCOPE OF ADDITIONAL SERVICES

Contractor shall perform the Additional Services set forth herein. The Additional Services under this SOW consist exclusively of the work set forth in this Article 6 (collectively, the “Software Development Work”). The Additional Services under this SOW are an Enhancement to the NPAC/SMS Software as defined in the Master Agreement.

CONFIDENTIAL

Page 3

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

6.1 Software Development Work

The work necessary to incorporate the Change Order(s) set forth in Section 6.2 below into the NPAC/SMS Software in accordance with the project schedule set forth in Article 8 below shall be referred to collectively as the “Software Development Work.” The Software Development Work associated with the Change Order(s) includes the following activities: requirements definition; system design; coding and unit testing; system integration testing, system and regression testing; program management; quality assurance; configuration control and documentation management, as well as application support, customer support, and system administration support.

6.2 Change Order

The NPAC/SMS Software shall incorporate and provide the functionality of the NANC change order (“Change Order”) set forth immediately below.

NANC 438 — Last Alternative SPID

The existing Alternative SPID parameter was introduced to allow Service Providers having a wholesale business relationship with subtending Service Providers, such as resellers or class 2 interconnected VoIP providers, to identify the subtending Service Provider in the SV record created for a ported or pooled number. However, since the Alternative SPID was implemented, there have been occasions where the provider having the retail relationship with the end user also must be identified. Because the subtending Service Provider having the wholesale business relationship with the network Service Provider, and the subtending Service Provider having the retail business relationship with the end user, may be different entities, there is a need to have the ability to separately identify two Alternative SPID values.

The new alternate SPID parameter will be labeled “Last Alternative SPID,” to make clear its use is to identify the Service Provider having the retail relationship with the end user, and be added to the Optional Data field of the Subscription Version. To maintain backward compatibility, the name and XML label of the original Alternative SPID parameter will remain the same.

7. 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 shall not be interpreted, implied, or assumed to include any other service(s), including additional or changed services, not specifically described in Article 6 above. Any and all requested or required services or change orders (hereinafter “Out of Scope Services”) may be provided in accordance with Article 13 of the Master Agreement.

8. PROJECT PHASES

8.1 Phase Descriptions

Contractor shall perform the Additional Services in accordance with the schedule (the “Project

CONFIDENTIAL

Page 4

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

Phases”) set forth below.

Table 1 — Project Phases

Phases	Descriptions
Phase 0	Monday, January 8, 2010
Phase 1	Development and Internal Testing of Enhancement
Phase 1.1	Development of Enhancement — 3 weeks
Phase 1.2	Internal Acceptance Testing — 1 week
Phase 2	Enhancement available for Testing on Industry Test Bed — 2 weeks
Phase 3	Implementation of Enhancement — 1 week SOW Completion Date of Sunday, February 28, 2010

Phase 1 — Beginning on Monday, January 8, 2010, Contractor shall undertake all necessary development activities to implement the Enhancement. Contractor shall complete this Phase 1 no later than four (4) weeks thereafter.

Phase 2 — Upon completion of Phase 1.1, Contractor shall make the Enhancement available for optional regression testing on the industry test bed. For Users supporting the Enhancement that have not already been certified to use the Optional Data Parameter capability, the industry test bed also will be available for turn-up testing. Contractor shall maintain availability of the Industry Test Bed for these purposes for two (2) weeks.

Phase 3 — Upon completion of Phase 2, Contractor shall commence the introduction of the Enhancement in production into the Service Areas on the first maintenance window available for installation. Contractor shall introduce the Enhancement in the first Service Area on February 21, 2010 and in the next 6 Service Areas on February 28, 2010. The date on which the Enhancement is implemented in all regions shall be referred to as the “SOW Completion Date.”

8.2 Acceptance

If not accepted sooner by Customer, the Additional Services shall be deemed to have been accepted (“Acceptance”) upon the absence of written notice from Customer to Contractor identifying Critical Defects (as defined herein) in the Change Order functionality implemented hereunder as of fifteen (15) days after the SOW Completion Date. For purposes of this Section, a “Critical Defect” shall mean any functional defect in the Enhancement to be implemented by the Additional Services hereunder that prevents one or more Users from performing a create, activate, modify or delete of an Active SV. For such a defect to be considered a Critical Defect it must be reproducible and be one for which no acceptable alternative functionality can be identified.

9. APPROVAL OF LAST ALTERNATIVE SPID

As of the SOW Completion Date, the following new parameter of the Optional Data field introduced by the Change Orders shall be set forth in Footnote 5 of Exhibit E to the Master

CONFIDENTIAL

Page 5

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

Agreement in the list of Active SV fields, any of which if modified results in a TN Porting Event:

• Last Alternative SPID

This Article 9 does not otherwise amend or modify Footnote 5 of Exhibit E to the Master Agreement.

10. COMPENSATION AND PAYMENT

There is no cost to the Subscribing Customer or the Users in the Subscribing Customer’s Service Area for the performance of the Additional Services set forth herein.

11. MISCELLANEOUS

11.1 Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms. From and after the SOW Effective Date hereof, any reference in the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the SOW Effective Date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit, as modified and amended by this. From and after the SOW Effective Date, this Statement of Work shall be a part of the Master Agreement, including its Exhibits, and, as such, shall be subject to the terms and conditions therein. Each of the respective Master Agreements with respect to separate Service Areas remains an independent agreement regarding the rights and obligations of each of the Parties thereto with respect to such Service Area, and neither this Statement of Work nor any other instrument shall join or merge any Master Agreement with any other, except by the express written agreement of the Parties thereto.

11.2 If any provision of this SOW is held invalid or unenforceable the remaining provision of this SOW shall become null and void and be of no further force or effect. If by rule, regulation, order, opinion or decision of the Federal Communications Commission or any other regulatory body having jurisdiction or delegated authority with respect to the subject matter of this SOW or the Master Agreement, this SOW is required to be rescinded or is declared ineffective or void in whole or in part, whether temporarily, permanently or ab initio (an “Ineffectiveness Determination”), immediately upon such Ineffectiveness Determination and without any requirement on any party to appeal, protest or otherwise seek clarification of such Ineffectiveness Determination, this SOW shall be rescinded and of no further force or effect retroactively to the Amendment Effective Date. Consequently, the Master Agreement in effect immediately prior to the Amendment Effective Date shall continue in full force and effect in accordance with its terms, unchanged or modified in any way by this SOW. In the event of an Ineffectiveness Determination, any amounts that would have otherwise been due and payable under the terms and conditions of the Master Agreement, in effect immediately prior to the Amendment Effective

CONFIDENTIAL

Page 6

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

Date (including, but not limited to any adjustments necessary to retroactively re-price TN Porting Events under Exhibit E from the Amendment Effective Date through the date of the Ineffectiveness Determination, or other amounts or credits, to any party hereunder), shall be invoiced by Contractor at the earliest practical Billing Cycle in accordance with the Master Agreement and shall be due and payable in accordance with the applicable invoice therewith or shall be credited or applied for the benefit of the Customer or any Allocated Payor in accordance with the Master Agreement.

11.3 This Statement of Work may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document. All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

11.4 If at any time hereafter a Customer, other than a Customer that is a party hereto desires to become a party hereto, such Customer may become a party hereto by executing a joinder agreeing to be bound by the terms and conditions of this Statement of Work, as modified from time to time.

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

11.6 This Statement of Work sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto. The modifications, amendments and price concessions made herein were negotiated together and collectively, and each is made in consideration of all of the other terms herein. All such modifications, amendments and price concessions are interrelated and are dependent on each other. No separate, additional or different consideration is contemplated with respect to the modifications, amendments and price concessions herein.

[THIS SPACE INTENTIONALLY LEFT BLANK]

CONFIDENTIAL

Page 7

Amendment No. 76 (NE)
SOW:	o No
	þ Yes

IN WITNESS WHEREOF, the undersigned have executed this Statement of Work:

CONTRACTOR: NeuStar, Inc.
By:
	Its: VP — Customer Relations
	Date: Nov. 23, 2009

CUSTOMER: North American Portability Management LLC, as successor in interest to and on behalf of Northeast Carrier Acquisition Company, LLC

By:
	Its: NAPM LLC Co-Chair
	Date: Dec. 1, 2009
By:
	Its: NAPM LLC Co-Chair
	Date: Dec. 3, 2009

CONFIDENTIAL

Page 8

EX-10.2.1

Exhibit 10.2.1

Revision 1 to Amendment No. 60 (CA)
SOW:	No ü Yes

REVISION 1

TO

STATEMENT OF WORK

FOR

CANADIAN VIRTUAL POINT OF PRESENCE ACCESS TO
NPAC/SMS PRODUCTION COMPUTER SYSTEM AND NPAC/SMS
DISASTER RECOVERY COMPUTER SYSTEM

UNDER

CONTRACTOR SERVICES AGREEMENT FOR NUMBER
PORTABILITY ADMINISTRATION CENTER / SERVICE
MANAGEMENT SYSTEM

Page 1
CONFIDENTIAL

Revision 1 to Amendment No. 60 (CA)
SOW:	No ü Yes

REVISION 1

TO

STATEMENT OF WORK NO. 60 (CA)

UNDER

CONTRACTOR SERVICES AGREEMENT FOR NUMBER PORTABILITY
ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM

Canadian Virtual Point of Presence Access to NPAC/SMS Production Computer
System and NPAC/SMS Disaster Recovery Computer System

1. PARTIES

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

2. EFFECTIVENESS

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

3. REVISIONS

The second paragraph of Section 3.1 of SOW No. 60(CA) is hereby deleted in its entirety and replaced with the following:

Contractor shall notify the Customer in writing, at least ten (10) Business Days prior to the effective date, of any extension, renewal or other modification of the existing terms with Allstream, the underlying provider of VPOP services, and any other service terms with any other underlying provider with whom Contractor may enter into an agreement in substitution for the agreement with Allstream, regarding virtual point of presence (VPOP) services under this SOW. Notwithstanding the foregoing, Contractor shall not effect any such extension, renewal, or other modification, or enter into arrangements with any other underlying provider, to the extent any of the foregoing would impact any of Customer’s rights hereunder in any way, without obtaining Customer’s prior written consent.

Page 2
CONFIDENTIAL

Revision 1 to Amendment No. 60 (CA)
SOW:	No ü Yes

Article 5 of SOW No. 60(CA) is hereby deleted in its entirety and replaced with the following:

5. PROJECT SCHEDULE AND SOW TERM

Contractor shall provide the Additional Services contemplated under this SOW until the earlier of (a) November 15, 2010 and (b) termination or expiration of the Master Agreement (the “SOW Term”). This SOW will renew automatically for additional twelve-month periods on the same terms and conditions set forth herein at the then-current underlying costs (including any such costs that result in a Monthly Recurring Charge or Non-Recurring Fee) (and in accordance with Exhibit O of the Master Agreement) incurred by Contractor for the Additional Services, unless Customer provides notice of its intention not to renew this SOW no later than sixty (60) days prior to the expiration of the then-current SOW Term, and provided that Contractor notifies Customer of such underlying costs no less than one hundred twenty (120) days prior to such renewal date.

Except for the replacement of Section 3.1 and Article 5 of the SOW as set forth immediately above, all other terms of the SOW shall remain in full force and effect.

4. APPLICABLE DOCUMENTS

The following internal documents are applicable to the Additional Services contemplated under the SOW, as amended by this Revision:

N/A	Functional Requirements Specifications
N/A	Requirements Traceability Matrix
N/A	External Design
N/A	System Design
N/A	Detailed Design
N/A	Integration Test Plan
N/A	System Test Plan
N/A	Software Quality Assurance Program Report
ü	User Documentation
N/A	Software Configuration Management Plan
N/A	Standards and Metrics

5. IMPACTS ON MASTER AGREEMENT

The following portions of the Master Agreement are impacted by the SOW, as amended by this Revision:

None	Master Agreement
None	Exhibit B Functional Requirements Specification
None	Exhibit C Interoperable Interface Specification

Page 3
CONFIDENTIAL

Revision 1 to Amendment No. 60 (CA)
SOW:	No ü Yes

ü	Exhibit E Pricing Schedules
None	Exhibit F Project Plan and Test Schedule
None	Exhibit G Service Level Requirements
None	Exhibit H Reporting and Monitoring Requirements
None	Exhibit 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
ü	Exhibit O Statement of Work Cost Principles

6. CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT

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

7. MISCELLANEOUS

     7.1 Counterparts

This Revision may be executed in two or more counterparts and by different Parties hereto in separate counterparts, with the same effect as if all parties had signed the same document. All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.

     7.2 Entire Agreement

This Revision sets forth the entire understanding between the Parties with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.

[THIS SPACE INTENTIONALLY LEFT BLANK]

Page 4
CONFIDENTIAL

Revision 1 to Amendment No. 60 (CA)
SOW:	No ü Yes

IN WITNESS WHEREOF, the undersigned have executed and delivered this Revision 1 to SOW No. 60(CA):

CONTRACTOR: NeuStar, Inc.
Signature:	/s/ Michael O’Connor
	Name:	Michael O’Connor
	Title:	VP-Customer Relations

Date: Nov. 23, 2009

CUSTOMER: Canadian LNP Consortium Inc.
Signature:	/s/ JR SARRAZIN
	Name:	JR SARRAZIN
	Title:	PRESIDENT & CEO

Date: NOV 17, 2009

Page 5
CONFIDENTIAL

EX-21.1

Exhibit 21.1

Subsidiaries of the Registrant

Company Name	Jurisdiction of Organization
NeuStar GmbH	Germany
NeuStar NGM Services, Inc.	Delaware
NeuStar NGM Services Limited	United Kingdom
NeuStar R&D (Israel) Ltd.	Israel
NeuStar Secretariat Services, LLC	Delaware
NeuStar (UK) Limited	United Kingdom
UltraDNS 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., the Registration Statement (Form S-8 No. 333-151260) pertaining to the NeuStar, Inc. Deferred Compensation Plan, and the Registration Statement (Form S-8 No. 333-160236) pertaining to the NeuStar, Inc. 2009 Stock Incentive Plan, of our reports dated February 26, 2010, with respect to the consolidated financial statements and schedule of NeuStar, Inc., and the effectiveness of internal control over financial reporting of NeuStar, Inc. included in this Annual Report (Form 10-K) for the year ended December 31, 2009.

/s/ Ernst & Young LLP

McLean, Virginia
February 26, 2010

EX-31.1

Exhibit 31.1

CERTIFICATION
PURSUANT TO SECTION 302 OF THE SARBANES-OXLEY ACT OF 2002

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)) and internal control over financial reporting (as defined in Exchange Act Rules 13a-15(f) and 15d-15(f)) 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.	Designed such internal control over financial reporting, or caused such internal control over financial reporting to be designed under our supervision, to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with generally accepted accounting principles;
c.	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
d.	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.

February 26, 2010	/s/ Jeffrey E. Ganek
	Jeffrey E. Ganek
	Chairman and Chief Executive Officer (Principal Executive Officer)

EX-31.2

Exhibit 31.2

CERTIFICATION
PURSUANT TO SECTION 302 OF THE SARBANES-OXLEY ACT OF 2002

I, Paul S. Lalljie, 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)) and internal control over financial reporting (as defined in Exchange Act Rules 13a-15(f) and 15d-15(f)) 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.	Designed such internal control over financial reporting, or caused such internal control over financial reporting to be designed under our supervision, to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with generally accepted accounting principles;
c.	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
d.	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.

February 26, 2010	/s/ Paul S. Lalljie
	Paul S. Lalljie
	Chief Financial Officer (Principal Accounting 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 that, to the best of his knowledge:

1.	The annual report on Form 10-K of NeuStar, Inc. for the year ended December 31, 2009 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 operations of NeuStar, Inc.

February 26, 2010	By:	/s/ Jeffrey E. Ganek
		Jeffrey E. Ganek
		Chief Executive Officer
February 26, 2010	By:	/s/ Paul S. Lalljie
		Paul S. Lalljie
		Chief Financial Officer

     A signed original of this written 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.4ab

December January 822, 200910

Related Publications

NPAC SMS Interoperable Interface Specification (IIS), Version 3.3.4a December 8, 2009.

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 — 200910 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-1
0.3.1 Release 1.0	0-1
0.3.2 Release 2.0	0-2
0.3.3 Release 3.0	0-2
0.3.4 Release 3.1	0-2
0.3.5 Release 3.2	0-2
0.3.6 Release 3.3	0-3
0.3.7 Release 3.3.4	0-3
0.4 Abbreviations and Notations	0-40-3
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-2
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-3
1.2.9.3 Subscription Version Data	1-3
1.2.10 NPA-NXX Split Processing	1-3
1.2.11 Business Days/Hours	1-5
1.2.12 Timer Types	1-7
1.2.13 Recovery Functionality	1-8
1.2.13.1 Network Data Recovery	1-8
1.2.13.2 Subscription Data Recovery	1-9
1.2.13.3 Notification Recovery	1-9
1.2.13.4 Service Provider Data Recovery	1-9
1.2.14 Number Pooling Overview	1-10
1.2.15 Time References in the NPAC SMS	1-13
1.2.16 SV Type and Alternative SPID in the NPAC SMS	1-15
1.2.17 Alternative End User Location and Alternative Billing ID in the NPAC SMS	1-16
1.2.18 URIs in the NPAC SMS	1-16

Release 3.3: © 1997 — 200910 NeuStar, Inc.	i	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

1.2.19 Medium Timers for Simple Ports	1-16
1.2.19.1 Medium Timer Set	1-16
1.2.19.2 Medium Timer SV Attributes	1-17
1.3 Background	1-19
1.4 Objective	1-21
1.5 Assumptions	1-21
1.6 Constraints	1-23
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-1
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-2
2.1.4.3 Failure — notify NPAC	2-2
2.1.4.4 Initiate repair procedures	2-2
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-3
2.2.3 NPAC donor notification	2-3
2.2.4 NPAC performs broadcast download of disconnect data	2-3
2.3 Repair Service Process	2-4
2.3.2 Service provider analyzes the problem	2-4
2.3.3 Service provider performs repairs	2-4
2.3.4 Request broadcast of subscription data	2-5
2.3.5 Broadcast repaired subscription data	2-5
2.4 Conflict Process	2-5
2.4.1 Subscription version in conflict	2-5
2.4.1.1 Cancel-Pending Acknowledgment missing from new Service Provider	2-5
2.4.1.2 Old Service Provider requests conflict status	2-5
2.4.1.3 Change of status upon problem notification	2-5
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-6
2.4.2 New Service Provider coordinates conflict resolution activities	2-6
2.4.2.1 Cancel pending notification	2-6
2.4.3 Subscription version cancellation	2-7
2.4.4 Conflict resolved	2-7
2.5 Disaster Recovery and Backup Process	2-7
2.5.1 NPAC personnel determine downtime requirement	2-7

Release 3.3: © 1997 — 200910 NeuStar, Inc.	ii	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

2.5.2 NPAC notifies Service Providers of switch to backup NPAC and start of cutover quiet period	2-7
2.5.3 Service providers connect to backup NPAC	2-7
2.5.4 Backup NPAC notifies Service Providers of application availability and end of cutover quiet period	2-7
2.5.5 Service providers conduct business using backup NPAC	2-8
2.5.6 Backup NPAC notifies Service Providers of switch to primary NPAC and start of cutover quiet period	2-8
2.5.7 Service providers reconnect to primary NPAC	2-8
2.5.8 Primary NPAC notifies Service Providers of availability and end of cutover quiet period	2-8
2.6 Service Order Cancellation Process	2-8
2.6.1 Service Provider issues service order cancellation	2-8
2.6.2 Service provider cancels an un-concurred Subscription Version	2-8
2.6.3 NPAC requests missing acknowledgment from Service Provider	2-8
2.6.4 NPAC cancels the Subscription Version and notifies both Service Providers	2-9
2.7 Audit Request Process	2-9
2.7.1 Service provider requests audit	2-9
2.7.2 NPAC SMS issues queries to appropriate Service Providers	2-9
2.7.3 NPAC SMS compares Subscription Version data	2-9
2.7.4 NPAC SMS updates appropriate Local SMS databases	2-9
2.7.5 NPAC SMS sends report of audit discrepancies to requesting SOA	2-9
2.7.6 NPAC SMS sends report of audit results to requesting SOA	2-9
2.8 Report Request Process	2-10
2.8.1 Service provider requests report	2-10
2.8.2 NPAC SMS generates report	2-10
2.8.3 Report delivered via NPAC Administrative or SOA Low-Tech Interface, Email, electronic file, fax, printer	2-10
2.9 Data Administration Requests	2-10
2.9.1 Service provider requests administration of data by NPAC personnel	2-10
2.9.2 NPAC SMS personnel confirms user’s privileges	2-10
2.9.3 NPAC SMS personnel inputs user’s request	2-10
2.9.4 NPAC SMS performs user’s request	2-10
2.9.5 NPAC SMS personnel logs request denial if user’s privileges are not validated	2-11
3. NPAC DATA ADMINISTRATION	3-1
3.1 Overview	3-1
3.1.1 Data Type Legend	3-2
3.1.2 NPAC Customer Data	3-3
3.1.3 Subscription Version Data	3-14
3.1.4 Network Data	3-24
3.2 NPAC Personnel Functionality	3-26
3.2.1 Block Holder, Mass Update	3-28
3.2.2 Service Provider ID (SPID) Migration Update	3-28
3.3 System Functionality	3-32
3.4 Additional Requirements	3-36
3.4.1 NPA-NXX Data Validations	3-38
3.5 NPA Splits Requirements	3-39
3.5.1 NPA-NXX-X, NPA Splits	3-46
3.5.2 Block Holder, NPA Splits	3-49

Release 3.3: © 1997 — 200910 NeuStar, Inc.	iii	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

3.6 NPA-NXX Filter Management Requirements	3-51
3.7 Business Hour and Days Requirements	3-52
3.8 Notifications	3-54
3.8.1 TN Range Notification Indicator	3-54
3.8.2 Customer No New SP Concurrence Notification Indicator	3-54
3.8.3 SOA Notification Priority	3-55
3.8.4 TN and Number Pool Block in Notifications	3-56
3.9 Service Provider Support Indicators	3-57
3.9.1 SV Type and Alternative SPID Indicators	3-57
3.9.2 Alternative-End User Location and Alternative Billing ID Indicators	3-59
3.9.3 URI Indicators	3-60
3.9.4 Medium Timers Support Indicators	3-61
3.10 Multiple Service Provider Ids Per SOA Association Requirements	3-62
3.11 Bulk Data Download Functionality	3-64
3.11.1 Bulk Data Download Functionality — General	3-64
3.11.2 Network Data, Bulk Data Download	3-64
3.11.3 Subscription Version, Bulk Data Download	3-66
3.11.4 NPA-NXX-X Holder, Bulk Data Download	3-68
3.11.5 Block Holder, Bulk Data Downloads	3-69
3.11.6 Notifications, Bulk Data Download	3-70
3.11.7 Bulk Data Download Response Files	3-71
3.12 NPA-NXX-X Information	3-73
3.12.1 NPA-NXX-X Download Indicator Management	3-73
3.12.2 NPA-NXX-X Holder Information	3-74
3.12.3 NPA-NXX-X Holder, NPAC Scheduling/Re-Scheduling of Block Creation	3-76
3.12.4 NPA-NXX-X Holder, Addition	3-79
3.12.5 NPA-NXX-X Holder, Modification	3-81
3.12.6 NPA-NXX-X Holder, Deletion	3-82
3.12.7 NPA-NXX-X Holder, First Port Notification	3-84
3.12.8 NPA-NXX-X Holder, Query	3-85
3.12.9 NPA-NXX-X Holder, Bulk Data Download	3-85
3.13 Block Information	3-85
3.13.1 Version Status	3-85
3.13.2 Block Holder, General	3-88
3.13.3 Block Holder, Addition	3-98
3.13.4 Block Holder, Modification	3-100
3.13.5 Block Holder, Deletion	3-102
3.13.6 Block Holder, Query	3-103
3.13.7 Block Holder, Default Routing Restoration	3-103
3.13.8 Block Holder, Re-Send	3-104
3.13.9 Block Holder, Bulk Data Downloads	3-106
3.14 Linked Action Replies	3-106
3.15 GTT Validation Processing by the NPAC SMS	3-110
3.15.1 Sub System Number (SSN) Edit Flag Indicator	3-110
3.15.2 Global GTT Validations	3-112

Release 3.3: © 1997 — 200910 NeuStar, Inc.	iv	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

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
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-7
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-3
5.1.2 Subscription Administration Requirements	5-13
5.1.2.1 User Functionality	5-13
5.1.2.2 System Functionality	5-13
5.1.2.2.1 Subscription Version Creation	5-14
5.1.2.2.1.1 Subscription Version Creation — Inter-Service Provider Ports	5-14
5.1.2.2.1.2 Subscription Version Creation — Intra-Service Provider Port	5-22
5.1.2.2.2 Subscription Version Modification	5-27
5.1.2.2.2.1 Modification of a Pending or Conflict Subscription Version	5-27
5.1.2.2.2.2 Modification of an Active/Disconnect Pending Subscription Version	5-31
5.1.2.2.3 Subscription Version Conflict	5-36
5.1.2.2.3.1 Placing a Subscription Version in Conflict	5-36
5.1.2.2.3.2 Removing a Subscription Version from Conflict	5-38
5.1.2.2.4 Subscription Version Activation	5-40
5.1.2.2.5 Subscription Version Disconnect	5-45
5.1.2.2.6 Subscription Version Cancellation	5-50
5.1.2.2.6.1 Un-do a “Cancel-Pending” Subscription	5-54
5.1.2.2.7 Subscription Version Resend	5-55
5.1.3 Subscription Queries	5-59
5.1.3.1 User Functionality	5-59
5.1.3.2 System Functionality	5-59
5.1.4 Subscription Version Processing for National Number Pooling	5-65
5.1.4.1 Subscription Version, General	5-66
5.1.4.2 Subscription Version, Addition for Number Pooling	5-66
5.1.4.3 Subscription Version, Block Create Validation of Subscription Versions	5-68
5.1.4.4 Subscription Version, Modification for Number Pooling	5-69
5.1.4.5 Subscription Version, Deletion for Number Pooling	5-70
5.1.4.6 Subscription Version, Block Delete Validation of Subscription Versions	5-71
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	v	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

6.3 Interface Transactions	6-1
6.4 Interface and Protocol Requirements	6-1
6.4.1 Protocol Requirements	6-2
6.4.2 Interface Performance Requirements	6-2
6.4.3 Interface Specification Requirements	6-3
6.4.4 Request Restraints	6-4
6.4.5 Application Level Errors	6-4
6.5 NPAC SOA Low-tech Interface	6-6
6.6 CMIP Request Retry Requirements	6-8
6.7 Recovery —	6-9
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-23
6.8 Out-Bound Flow Control	6-24
6.9 Roll-Up Activity and Abort Behavior	6-25
6.10 NPAC Monitoring of SOA and LSMS Associations	6-26
6.11 Separate SOA Channel for Notifications	6-28
6.12 Maintenance Window Timer Behavior	6-29
7. SECURITY	7-1
7.1 Overview	7-1
7.2 Identification	7-1
7.3 Authentication	7-2
7.3.1 Password Requirements	7-3
7.4 Access Control	7-4
7.4.1 System Access	7-4
7.4.2 Resource Access	7-7
7.5 Data and System Integrity	7-8
7.6 Audit	7-9
7.6.1 Audit Log Generation	7-9
7.6.2 Reporting and Intrusion Detection	7-11
7.7 Continuity of Service	7-12
7.8 Software Vendor	7-13
7.9 OSI Security Environment	7-13

Release 3.3: © 1997 — 200910 NeuStar, Inc.	vi	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

7.9.1 Threats	7-13
7.9.2 Security Services	7-13
7.9.3 Security Mechanisms	7-14
7.9.3.1 Encryption	7-14
7.9.3.2 Authentication	7-15
7.9.3.3 Data Origin Authentication	7-15
7.9.3.4 Integrity and Non-repudiation	7-15
7.9.3.5 Access Control	7-16
7.9.3.6 Audit Trail	7-16
7.9.3.7 Key Exchange	7-16
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-5
8.7 Database Integrity Sampling	8-6
8.8 Audit Processing in a Number Pool Environment	8-6
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-3
9.3.2 Cause Code Reports	9-6
9.3.3 Resend Excluded Service Provider Report	9-6
10. PERFORMANCE AND RELIABILITY	10-10
10.1 Availability and Reliability	10-10
10.2 Capacity and Performance	10-12
10.3 Requirements in RFP Not Given a Unique ID	10-13
11. BILLING	11-1
11.1 User Functionality	11-1

Release 3.3: © 1997 — 200910 NeuStar, Inc.	vii	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Table of Contents

11.2 System Functionality 11-1

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 — 200910 NeuStar, Inc.	viii	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

List of Figures

List of Figures

Figure 1 — Entity Relationship Model	3-2
Figure 2 — Number Pool Block Version Status Interaction Diagram	3-86
Figure 3 — Subscription Version Status Interaction Diagram	5-3
Figure A- 1 — NPAC Business Process Flows Legend	A-2
Figure A- 2 — NPAC SMS Provision Service Process	A-3
Figure A- 3 — Flow 2.1.2 NPAC SMS Subscription Version Creation Process	A-4
Figure A- 4 — Flow 2.1.4 NPAC SMS Activate and Data Download Process	A-5
Figure A- 5 — Flow 2.2 NPAC SMS Disconnect Process	A-6
Figure A- 6 — Flow 2.3 NPAC SMS Repair Process	A-7
Figure A- 7 — Flow 2.4.1 Conflict Process	A-8
Figure A- 8 — Flow 2.5 NPAC SMS Disaster Recovery Process	A-9
Figure A- 9 — Flow 2.6 Cancellation Process	A-10
Figure A- 10 — Flow 2.7 Audit Process	A-11
Figure A- 11 — Flow 2.8 Report Process	A-12
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- 3 — Network NPA-NXX Download File Example	E-6
Figure E- 4 — Network LRN Download File Example	E-7
Figure E- 5 — Network NPA-NXX-X Download File Example	E-8
Figure E- 6 — Block Download File Example	E-9

Release 3.3: © 1997 — 200910 NeuStar, Inc.	ix	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

List of Tables

List of Tables

Table 0-1 Notation Key	0-60-5
Table 0-2 Language Key	0-60-5
Table 1-1 Business Day/Hour Behavior	1-6
Table 1-2 Timer Type Behaviour	1-7
Table 1-3 Vacant Number Treatment/Snapback Notification	1-13
Table 3-1 Data Type Legend	3-3
Table 3-2 NPAC Customer Data Model	3-12
Table 3-3 NPAC Customer Contact Data Model	3-13
Table 3-4 NPAC Customer Network Address Data Model	3-14
Table 3-5 NPAC Customer Associated Service Provider Data Model	3-14
Table 3-6 Subscription Version Data Model	3-19
Table 3-7 Subscription Version Failed SP List Data Model	3-20
Table 3-8 Number Pooling Block Holder Information Data Model	3-23
Table 3-9 Number Pooling Block Failed SP List Data Model	3-24
Table 3-10 Portable NPA-NXX Data Model	3-24
Table 3-11 LRN Data Model	3-25
Table 3-12 LSMS Filtered NPA-NXX Data Model	3-25
Table 3-13 Number Pooling NPA-NXX-X Holder Information Data Model	3-26
Table 3-14 Number Pool Block Version Status Interaction Descriptions	3-88
Table 5-1 Subscription Version Status Interaction Descriptions	5-8
Table 6-1 Interface Protocol Stack	6-2
Table C- 1 — Subscription Tunables	C-5
Table C- 2 — Communications Tunables	C-9
Table C- 3 — Audit Tunables	C-10
Table C- 4 — Logs Tunables	C-10
Table C- 5 — Keys Tunables	C-11
Table C- 6 — Block Tunables	C-11
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-7

Release 3.3: © 1997 — 200910 NeuStar, Inc.	x	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

List of Tables

Table E- 5 — Explanation of the Fields in the Network NPA-NXX-X Download File	E-8
Table E- 6 — Explanation of the Fields in The Block Download File	E-11

Release 3.3: © 1997 — 200910 NeuStar, Inc.	xi	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	0-0	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Preface

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	0-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Preface

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	0-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Preface

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.2a, released on 3/7/2006 contains the following changes from the NANC FRS Version 3.3.1a:

NANC version 3.3.3a, released on 2/28/2007 contains the following changes from the NANC FRS Version 3.3.2a:

• Documentation only changes contained in Change Order NANC 412 Doc Only Change Order: FRS

• Documentation only changes contained in Change Order NANC 388v2 Un-Do a “Cancel Pending” SV

0.3.7 Release 3.3.4

NANC version 3.3.4a, released on 12/8/2009 contains the following changes from the NANC FRS Version 3.3.3a:

• Change Order NANC 416 — BDD File for Notifications — Adding New Attributes

• Change Order NANC 429 — URI Fields (Voice)

• Change Order NANC 430 — URI Fields (MMS)

• Change Order NANC 435 — URI Fields (SMS)

• Change Order NANC 436 — Optional Data — alternative End User Location and alternative Billing ID

• Change Order NANC 438 — Last Alternative SPID

• Change Order NANC 440 — FCC Order, Medium Timers

• Change Order NANC 441 — FCC Order, SOA Indicator

NANC version 3.3.4b, released on 1/22/2010 contains numbering corrections from the NANC FRS Version 3.3.4a.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	0-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Preface

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:

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	0-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Preface

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 — 200910 NeuStar, Inc.	0-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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, should	Use of the terms “is,” “will,” or “should” in this document is intended to identify guidance or preference. Statements annotated in this manner are to be treated as informative or preference, but not required. Statements following the words “is,” “will,” or “should” are not a mandatory deliverable for the final system.

Table 0-2 Language Key

Release 3.3: © 1997 — 200910 NeuStar, Inc.	0-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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 — 200910 NeuStar, Inc.	1-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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
Service	Business
Provider	Type	Short	Long (Non-Simple Port)	Long (Simple Port)
	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. No action is necessary by either the old or new service provider operations personnel.	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. 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.	When the new service provider supports short business days/hours and the old service provider supports long business days/hours for a subscription version port, and the port is designated as simple, medium business days/hours will be used. The old service provider who supports the long business days/hours will have to recognize that the medium business days/hours are being used instead of the expected long business days/hours.
	Long (Non-Simple Port)	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. 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.	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.	When both the old and new service providers support long business days/hours for a subscription version port long business days/hours will be used. No action is necessary by either the old or new service provider operations personnel.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

	OLD Service Provider
New
Service	Business
Provider	Type	Short	Long (Non-Simple Port)	Long (Simple Port)
	Long (Simple Port)	When the new service provider supports short business days/hours and the old service provider supports long business days/hours for a subscription version port, and the port is designated as simple, medium business days/hours will be used. The old service provider who supports the long business days/hours will have to recognize that the medium business days/hours are being used instead of the expected long business days/hours.	When both the old and new service providers support long business days/hours for a subscription version port long business days/hours will be used. No action is necessary by either the old or new service provider operations personnel.	When both the old and new service providers support long business days/hours for a subscription version port, and the port is designated as simple, medium business days/hours will be used. No action is necessary by either the old or new service provider operations personnel.

Table 1-1 Business Day/Hour Behavior

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

1.2.12 Timer Types

For support of service providers that have different needs for timers available for porting, three types of timers have been defined in the NPAC SMS. The three types are long, medium and short timers.

The following table illustrates the outcome of timers to be used based on the possible combinations:

	OLD Service Provider
New
Service	Timer		Port Out- Long	Port Out- Long
Provider	Type	Port Out- Short	(Non-Simple Port)	(Simple Port)
	Port In — Short	When both the old and new service providers support short timers for a subscription version port short timers will be used. No action is necessary by either the old or new service provider operations personnel.	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. 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.	When the new service provider supports short timers and the old service providers supports long timers for a subscription version port, and the port is designated as simple, medium timers will be used. The new service provider who supports the short timers will have to recognize that the medium timers are being used instead of the expected short timers.
	Port In — Long (Non-Simple Port)	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. 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.	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.	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.
	Port In- Long (Simple Port)	When the new service provider supports short timers and the old service providers supports long timers for a subscription version port, and the port is designated as simple, medium timers will be used. The new service provider who supports the short timers will have to recognize that the medium timers are being used instead of the expected short timers.	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.	When both the old and new service providers support long timers for a subscription version port and the port is designated as simple, medium timers will be used. No action is necessary by either the old or new service provider operations personnel.

Table 1-2 Timer Type Behaviour

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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).
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 Treatment	Pre effective date	post effective date	post Block activation	during Block de-pool
Contaminated disconnect	Code holder	Code holder	Block holder	Code holder
Non-contaminated	Code holder	Code holder	Block holder	Code holder
Snapback for TN re-assignment
Contaminated disconnect	Code holder*	Block holder	Block holder	Code holder*
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, medium and long)
4.	NPAC parameters

a. Short Business Day Start Time

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

b.	Medium Business Day Start Time
c.	Long Business Day Start Time
d.	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
Wireline or Inter-modal simple port	Medium Business Days	Monday — Friday (five days)
	Medium Business Day Start Time	13:00/12:00 GMT (for eastern regions)
		14:00/13:00 GMT (for central regions)
		14:00/13:00 GMT (for Canadian region)
		15:00/14:00 GMT (for mountain region)
		16:00/15:00 GMT (for pacific region)
	Medium Business Day Duration	17 hours

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

Using this information, the region equivalents are defined by the table below:

		SPs using Medium
Region	SPs using Short Hours/Days	Hours/Days	SPs using Long Hours/Days
NE	Monday — Friday, 8a-8p ET	Monday — Friday, 8a-12a ET	Sunday — Saturday, 9a-9p ET
MA	Monday — Friday, 8a-8p ET	Monday — Friday, 8a-12a ET	Sunday — Saturday, 9a-9p ET
SE	Monday — Friday, 8a-8p ET	Monday — Friday, 8a-12a ET	Sunday — Saturday, 9a-9p ET
MW	Monday — Friday, 7a-7p CT	Monday — Friday, 8a-12a CT	Sunday — Saturday, 9a-9p CT
SW	Monday — Friday, 7a-7p CT	Monday — Friday, 8a-12a CT	Sunday — Saturday, 9a-9p CT
WE	Monday — Friday, 6a-6p MT	Monday — Friday, 8a-12a MT	Sunday — Saturday, 9a-9p MT
WC	Monday — Friday, 5a-5p PT	Monday — Friday, 8a-12a PT	Sunday — Saturday, 9a-9p PT
CA	Monday — Friday, 7a-7p CT	Monday — Friday, 8a-12a CT	Sunday — Saturday, 9a-9p CT

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.	Medium Business Day Start Time
3.	Long Business Day Start Time
4.	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, Medium 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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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.

The NPAC SMS shall provide a Last Alternative SPID field for each SV and Pooled Block record. This new field shall identify (if applicable) a subtending service provider that has a retail relationship with the end user. The Last Alternative SPID must be a valid SPID defined in the NPAC SMS database. Last Alternative SPID is an optional attribute in a SV or Pooled Block record, even if it is supported by the Service Provider.

1.2.17 Alternative End User Location and Alternative Billing ID in the NPAC SMS

With implementation of software release 3.3.3.2 (NANC 436), the NPAC SMS shall provide Alternative End User Location and Alternative Billing ID fields for each SV and Pooled Block record. These new fields shall identify (if applicable) an alternative value to the existing End User Location and Billing ID fields associated with each TN or Pooled Block. 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 these fields for those SOA and LSMS associations optioned “on” to send and receive this data. These alternative fields are optional attributes in a SV or Pooled Block record, even if it is supported by the Service Provider.

1.2.18 URIs in the NPAC SMS

With implementation of software release 3.3.3.5 (NANC 429, NANC 430, NANC 435), the NPAC SMS shall provide URI fields for each SV and Pooled Block record. These new fields shall identify (if applicable) a Voice URI, MMS URI, and/or SMS URI associated with each TN or Pooled Block. 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 URIs for those SOA and LSMS associations optioned “on” to send and receive this data. The URIs are optional attributes in a SV or Pooled Block record, even if it is supported by the Service Provider.

1.2.19 Medium Timers for Simple Ports

With implementation of software release 3.3.4 (NANC 440, NANC 441) to implement functionality for FCC Order 09-41, the NPAC SMS will provide a new set of Timers (Medium) applicable to SV records for simple ports (wireline, intermodal).

In the Service Provider Profile, a new support tunable will be added. This indicator will identify whether or not an SP supports the use of the Medium Timers. This is needed because of the two-stage implementation (nine months for large carriers, and fifteen months for small carriers), as well as carriers that may obtain a waiver from the FCC on implementation.

1.2.19.1 Medium Timer Set

The Medium Timer set includes the following:

• Medium Initial Concurrence Timer (i.e., T1) — defaulted to three (3) NPAC business hours

• Medium Final Concurrence Timer (i.e., T2) — defaulted to three (3) NPAC business hours

• Medium Conflict Restriction Window — defaulted to 21:00 in the predominate time zone (Mon-Fri, excluding NPAC-defined holidays, adjusted for Standard/Daylight) on the day before the due date (adjusted for Standard/Daylight)

• Medium Conflict Resolution Restriction Window — defaulted two (2) NPAC business hours

• Medium Initial Cancellation Acknowledgement Timer — defaulted to nine (9) NPAC business hours

• Medium Final Cancellation Acknowledgement Timer — defaulted to nine (9) NPAC business hours

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

• Medium Business Day Start — defaulted to 07:00 in the predominate time zone (Mon-Fri, excluding NPAC-defined holidays, adjusted for Standard/Daylight)

• Medium Business Day Duration — defaulted to 17 clock hours

• Medium Business Days — defaulted to Monday-Friday

The Medium Timer set will be used by the NPAC based on a combination of information provided by both SOAs (New SP and Old SP) and SP Profile settings of both SOAs. Timer Type and Business Type will be broadcast to the SOAs upon creation/concurrence of the SV (object creation notification and attribute value change notification), for those SOA associations optioned “on” to receive this data (Timer Type and Business Type). This new value for the existing attributes shall be added to the notification Bulk Data Download file, and be available to a Service Provider’s SOA. This new value for the existing attributes will be supported across the interface on an opt-in basis only and will be functionally backward compatible.

1.2.19.2 Medium Timer SV Attributes

The Medium Timer SV attributes are:

• New SP Medium Timer Indicator

• Old SP Medium Timer Indicator

If a SOA supports the New SP/Old SP Medium Timer Indicator (based on the Medium Timers Support Indicator setting), the new attribute must be sent up in their inter-SP SV Create message, otherwise the message will be rejected. If a SOA does not support the New SP/Old SP Medium Timer Indicator the new attribute must not be sent in the inter-SP SV Create message, if sent the message will be rejected. If a SOA that supports the New SP/Old SP Medium Timer Indicator sends up the new attributes in an intra-SP SV Create message, the attributes are ignored.

Since only the Old SP is in a definitive position to determine if a port is simple:

• Modify requests from the New SP for the New SP Medium Timer Indicator will be supported only until the Old SP sends their Create message.

• Modify requests from the Old SP for the Old SP Medium Timer Indicator will be supported until the port is activated.

Modifies of the Old or New Medium Timer Indicator will cause a restart to T1 when the NPAC has received a create message from only one service provider. If both create messages have been received, T1 will not be restarted. Because the T1 timer can be restarted, New Service Providers may need to be included in the notification of T2 expirations for Old Service Provider concurrence. A Service Provider notification priority category will be added to allow a Service Provider to opt-in on receiving T2 expiration notifications as the New Service Provider for lack of Old Service Provider concurrence. Sending a notification to the New Service Provider at T2 expiration avoids the need for the New Service Provider to track NPAC timers, which eliminates the need to inform the New Service Provider of a new timestamp when T1/T2 is restarted. In cases where a modify request was sent with the same value (true -> true, false -> false), a notification will still be sent (as done with current behavior on modifies to the same value), but the T1/T2 will not be cancelled, T1 will not be restarted, and neither Timer Type nor Business Type will be included in the notification.

The NPAC will use the values of the New SP/Old SP Medium Timer Indicators sent in the SV Create messages (or information in the SP Profile if not supported) to determine the usage of the Medium Timers for a given SV. This New SP/Old SP Medium Timer Indicator information will be broadcast to the SOAs upon creation/concurrence of the SV (object creation notification and attribute value change notification), for those SOA associations optioned “on” to send and receive this data (NANC 440, Medium Timers Support Indicator).

When both SPs support the Medium Timers Support Indicators, and the values specified by the New Service Provider and Old Service Provider are different, the value specified by the Old Service Provider will prevail (if necessary, the SV Timer Type and Business Type will be changed). Even though T1 and T2 concurrence timers have expired, the change is applicable because subsequent conflict or cancellation acknowledgement timers will use the value contained in the Timer Type attribute and Business Type attribute on the SV to determine conflict or cancellation duration. This updated Timer Type and Business Type information will be sent to both the New

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

Service Provider and the Old Service Provider in an Attribute Value Change notification. If Old Service Provider does not send up a Create, the SV would remain with whatever value is specified in the New Service Provider Create. These new attributes shall be added to the notification Bulk Data Download file, and be available to a Service Provider’s SOA. These new attributes will be supported across the interface on an opt-in basis only and will be functionally backward compatible.

All references in the Processing Rules below that refer to “Short” and “Long” relate to the Timer Type settings in the Service Provider’s Profile (Port-In Timer Type, Port-Out Timer Type).

Processing Rules where both SPs do not support the Medium Timers Support Indicator:

• BAU (Business As Usual)

• Short + Short = Short

• Everything else =Long

Processing Rules where both SPs do support the Medium Timers Support Indicator:

• NSP is Short, OSP is Short, SV is Short regardless of Indicators

• NSP is Short, OSP is Long, (Note: NSP Short/OSP Long, NSP Long/OSP Short, and NSP Long/OSP Long all have the same behavior.)

• NSP is First Create,

• SOA Indicator on SV Create is F (non-simple), SV uses Long,

• OSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV switches to Medium

• OSP does not concur, SV remains Long

• SOA Indicator on SV Create is T (simple), SV uses Medium,

• OSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV switches to Long

• SOA Indicator on SV Create is T (simple), SV remains Medium

• OSP does not concur, SV remains Medium

• OSP is First Create,

• SOA Indicator on SV Create is F (non-simple), SV uses Long,

• NSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV uses Medium,

• NSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Medium

• SOA Indicator on SV Create is T (simple), SV remains Medium

• NSP is Long , OSP is Short, (Note: NSP Short/OSP Long, NSP Long/OSP Short, and NSP Long/OSP Long all have the same behavior.)

• NSP is First Create,

• SOA Indicator on SV Create is F (non-simple), SV uses Long,

• OSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV switches to Medium

• OSP does not concur, SV remains Long

• SOA Indicator on SV Create is T (simple), SV uses Medium,

• OSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV switches to Long

• SOA Indicator on SV Create is T (simple), SV remains Medium

• OSP does not concur, SV remains Medium

• OSP is First Create,

• SOA Indicator on SV Create is F (non-simple), SV uses Long,

• NSP is second Create,

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

• SOA Indicator on SV Create is F (non-simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV uses Medium,

• NSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Medium

• SOA Indicator on SV Create is T (simple), SV remains Medium

• NSP is Long , OSP is Long, (Note: NSP Short/OSP Long, NSP Long/OSP Short, and NSP Long/OSP Long all have the same behavior.)

• NSP is First Create,

• SOA Indicator on SV Create is F (non-simple), SV uses Long,

• OSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV switches to Medium

• OSP does not concur, SV remains Long

• SOA Indicator on SV Create is T (simple), SV uses Medium,

• OSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV switches to Long

• SOA Indicator on SV Create is T (simple), SV remains Medium

• OSP does not concur, SV remains Medium

• OSP is First Create,

• SOA Indicator on SV Create is F (non-simple), SV uses Long,

• NSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV remains Long

• SOA Indicator on SV Create is T (simple), SV uses Medium,

• NSP is second Create,

• SOA Indicator on SV Create is F (non-simple), SV remains Medium

• SOA Indicator on SV Create is T (simple), SV remains Medium

Anytime the NPAC sets the Timer Type to Medium for a port, the Business Type will also be set to Medium (e.g., Medium Timers, Medium Business Hours and Medium Business Days are assigned as a complete set).

1.3 Background

Release 1.0

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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

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

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.4 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality to support FCC Order 09-41, One Business Day Simple Ports.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	1-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Introduction

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 — 200910 NeuStar, Inc.	1-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

2.1.4.1 New Service Provider sends activation to NPAC SMS

The new Service Provider sends an activate notification to the NPAC SMS. 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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

2.2.1 Customer notification, Service Provider initial disconnect service order activities

When a ported number is being disconnected, the customer and Service Provider will agree on a date. The Service Provider will send a notification to the NPAC SMS indicating the date of the physical disconnect of the number and, optionally, the date that the disconnect information is to be broadcast to all Local SMSs (the ‘effective release date’).

2.2.2 NPAC waits for effective release date

The NPAC SMS will send delete actions containing the disconnect information based on the effective release date specified by the Service Provider. If no effective release date is specified on the disconnect request, the NPAC SMS processes the request immediately.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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.

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

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 — 200910 NeuStar, Inc.	2-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	2-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flows

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 — 200910 NeuStar, Inc.	2-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

Figure 1 — Entity Relationship Model

3.1.1 Data Type Legend

The following table describes the data types used in the data models.

DATA TYPE LEGEND
Data Type	Description
Address	Network Address: raw binary data stored as unformatted bytes.
B	Boolean (True or False) indicator.
C	Character or Alphanumeric strings.
E	Enumeration.
M	Bit Mask comprised of one or more bytes.
N	Numeric data (up to 32 bit integer, numeric data that can be arithmetically manipulated).
N(x)	Character string of “x” digits only.
T	Timestamp: month, day, year, hour, minute, and seconds.
TN	Telephone Number: 3-digit NPA, 3-digit NXX, 4-digit Station Number.

Table 3-1 Data Type Legend

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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
	Type
Attribute Name	(Size)	Required	Description
NPAC Customer ID	C (4)	Ö	An alphanumeric code which uniquely identifies an NPAC Customer.
NPAC Customer Name	C (40)	Ö	A unique NPAC Customer Name.
NPAC Customer Allowable Functions	M	Ö	Each bit in the mask represents a Boolean indicator for the following functional options:
			•   SOA Management •   SOA Network Data Management •   SOA Data Download •   LSMS Network Data Management •   LSMS Data Download •   LSMS Queries/Audits
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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
			•   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 Cannot select Medium Timers as a default value. Medium Timers are derived based on information from the New SP and Old SP.
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 Cannot select Medium Timers as a default value. Medium Timers are derived based on information from the New SP and Old SP.
Business Hour/Days	E	Ö	Business Hours supported by the Service Provider:
			S — Short Business Hours L — Long Business Hours Cannot select Medium Business Hours as a default value. Medium Business Hours are derived based on information from the New SP and Old SP.
NPAC Customer SOA NPA-NXX-X Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer accepts NPA-NXX-X downloads 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
			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 C-7 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 Indicator	B	Ö	A Boolean that indicates whether or not the 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	N	Ö	A Service Provider specific tunable indicating the maximum number of TNs that

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
Request			can be recovered in a single time-based, recovery request. Valid range is 1-10000. 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 Heartbeat Indicator	B	Ö	A Service Provider Boolean that defines 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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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 Attribute Flag Indicator	B	Ö	A Service Provider Boolean that defines 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.
Service Provider SOA Supports Cancel-Pending-to-Conflict Cause Code	B	Ö	A Service Provider Boolean that defines whether a SOA NPAC Customer supports a Conflict message that uses the Cancel-Pending-to-Conflict Cause Code. The default is FALSE.
Service Provider LSMS Supports Cancel-Pending-to-Conflict Cause Code	B	Ö	A Service Provider Boolean that defines whether a LSMS NPAC Customer supports a Conflict message that uses the Cancel-Pending-to-Conflict Cause Code. The default is FALSE.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
Service Provider SOA SV Query Indicator	B	Ö	A Service Provider Boolean that defines whether a SOA NPAC Customer supports enhanced Subscription Version query functionality over their SOA to 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 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) •    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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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. The default value is False.
Service Provider SOA Supports SPID Recovery Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports SPID Recovery processing from the SOA to the NPAC SMS. The default value is False.
Service Provider LSMS Supports SPID Recovery Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports SPID Recovery processing from the NPAC SMS to the LSMS. The default value is False.
NPAC Customer SOA Alt-End User Location Value Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alt-End User Location Value information from the NPAC SMS to their SOA. The default value is False.
NPAC Customer LSMS Alt-End User Location Value Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alt-End User Location Value information from the NPAC SMS to their LSMS. The default value is False.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
NPAC Customer SOA Alt-End User Location Type Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alt-End User Location Type information from the NPAC SMS to their SOA. The default value is False.
NPAC Customer LSMS Alt-End User Location Type Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alt-End User Location Type information from the NPAC SMS to their LSMS. The default value is False.
NPAC Customer SOA Alt-Billing ID Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alt-Billing ID information from the NPAC SMS to their SOA. The default value is False.
NPAC Customer LSMS Alt-Billing ID Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Alt-Billing ID information from the NPAC SMS to their LSMS. The default value is False.
NPAC Customer SOA Voice URI Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Voice URI information from the NPAC SMS to their SOA. The Voice URI is the network address to the Service Provider’s gateway for Voice service. The default value is False.
NPAC Customer LSMS Voice URI Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Voice URI information from the NPAC SMS to their LSMS. The Voice URI is the network address to the Service Provider’s gateway for Voice service. The default value is False.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
NPAC Customer SOA MMS URI Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports MMS URI information from the NPAC SMS to their SOA. The MMS URI is the network address to the Service Provider’s gateway for MMS service. The default value is False.
NPAC Customer LSMS MMS URI Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports MMS URI information from the NPAC SMS to their LSMS. The MMS URI is the network address to the Service Provider’s gateway for MMS service.
			The default value is False.
NPAC Customer SOA SMS URI Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports SMS URI information from the NPAC SMS to their SOA. The SMS URI is the network address to the Service Provider’s gateway for SMS service.
			The default value is False.
NPAC Customer LSMS SMS URI Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports SMS URI information from the NPAC SMS to their LSMS. The SMS URI is the network address to the Service Provider’s gateway for SMS service.
			The default value is False.
NPAC Customer SOA Last Alternative SPID Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Last Alternative SPID information from the NPAC SMS to their SOA. The Last Alternative SPID is the SPID of the subtending Service Provider having the retail relationship with the end user.
			The default value is False.
NPAC Customer LSMS Last Alternative SPID Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Last Alternative SPID information from the NPAC SMS to their LSMS. The Last Alternative SPID is the SPID of the subtending Service Provider having the retail relationship with the end

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
			user.
			The default value is False.
Medium Timers Support Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer supports Medium Timers in an Object Creation Notification or Attribute Value Change Notification. The default value is False.

Table 3-2 NPAC Customer Data Model

NPAC CUSTOMER CONTACT DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
NPAC Customer Contact ID	N	Ö	A unique sequential number assigned upon creation of the Contact record.
NPAC Customer ID	C (4)	Ö	An alphanumeric code which uniquely identifies an NPAC Customer.
Contact Type	C (2)	Ö	The type of NPAC Customer Contact Organization. Valid values are:
			•     BI — Billing
			•     CF — Conflict Resolution Interface
			•     LI — Local SMS Interface
			•     NC — NPAC Customer
			•     NF — Network and Communications Facilities Interface
			•     OP — Operations
			•     RE — Repair Center Contact Organization
			•     SE — Security
			•     SI — SOA System Interface
			•     UA — User Administration
			•     WI — Web Interface
Contact	C (40)	Ö	Name of NPAC Customer Contact Organization.
Contact Address Line 1	C (40)	Ö	Contact Organization address Line 1.
Contact Address Line 2	C (40)	Ö	Contact Organization address Line 2.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER CONTACT DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
Contact City	C (20)	Ö	Contact Organization city.
Contact State	C (2)	Ö	Contact Organization state.
Contact Zip	C (9)	Ö	Contact Organization zip code or postal code.
Contact Country	C (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
	Type
Attribute Name	(Size)	Required	Description
NPAC Customer Network Address ID	N	Ö	A unique sequential number assigned upon creation of the Network Address record.
NPAC Customer ID	C (4)	Ö	An alphanumeric code which uniquely identifies an NPAC Customer.
Network 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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NPAC CUSTOMER NETWORK ADDRESS DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
Internet Address	Address (12)		Internet address of the Service Provider Web interface.

Table 3-4 NPAC Customer Network Address Data Model

	NPAC CUSTOMER ASSOCIATED SERVICE PROVIDER DATA MODEL
Attribute Name		Type (Size)	Required	Description
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
	Type
Attribute Name	(Size)	Required	Description
Version ID	N	Ö	A unique sequential number assigned upon creation of the Subscription Version.
LRN	TN	Ö	The LRN is an identifier for the switch on which portable NPA-NXXs reside.
Old Service Provider ID	C (4)	Ö	Old Service Provider ID.
New Service Provider ID	C (4)	Ö	New Service Provider ID.
TN	TN	Ö	Subscription Version telephone number.
Local Number	E	Ö	Number Portability Type. Valid enumerated values are:
Portability Type
			•     LSPP — Local Service Provider Portability (0)
			•     LISP — Local Intra-Service Provider Portability (1)
			•     POOL — Pooled Block Number Port (2)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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.
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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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)
Old Service Provider Cancellation Time Stamp	T		The date and time that the Old Service Provider acknowledged that the Subscription Version be canceled.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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 — 200910 NeuStar, Inc.	3-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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.
			0 — Short Timers
			1 — Long Timers
			2 — MediumTimers
Business Hour Type	E	Ö	Business Hours used for the subscription version.
			0 — Short Business Hours/Days
			1 — Long Business Hours/Days
			2 — Medium Business Hours/Days
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.
Alt-End User Location Value	N (12)		Alt-End User Location Value for Subscription Version.
			This field may only be specified if the service provider SOA supports Alt-End User Location Value.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

SUBSCRIPTION VERSION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
Alt-End User Location Type	N (2)		Alt-End User Location Type for Subscription Version.
			This field may only be specified if the service provider SOA supports Alt-End User Location Type.
Alt-Billing ID	C (4)		Alt-Billing ID for Subscription Version.
			This field may only be specified if the service provider SOA supports Alt-Billing ID.
Voice URI	C (255)		Voice URI for Subscription Version.
			This field may only be specified if the service provider SOA supports Voice URI. The Voice URI is the network address to the Service Provider’s gateway for voice service.
MMS URI	C (255)		MMS URI for Subscription Version.
			This field may only be specified if the service provider SOA supports MMS URI. The MMS URI is the network address to the Service Provider’s gateway for MMS.
SMS URI	C (255)		SMS URI for Subscription Version.
			This field may only be specified if the service provider SOA supports SMS URI. The SMS URI is the network address to the Service Provider’s gateway for SMS.
Last Alternative SPID	C (4)		Last Alternative SPID for Subscription Version.
			This field may be specified only if the service provider SOA supports Last Alternative SPID. The Last Alternative SPID is the SPID of the subtending Service Provider having the retail relationship with the end user.
New SP Medium Timer Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer views this SV as a simple port using Medium Timers when they are the New SP.
			This field is only required if the service provider supports Medium Timers.
Old SP Medium Timer Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer views this SV as a simple port using Medium Timers when they are the Old SP.
			This field is only required if the service provider supports Medium Timers.

Table 3-6 Subscription Version Data Model

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

SUBSCRIPTION VERSION FAILED SP LIST DATA MODEL
	Type
Attribute Name	(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
	Type
Attribute Name	(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 supports WSMSC data, as defined in the NPAC Customer Data Model.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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.
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.
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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
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.
SOA Origination 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
			3 — audit-discrepancy
Alt-End User Location Value	N (12)		Alt-End User Location Value for Number Pool Block.
			This field may only be specified if the service provider SOA supports Alt-End User Location Value.
Alt-End User Location Type	N (2)		Alt-End User Location Type for Number Pool Block.
			This field may only be specified if the service provider SOA supports Alt-End User Location Type.
Alt-Billing ID	C (4)		Alt-Billing ID for Number Pool Block.
			This field may only be specified if the service provider SOA supports Alt-Billing ID.
Voice URI	C (255)		Voice URI for Number Pool Block.
			This field may only be specified if the service provider SOA supports Voice URI. The Voice URI is the network address to the Service Provider’s gateway for voice service.
MMS URI	C (255)		MMS URI for Number Pool Block.
			This field may only be specified if the service provider SOA supports MMS URI. The MMS URI is the network address to the Service Provider’s gateway for MMS.
SMS URI	C (255)		SMS URI for Number Pool Block.
			This field may only be specified if the service provider SOA supports SMS URI. The SMS URI is the network address to the Service Provider’s gateway for SMS.
Last Alternative SPID	C (4)		Last Alternative SPID for Number Pool Block.
			This field may be specified only if the service provider SOA supports Last Alternative SPID. The Last Alternative SPID is the SPID of the subtending Service Provider having the retail relationship with the end user.

Table 3-8 Number Pooling Block Holder Information Data Model

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NUMBER POOLING BLOCK FAILED SP LIST DATA MODEL
	Type
Attribute Name	(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.

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
	Type
Attribute Name	(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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

LRN DATA MODEL
	Type
Attribute Name	(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.
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
	Type
Attribute Name	(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
	Type
Attribute Name	(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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-25	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

NUMBER POOLING NPA-NXX-X HOLDER INFORMATION DATA MODEL
	Type
Attribute Name	(Size)	Required	Description
Creation Time Stamp	T		The date and time (GMT) that this NPA-NXX-X Holder record was created.
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

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-26	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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, Last Alternative SPID, Alt-End User Location Value, Alt-End User Location Type, Alt-Billing ID, Voice URI, MMS URI, SMS URI, 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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-27	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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), SSN(s), SV Type, Alternative SPID, Last Alternative SPID, Alt-End User Location Value, Alt-End User Location Type, Alt-Billing ID, Voice URI, MMS URI, and SMS URI 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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-28	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-29	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-30	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

RR3-270 SPID Migration Update — Creation of Number Pool Block for Old Service Provider

DELETED

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.

Note: This applies to pending-like records where the OSP (migrating-from SPID) is either the code holder or the block holder, and also pending-like records where the previous port is an active record (migrating-from SPID is the NSP) that is being migrated (e.g., SV1 is active and will be migrated, SV2 is pending-like and will be cancelled).

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 — 200910 NeuStar, Inc.	3-31	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

• Last Alternative SPID (for Local SMSs that support Last Alternative SPID data)

• Alt-End User Location Value (for Local SMSs that support Alt-End User Location Value)

• Alt-End User Location Type (for Local SMSs that support Alt-End User Location Type)

• Alt-Billing ID (for Local SMSs that support Alt-Billing ID)

• Voice URI (for Local SMSs that support Voice URI data)

• MMS URI (for Local SMSs that support MMS URI data)

• SMS URI (for Local SMSs that support SMS URI 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-32	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

• Creation Timestamp

• Effective Timestamp

• Download Reason

• Block Data

• Block ID

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

• Last Alternative SPID (for Local SMSs that support Last Alternative SPID data)

• Alt-End User Location Value (for Local SMSs that support Alt-End User Location Value)

• Alt-End User Location Type (for Local SMSs that support Alt-End User Location Type)

• Alt-Billing ID (for Local SMSs that support Alt-Billing ID)

• Voice URI (for Local SMSs that support Voice URI data)

• MMS URI (for Local SMSs that support MMS URI data)

• SMS URI (for Local SMSs that support SMS URI 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-33	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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:

• 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-34	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-35	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-36	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-37	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-38	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-39	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-40	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-41	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-42	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

RN3-4.4 NPA Split — NPA-NXX Effective Date Validation — Error

DELETED

RN3-4.5 NPA Split — NPA-NXX involved in one NPA Split Validation

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-43	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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 NPA Split — Addition of NPA-NXX before or during Permissive Dialing

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-44	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-45	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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 NPA Split -

DELETED

RN3-4.34 NPA Split -

DELETED

RN3-4.35 NPA Split -

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-46	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-47	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-48	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-49	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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 — 200910 NeuStar, Inc.	3-50	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	3-51	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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, medium and short business hours and days for operations involving business time calculation.

RR3-11 Business Day Definition — Short

DELETED

RR3-30 Business Day Definition — Long

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-498 Medium Business Days Tunable Parameter

NPAC SMS shall provide a Medium 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.

RR3-499 Medium Business Days Tunable Parameter — Default Value

NPAC SMS shall default the Medium Business Days tunable parameter to Monday through Friday.

RR3-500 Medium Business Days Tunable Parameter — Valid Values

NPAC SMS shall use days of the week as valid values for the Medium Business Days tunable parameter.

RR3-501 Medium Business Days Tunable Parameter — Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface to modify the Medium Business Days Tunable Parameter.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-52	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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, medium 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, medium 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-502 Medium Business Day Duration — Tunable Parameter Default

NPAC SMS shall default the medium Business Day Duration tunable parameter to 17 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, medium 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, medium and short Business Day Start Time tunable parameters to the value specified by the contracting region.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-53	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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-503 Medium Business Day Start Time — Tunable Parameter Default

NPAC SMS shall default the medium Business Day Start Time tunable parameter to 7:00 AM local time of the predominant time zone within the region, stored in UTC and 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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-54	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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 — 200910 NeuStar, Inc.	3-55	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-56	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.9 Service Provider Support Indicators

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

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-57	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

RR3-504 Service Provider SOA Last Alternative SPID Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA Last Alternative SPID Edit Flag Indicator tunable parameter which defines whether a SOA supports Last Alternative SPID. (previously NANC 438, Req 1)

RR3-505 Service Provider SOA Last Alternative SPID Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA Last Alternative SPID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 438, Req 2)

RR3-506 Service Provider SOA Last Alternative SPID Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Last Alternative SPID Edit Flag Indicator tunable parameter. (previously NANC 438, Req 3)

RR3-507 Service Provider LSMS Last Alternative SPID Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS Last Alternative SPID Edit Flag Indicator tunable parameter which defines whether an LSMS supports Alternative SPID. (previously NANC 438, Req 4)

RR3-508 Service Provider LSMS Last Alternative SPID Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS Last Alternative SPID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 438, Req 5)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-58	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

RR3-509 Service Provider LSMS Last Alternative SPID Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Last Alternative SPID Edit Flag Indicator tunable parameter. (previously NANC 438, Req 6)

3.8.63.9.2 Alternative-End User Location and Alternative Billing ID 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 436.

RR3-510 Service Provider SOA Alt-End User Location Value Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA Alt-End User Location Value Edit Flag Indicator tunable parameter which defines whether a SOA supports Alt-End User Location Value. (previously NANC 436, Req 1)

RR3-511 Service Provider SOA Alt-End User Location Value Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA Alt-End User Location Value Edit Flag Indicator tunable parameter to FALSE. (previously NANC 436, Req 2)

RR3-512 Service Provider SOA Alt-End User Location Value Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Alt-End User Location Value Edit Flag Indicator tunable parameter. (previously NANC 436, Req 3)

RR3-513 Service Provider SOA Alt-End User Location Type Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA Alt-End User Location Type Edit Flag Indicator tunable parameter which defines whether a SOA supports Alt-End User Location Type. (previously NANC 436, Req 4)

RR3-514 Service Provider SOA Alt-End User Location Type Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA Alt-End User Location Type Edit Flag Indicator tunable parameter to FALSE. (previously NANC 436, Req 5)

RR3-515 Service Provider SOA Alt-End User Location Type Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Alt-End User Location Type Edit Flag Indicator tunable parameter. (previously NANC 436, Req 6)

RR3-516 Service Provider SOA Alt-Billing ID Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA Alt-Billing ID Edit Flag Indicator tunable parameter which defines whether a SOA supports Alt-Billing ID. (previously NANC 436, Req 7)

RR3-517 Service Provider SOA Alt-Billing ID Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA Alt-Billing ID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 436, Req 8)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-59	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

RR3-518 Service Provider SOA Alt-Billing ID Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Alt-Billing ID Edit Flag Indicator tunable parameter. (previously NANC 436, Req 9)

3.8.73.9.3 URI Indicators

The following section of requirements defines service provider tunable features that indicate if a service provider system supports optional data functionality defined for URIs.

RR3-519 Service Provider SOA Voice URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA Voice URI Edit Flag Indicator tunable parameter which defines whether a SOA supports Voice URI. (previously NANC 429, Req 1)

RR3-520 Service Provider SOA Voice URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA Voice URI Edit Flag Indicator tunable parameter to FALSE. (previously NANC 429, Req 2)

RR3-521 Service Provider SOA Voice URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Voice URI Edit Flag Indicator tunable parameter. (previously NANC 429, Req 3)

RR3-522 Service Provider LSMS Voice URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS Voice URI Edit Flag Indicator tunable parameter which defines whether an LSMS supports Voice URI. (previously NANC 429, Req 4)

RR3-523 Service Provider LSMS Voice URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS Voice URI Edit Flag Indicator tunable parameter to FALSE. (previously NANC 429, Req 5)

RR3-524 Service Provider LSMS Voice URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Voice URI Edit Flag Indicator tunable parameter. (previously NANC 429, Req 6)

RR3-525 Service Provider SOA MMS URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA MMS URI Edit Flag Indicator tunable parameter which defines whether a SOA supports MMS URI. (previously NANC 430, Req 1)

RR3-526 Service Provider SOA MMS URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA MMS URI Edit Flag Indicator tunable parameter to FALSE. (previously NANC 430, Req 2)

RR3-527 Service Provider SOA MMS URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA MMS URI Edit Flag Indicator tunable parameter. (previously NANC 430, Req 3)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-60	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

RR3-528 Service Provider LSMS MMS URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS MMS URI Edit Flag Indicator tunable parameter which defines whether an LSMS supports MMS URI. (previously NANC 430, Req 4)

RR3-529 Service Provider LSMS MMS URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS MMS URI Edit Flag Indicator tunable parameter to FALSE. (previously NANC 430, Req 5)

RR3-530 Service Provider LSMS MMS URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS MMS URI Edit Flag Indicator tunable parameter. (previously NANC 430, Req 6)

RR3-531 Service Provider SOA SMS URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA SMS URI Edit Flag Indicator tunable parameter which defines whether a SOA supports SMS URI. (previously NANC 435, Req 1)

RR3-532 Service Provider SOA SMS URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA SMS URI Edit Flag Indicator tunable parameter to FALSE. (previously NANC 435, Req 2)

RR3-533 Service Provider SOA SMS URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SMS URI Edit Flag Indicator tunable parameter. (previously NANC 435, Req 3)

RR3-534 Service Provider LSMS SMS URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS SMS URI Edit Flag Indicator tunable parameter which defines whether an LSMS supports SMS URI. (previously NANC 435, Req 4)

RR3-535 Service Provider LSMS SMS URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS SMS URI Edit Flag Indicator tunable parameter to FALSE. (previously NANC 435, Req 5)

RR3-536 Service Provider LSMS SMS URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SMS URI Edit Flag Indicator tunable parameter. (previously NANC 435, Req 6)

3.8.83.9.4 Medium Timers Support Indicators

The following section of requirements defines service provider tunable features that indicate if a service provider system supports simple port medium timer functionality defined as part of NANC 440 and 441.

RR3-537 Medium Timers Support Indicator

NPAC SMS shall provide a Medium Timers Support Indicator tunable parameter which defines whether a SOA supports Medium Timers in an Object Creation Notification or Attribute Value Change Notification. (previously NANC 440, Req 1)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-61	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

Note: When this value is set to TRUE, and a SOA supports the Timer Type attribute, a Timer Type value of 2 may be sent in the Object Creation Notification, and the Timer Type attribute will be included in the Attribute Value Change Notification with a Timer Type value of 0 or 2 in cases when the value changed from the initial setting based on a Timer Type mismatch in the New SP and Old SP Create messages.

RR3-538 Medium Timers Support Indicator Default

NPAC SMS shall default the Medium Timers Support Indicator tunable parameter to FALSE. (previously NANC 440, Req 2)

RR3-539 Medium Timers Support Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Medium Timers Support Indicator tunable parameter. (previously NANC 440, Req 3)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-62	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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 — 200910 NeuStar, Inc.	3-63	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

3.103.11 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.13.11.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.23.11.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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-64	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-65	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-66	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-67	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-68	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-69	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-70	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

RR3-540 Notification BDD Service Provider Timer Type Business Hours Attributes Indicator

NPAC SMS shall provide a Notification BDD Service Provider Timer Type Business Hours Attributes Indicator tunable parameter which defines whether a Service Provider supports the Timer Type and Business Hours attributes in their BDD Files. (previously NANC 416, Req 1)

RR3-541 Notification BDD Service Provider Timer Type Business Hours Attributes Indicator Default

NPAC SMS shall default the Notification BDD Service Provider Timer Type Business Hours Attributes Indicator tunable parameter to FALSE. (previously NANC 416, Req 2)

RR3-542 Notification BDD Service Provider Timer Type Business Hours Attributes Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Notification BDD Service Provider Timer Type Business Hours Attributes Indicator tunable parameter. (previously NANC 416, Req 3)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-71	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-72	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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.113.12 NPA-NXX-X Information

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-73	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-74	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-75	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-76	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)
Last Alternative SPID (if supported by the Block Holder SOA)
Alt-End User Location Value (if supported by the Block Holder SOA)
Alt-End User Location Type (if supported by the Block Holder SOA)
Alt-Billing ID (if supported by the Block Holder SOA)
Voice URI (if supported by the Block Holder SOA)
MMS URI (if supported by the Block Holder SOA)
SMS URI (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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-77	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-78	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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.43.12.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 — 200910 NeuStar, Inc.	3-79	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-80	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-81	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-82	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-83	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

3.11.73.12.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 — 200910 NeuStar, Inc.	3-84	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

3.123.13 Block Information

3.12.13.13.1 Version Status

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-85	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

Figure 2 — Number 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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-86	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

Number Pool Block Version Status Interaction Descriptions

#	Interaction Name	Type	Description
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.
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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-87	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

Number Pool Block Version Status Interaction Descriptions

#	Interaction Name	Type	Description
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.

Table 3-14 Number Pool Block Version Status Interaction Descriptions

3.12.23.13.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 — 200910 NeuStar, Inc.	3-88	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	3-89	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	3-90	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	3-91	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

				Non-EDR Local SMS
					some but
					not all
					non-EDR Local
					SMSs respond	all non-EDR
	EDR Local SMS				successfully	Local
		some but	none		to a	SMSs fail	some but
	all EDR	not all	of the	all non-EDR	given	a given SV,	not all	none of
	Local	EDR	EDR Local	Local SMSs	SV, but all	but	non-EDR	the non-EDR
	SMSs	Local	SMSs	respond	respond	respond	Local SMSs	Local SMSs	All Pooled
	respond	SMSs respond	respond	successfully	successfully	successfully	fail all	respond	SVs in
	successfully	successfully	successfully	to all SVs	to another SV	to another SV	Pooled SVs	successfully	the Block	Block
1									Act	Act
2									Act/Part	Part
3									Part	Part
4									Part	Part
5									Part	Part
6									Part	Part
7									Part	Part
8									Part	Part
9									Part	Part
10									Part	Part
11									Part	Part
12									Part	Part
13									Part/Fail	Part
14									Part	Part
15									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 — 200910 NeuStar, Inc.	3-92	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.3 — Block Modification

				Non-EDR Local SMS
					some but
					not all
					non-EDR Local
					SMSs respond	all non-EDR
	EDR Local SMS				successfully	Local
		some but	none		to a	SMSs fail	some but
	all EDR	not all	of the	all non-EDR	given	a given SV,	not all	none of
	Local	EDR	EDR Local	Local SMSs	SV, but all	but	non-EDR	the non-EDR
	SMSs	Local	SMSs	respond	respond	respond	Local SMSs	Local SMSs	All Pooled
	respond	SMSs respond	respond	successfully	successfully	successfully	fail all	respond	SVs in
	successfully	successfully	successfully	to all SVs	to another SV	to another SV	Pooled SVs	successfully	the Block	Block
1									Act	Act
2									Act	Act
3									Act	Act
4									Act	Act
5									Act	Act
6									Act	Act
7									Act	Act
8									Act	Act
9									Act	Act
10									Act	Act
11									Act	Act
12									Act	Act
13									Act	Act
14									Act	Act
15									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 — 200910 NeuStar, Inc.	3-93	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

				Non-EDR Local SMS
					some but
					not all
					non-EDR Local
					SMSs respond	all non-EDR
	EDR Local SMS				successfully	Local
		some but	none		to a	SMSs fail	some but
	all EDR	not all	of the	all non-EDR	given	a given SV,	not all	none of
	Local	EDR	EDR Local	Local SMSs	SV, but all	but	non-EDR	the non-EDR
	SMSs	Local	SMSs	respond	respond	respond	Local SMSs	Local SMSs	All Pooled
	respond	SMSs respond	respond	successfully	successfully	successfully	fail all	respond	SVs in
	successfully	successfully	successfully	to all SVs	to another SV	to another SV	Pooled SVs	successfully	the Block	Block
1									Old	Old
2									Old	Old
3									Old	Old
4									Old	Old
5									Old	Old
6									Old	Old
7									Old	Old
8									Old	Old
9									Old	Old
10									Old	Old
11									Old	Old
12									Old	Old
13									Act/Old	Old
14									Old	Old
15									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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-94	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

• 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 — 200910 NeuStar, Inc.	3-95	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

				Non-EDR Local SMS
					some but
					not all
					non-EDR Local
					SMSs respond	all non-EDR
	EDR Local SMS				successfully	Local
		some but	none		to a	SMSs fail	some but
	all EDR	not all	of the	all non-EDR	given	a given SV,	not all	none of
	Local	EDR	EDR Local	Local SMSs	SV, but all	but	non-EDR	the non-EDR
	SMSs	Local	SMSs	respond	respond	respond	Local SMSs	Local SMSs	All Pooled
	respond	SMSs respond	respond	successfully	successfully	successfully	fail all	respond	SVs in
	successfully	successfully	successfully	to all SVs	to another SV	to another SV	Pooled SVs	successfully	the Block	Block
1									ZFSL	ZFSL
2									Z/S FSL	SFSL
3									SFSL	SFSL
4									SFSL	SFSL
5									SFSL	SFSL
6									SFSL	SFSL
7									SFSL	SFSL
8									SFSL	SFSL
9									SFSL	SFSL
10									SFSL	SFSL
11									SFSL	SFSL
12									SFSL	SFSL
13									S/A FSL	SFSL
14									SFSL	SFSL
15									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 — 200910 NeuStar, Inc.	3-96	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	3-97	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-98	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

Alternative SPID (if supported by the Block Holder SOA)
Last Alternative SPID (if supported by the Block Holder SOA)
Alt-End User Location Value (if supported by the Block Holder SOA)
Alt-End User Location Type (if supported by the Block Holder SOA)
Alt-Billing ID (if supported by the Block Holder SOA)
Voice URI (if supported by the Block Holder SOA)
MMS URI (if supported by the Block Holder SOA)
SMS URI (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)

RR3-53443 Activate Number Pool Block — Send Last Alternative SPID to Local SMSs

NPAC SMS shall, for a Service Provider that supports Last Alternative SPID, send the Last Alternative SPID attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 438, Req 8)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-99	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

RR3-53544 Activate Number Pool Block — Send Alt-End User Location Value to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alt-End User Location Value, send the Alt-End User Location Value attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 436, Req 7)

RR3-53645 Activate Number Pool Block — Send Alt-End User Location Type to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alt-End User Location Type , send the Alt-End User Location Type attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 436, Req 7.1)

RR3-53746 Activate Number Pool Block — Send Alt-Billing ID to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alt- Billing ID, send the Alt- Billing ID attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 436, Req 7.2)

RR3-53847 Activate Number Pool Block — Send Voice URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports Voice URI, send the Voice URI attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 429, Req 8)

RR3-53948 Activate Number Pool Block — Send MMS URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports MMS URI, send the MMS URI attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 430, Req 8)

RR3-5409 Activate Number Pool Block — Send SMS URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports SMS URI, send the SMS URI attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 435, Req 8)

3.12.43.13.4 Block Holder, Modification

RR3-154 Block’s SOA Origination Indicator — NPAC Personnel OpGUI

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-100	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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), Alternative SPID (if supported by the Block Holder SOA), Last Alternative SPID (if supported by the Block Holder SOA), Alt-End User Location Value (if supported by the Block Holder SOA), Alt-End User Location Type (if supported by the Block Holder SOA), and Alt-Billing ID (if supported by the Block Holder SOA), Voice URI (if supported by the Block Holder SOA) MMS URI (if supported by the Block Holder SOA), and SMS URI (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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-101	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-102	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-103	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-104	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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 — 200910 NeuStar, Inc.	3-105	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

3.12.93.13.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.133.14 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 — 200910 NeuStar, Inc.	3-106	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-107	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-108	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-109	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-110	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-111	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-112	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-113	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-114	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-115	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-116	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	3-117	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC Data Administration

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)

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 — 200910 NeuStar, Inc.	3-118	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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 (can select Short or Long, cannot select Medium)
13.	Port Out Timer Type (can select Short or Long, cannot select Medium)
14.	Business Hour/Days (can select Short or Long, cannot select Medium)
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
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.	Service Provider SOA Supports Cancel-Pending-to-Conflict Cause Code
36.	Service Provider LSMS Supports Cancel-Pending-to-Conflict Cause Code
37.	Service Provider SOA SV Query Indicator
38.	Service Provider LSMS SV Query Indicator
39.	NPAC Customer SOA SV Type Indicator
40.	NPAC Customer SOA Alternative SPID Indicator

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

41.	NPAC Customer LSMS SV Type Indicator
42.	NPAC Customer LSMS Alternative SPID Indicator
43.	Service Provider SOA SPID Recovery Indicator
44.	Service Provider LSMS SPID Recovery Indicator
45.	NPAC Customer SOA Alt-End User Location Value Indicator
46.	NPAC Customer LSMS Alt-End User Location Value Indicator
47.	NPAC Customer SOA Alt-End User Location Type Indicator
48.	NPAC Customer LSMS Alt-End User Location Type Indicator
49.	NPAC Customer SOA Alt-Billing ID Indicator
50.	NPAC Customer LSMS Alt-Billing ID Indicator
51.	NPAC Customer SOA Voice URI Indicator
52.	NPAC Customer LSMS Voice URI Indicator
53.	NPAC Customer SOA MMS URI Indicator
54.	NPAC Customer LSMS MMS URI Indicator
55.	NPAC Customer SOA SMS URI Indicator
56.	NPAC Customer LSMS SMS URI Indicator
57.	NPAC Customer SOA Last Alternative SPID Support Indicator
58.	NPAC Customer LSMS Last Alternative SPID Support Indicator
59.	Service Provider Medium Timers Support 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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	4-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Service Provider Data Administration

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 — 200910 NeuStar, Inc.	4-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

5.1.1.1 Version Status

Figure 3 — Subscription Version Status Interaction Diagram

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
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	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.
		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.
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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
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.
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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
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.
		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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

Subscription Version Status Interaction Descriptions
#	Interaction Name	Type	Description
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 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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

R5-3.4 Cancel-Conflict Subscription Retention — Tunable Parameter

NPAC SMS shall provide a Cancel-Conflict Subscription Retention tunable parameter which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of conflict shall be retained and accessible through a query request.

R5-3.5 Cancel-Conflict Subscription Retention — Tunable Parameter Modification

NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Conflict Subscription Retention tunable parameter.

R5-3.6 Cancel-Conflict Subscription Retention — Tunable Parameter Default

NPAC SMS shall default the Cancel-Conflict Subscription Retention tunable parameter to 30 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

• Status Flag — successful or failed

• Subscription Version ID (when assigned)

RR5-182 Create/Modify Subscription Version — Medium Timers — Timer Type

NPAC SMS shall set the value of a Subscription Version Timer Type, based on SP Profile and Subscription Version data contained in Table RR3-182. (previously NANC 441, Req 3)

Note: If one or both service providers don’t support Medium Timers the NPAC sets Timer Type and Business Type as specified in the existing requirements R5-19.3, R5-19.4, R5-19.5 and R5-19.6.

Table RR3-182 — Timer Type Values

NSP is Short, OSP is Short, Timer Type is Short regardless of Indicators
NSP is Short, OSP is Long
NSP is First Create	NSP SOA Indicator is F	Timer set to:	Long
	OSP SOA Indicator is F	Timer remains:	Long
	OSP SOA Indicator is T	Timer switches to:	Medium
	OSP no concur	Timer remains:	Long
NSP is First Create	NSP SOA Indicator is T	Timer set to:	Medium
	OSP SOA Indicator is F	Timer switches to:	Long
	OSP SOA Indicator is T	Timer remains:	Medium
	OSP no concur	Timer remains:	Medium
OSP is First Create	OSP SOA Indicator is F	Timer set to:	Long
	NSP SOA Indicator is F	Timer remains:	Long
	NSP SOA Indicator is T	Timer remains:	Long
OSP is First Create	OSP SOA Indicator is T	Timer set to:	Medium
	NSP SOA Indicator is F	Timer remains:	Medium
	NSP SOA Indicator is T	Timer remains:	Medium
NSP is Long, OSP is Short
NSP is First Create	NSP SOA Indicator is F	Timer set to:	Long
	OSP SOA Indicator is F	Timer remains:	Long
	OSP SOA Indicator is T	Timer switches to:	Medium
	OSP no concur	Timer remains:	Long
NSP is First Create	NSP SOA Indicator is T	Timer set to:	Medium
	OSP SOA Indicator is F	Timer switches to:	Long

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

	OSP SOA Indicator is T	Timer remains:	Medium
	OSP no concur	Timer remains:	Medium
OSP is First Create	OSP SOA Indicator is F	Timer set to:	Long
	NSP SOA Indicator is F	Timer remains:	Long
	NSP SOA Indicator is T	Timer remains:	Long
OSP is First Create	OSP SOA Indicator is T	Timer set to:	Medium
	NSP SOA Indicator is F	Timer remains:	Medium
	NSP SOA Indicator is T	Timer remains:	Medium
NSP is Long, OSP is Long
NSP is First Create	NSP SOA Indicator is F	Timer set to:	Long
	OSP SOA Indicator is F	Timer remains:	Long
	OSP SOA Indicator is T	Timer switches to:	Medium
	OSP no concur	Timer remains:	Long
NSP is First Create	NSP SOA Indicator is T	Timer set to:	Medium
	OSP SOA Indicator is F	Timer switches to:	Long
	OSP SOA Indicator is T	Timer remains:	Medium
	OSP no concur	Timer remains:	Medium
OSP is First Create	OSP SOA Indicator is F	Timer set to:	Long
	NSP SOA Indicator is F	Timer remains:	Long
	NSP SOA Indicator is T	Timer remains:	Long
OSP is First Create	OSP SOA Indicator is T	Timer set to:	Medium
	NSP SOA Indicator is F	Timer remains:	Medium
	NSP SOA Indicator is T	Timer remains:	Medium

RR5-183 Create/Modify Subscription Version — Medium Timers — Business Type

NPAC SMS shall set the value of a Subscription Version Business Type to Medium anytime the Subscription Version Timer Type is set to Medium. (previously NANC 441, Req 4)

Note: Anytime the Timer Type is currently set to Medium and the NPAC changes it due to a modify SV request, a different Business Type value will be also set as specified in the existing requirements R5-19.5 and R5-19.6.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

• Old SP Medium Timer Indicator — indication that Old SP considers this a simple port using Medium Timers. (if supported by the Service Provider SOA)

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

• New SP Medium Timer Indicator — indication that New SP considers this a simple port using Medium Timers. (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.

• New SP Medium Timer Indicator — indication that New SP considers this a simple port using Medium Timers. (if supported by the Service Provider SOA)

R5-16 Create Inter-Service Provider (non-PTO) 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, when the Porting to Original flag is set to False: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• Alternative SPID (if supported by the Service Provider SOA)

• Last Alternative SPID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

RR5-179 Create Inter-Service Provider PTO 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, when the Porting to Original flag is set to True: (reference NANC 399)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

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)

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

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

• New SP Medium Timer Indicator (if supported by the Service Provider SOA)

• Old SP Medium Timer Indicator (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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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 — 200910 NeuStar, Inc.	5-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 New Service Provider Fails to Authorize Transfer of Service

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 — 200910 NeuStar, Inc.	5-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — Old SP

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.

RR5-184 Old Service Provider Final Concurrence Timer Expiration Notification — New SP

NPAC SMS shall upon expiration of the Final Concurrence Timer send a notification to the new service provider, based on the Subscription Version Old SP Final Concurrence Timer Expiration Notification priority setting, via the SOA to NPAC SMS interface to inform them of the timer expiration. (previously NANC 441, Req 8)

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 — 200910 NeuStar, Inc.	5-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

• 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” (non-PTO) 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, when the Porting to Original flag is set to False: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• Alternative SPID (if supported by the Service Provider SOA)

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

RR5-180 Create “Intra-Service Provider Port” (PTO) 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, when the Porting to Original flag is set to True: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-25	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

RR5-6.6 Create “Intra-Service Provider Port” Subscription Version — Duplicate Authorization Validation

NPAC SMS shall verify that the authorization for transfer of service for a given Service Provider does not already exist when a Service Provider creates a Subscription Version for an Intra-Service Provider port.

RR5-6.7 Create “Intra-Service Provider Port” Subscription Version — Old Service Provider ID Validation

NPAC SMS shall verify that the old Service Provider ID on the version being created is equal to the new Service Provider ID on the active Subscription Version, if an active version exists, upon Subscription Version creation for an Intra-Service Provider port.

RR5-6.8 Create “Intra-Service Provider Port” Subscription Version — 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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-26	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

RR5-185 Create Intra-Service Provider Port — Medium Timers

NPAC SMS shall accept an intra-service provider Subscription Version Create message from NPAC Personnel or the Current (New) Service Provider, for a Service Provider that supports the New SP/Old SP Medium Timer Indicator, if any of the following attributes are specified: (Previously NANC 441, Req 1)

• New SP Medium Timer Indicator — this attribute is ignored.

• Old SP Medium Timer Indicator — this attribute is ignored.

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

RR5-186 Modify Subscription Version — New Service Provider — Medium Timers

NPAC SMS shall accept a pending Subscription Version Modify message from NPAC Personnel or the New Service Provider that includes the New SP Medium Timer Indicator until the NPAC SMS has successfully processed the Old SP Subscription Version create message. (previously NANC 441, Req 2)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-27	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

• New SP Medium Timer Indicator (if supported by the Service Provider SOA)

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.

• New SP Medium Timer Indicator (if supported by the Service Provider SOA)

RR5-187 Modify Subscription Version — Old Service Provider — Medium Timers

NPAC SMS shall accept a pending or conflict Subscription Version Modify message from NPAC Personnel or the Old Service Provider that includes the Old SP Medium Timer Indicator until the NPAC SMS has successfully processed the Subscription Version activate message from the New Service Provider. (previously NANC 441, Req 2.1)

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

• Old SP Medium Timer Indicator (if supported by the Service Provider SOA)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-28	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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 (non-PTO) 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, when the Porting to Original flag is set to False: (reference NANC 399)

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

• Alternative SPID (if supported by the Service Provider SOA)

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

RR5-181 Modify (PTO) 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, when the Porting to Original flag is set to True, upon modification of a pending or conflict subscription version:

• Billing Service Provider ID

• End-User Location — Value

• End-User Location — Type

R5-29.1 Modify Subscription Version — Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-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

• CNAM DPC

• CNAM SSN

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-29	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

• New SP Medium Timer Indicator (if supported by the New Service Provider SOA)

• Old SP Medium Timer Indicator (if supported by the Old 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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-30	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

RR5-188 Modify Subscription Version — Medium Timers — Timer Type Change

NPAC SMS shall upon receiving a Subscription Version Modify message from the Old or New Service Provider that modifies the New SP Medium Timer Indicator or the Old SP Medium Timer Indicator and causes a change in the Subscription Version Timer Type, delete any existing T1/T2 timer. (previously NANC 441, Req 2.2)

RR5-189 Modify Subscription Version — Medium Timers — Restart T1 Timer

NPAC SMS shall upon receiving a Subscription Version Modify message from the Old or New Service Provider that modifies the New SP Medium Timer Indicator or the Old SP Medium Timer Indicator and causes a change in the Subscription Version Timer Type, restart a new T1 timer in cases where the NPAC has not received a create from both providers. (previously NANC 441, Req 2.3)

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-31	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

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)

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (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)

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-32	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-33	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-34	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-35	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-36	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-37	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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 — 200910 NeuStar, Inc.	5-38	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 initially put into conflict that the NPAC SMS will prevent it from being removed from conflict by the New Service Provider.

NOTE: In the case where a subscription version is put into conflict (status is conflict), then cancelled (status is cancel-pending), then cancel un-do (status is retunred to conflict), the number of business hours is based on when the subscription version initially went into conflict, not when it is returned back to conflict.

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 — 200910 NeuStar, Inc.	5-39	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-40	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-41	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-42	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-43	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

RR5-190 Activate Subscription Version — Send Last Alternative SPID to Local SMSs

NPAC SMS shall, for a Service Provider that supports Last Alternative SPID, send the Last 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 438, Req 7)

RR5-191 Activate Subscription Version — Send Alt-End User Location Value to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alt-End User Location Value, send the Alt-End User Location Value 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 436, Req 8)

RR5-192 Activate Subscription Version — Send Alt-End User Location Type to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alt-End User Location Type, send the Alt-End User Location 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 436, Req 8.1)

RR5-193 Activate Subscription Version — Send Alt-Billing ID to Local SMSs

NPAC SMS shall, for a Service Provider that supports Alt- Billing ID, send the Alt Billing ID 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 436, Req 8.2)

RR5-194 Activate Subscription Version — Send Voice URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports Voice URI, send the Voice URI 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 429, Req 7)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-44	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

RR5-195 Activate Subscription Version — Send MMS URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports MMS URI, send the MMS URI 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 430, Req 7)

RR5-196 Activate Subscription Version — Send SMS URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports SMS URI, send the SMS URI 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 435, Req 7)

5.1.2.2.5 Subscription Version Disconnect

This section provides the requirements for the Subscription Version Disconnect functionality, which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to have a Subscription Version disconnected.

R5-62 Disconnect Subscription Version — Version Identification

NPAC SMS shall receive the following data from the NPAC personnel or current Service Provider to identify an active Subscription Version to be disconnected:

Ported Telephone Numbers (or 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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-45	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-46	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-47	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

R5-68.6 Disconnect Subscription Version — Sending Status during Retries

NPAC SMS shall retain the status for the Subscription Version being disconnected as sending until the Subscription Disconnect Retry Attempts tunable parameter period expires for all Local SMSs, or until all Local SMSs have acknowledged the disconnect.

R5-68.7 Disconnect Subscription Version — Retry Failed

NPAC SMS shall consider the disconnect Subscription Version request to have failed at a specific Local SMS after the Subscription Disconnect Retry Attempts tunable parameter count for the specific Local SMS has been exhausted.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-48	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-49	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

• 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 — 200910 NeuStar, Inc.	5-50	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-51	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-52	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-53	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

RR5-140 Cancel-Pending-to-Conflict Cause Code Indicator

Deleted, Renumbered to RR6-205

RR5-141 Cancel-Pending-to-Conflict Cause Code Indicator Default

Deleted, Renumbered to RR6-206

RR5-142 Cancel-Pending-to-Conflict Cause Code Indicator Modification

Deleted, Renumbered to RR6-207

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)

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, or from cancel-pending back to conflict 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:

• Ported TN (or a specified range of numbers)

• Subscription Version ID

• Version Status (if TN or TN range is specified, must be cancel-pending)

• New Version Status (can be only pending, in order for it to be returned to a pending-like status)

(previously NANC 388, Req 2)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-54	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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 or conflict. (previously NANC 388, Req 5)

RR5-148 Un-Do a Cancel-Pending Subscription Version — Missing Create Error

DELETED

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 or Conflict, returning the status to the same value as prior to the cancellation that caused it to go into cancel-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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-55	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-56	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-57	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-58	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-59	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-60	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

• Last Alternative SPID (if supported by the Service Provider SOA)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

• New SP Medium Timer Indicator (if supported by the Service Provider SOA)

• Old SP Medium Timer Indicator (if supported by the Service Provider SOA)

Note: If the New SP Medium Timer Indicator value or Old SP Medium Timer Indicator value is not set on the Subscription Version, then it will not be returned in the query response.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-61	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

• 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

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

• Last Alternative SPID (if supported by the Service Provider LSMS)

• Alt-End User Location Value (if supported by the Service Provider SOA)

• Alt-End User Location Type (if supported by the Service Provider SOA)

• Alt-Billing ID (if supported by the Service Provider SOA)

• Voice URI (if supported by the Service Provider SOA)

• MMS URI (if supported by the Service Provider SOA)

• SMS URI (if supported by the Service Provider SOA)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-62	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-63	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

New SP Medium Timer Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer views this SV as a simple port using Medium Timers when they are the New SP.
			This field is only required if the service provider supports Medium Timers.
Old SP Medium Timer Indicator	B	Ö	A Boolean that indicates whether the NPAC Customer views this SV as a simple port using Medium Timers when they are the Old SP.
			This field is only required if the service provider supports Medium Timers.

Table 3-6 Subscription Version Data ModelTable 3-6 Subscription Version Data Model: (previously R4-29)

• Subscription Version ID

• Subscription Version Status

• Local Number Portability Type

• Ported Telephone Number

• Old facilities-based Service Provider Due Date

• New facilities-based Service Provider 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-64	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

• Porting To Original

• Status Change Cause Code

• Timer Type

• Business Hour Type

• SV 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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-65	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-66	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-67	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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)

Last Alternative SPID (Value set to same field as Block)

Alt-End User Location Value (Value set to same field as Block)

Alt-End User Location Type (Value set to same field as Block)

Alt-End Billing ID (Value set to same field as Block)

Voice URI (Value set to same field as Block)

MMS URI (Value set to same field as Block)

SMS URI (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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-68	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	5-69	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Subscription Management

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)

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 — 200910 NeuStar, Inc.	5-70	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	5-71	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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 — 200910 NeuStar, Inc.	6-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

RR6-199 Service Provider SOA SPID Recovery Indicator

NPAC SMS shall provide a Service Provider SOA SPID Recovery Indicator tunable parameter, which defines whether a SOA supports SPID recovery. (NANC 351)

RR6-200 Service Provider SOA SPID Recovery Indicator Default

NPAC SMS shall default the SOA SPID Recovery Indicator tunable parameter to False. (NANC 351)

RR6-201 Service Provider SOA SPID Recovery Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SPID Recovery Indicator tunable parameter. (NANC 351)

RR6-202 Service Provider LSMS SPID Recovery Indicator

NPAC SMS shall provide a Service Provider LSMS SPID Recovery Indicator tunable parameter, which defines whether a LSMS supports SPID recovery. (NANC 351)

RR6-203 Service Provider LSMS SPID Recovery Indicator Default

NPAC SMS shall default the LSMS SPID Recovery Indicator tunable parameter to False. (NANC 351)

RR6-204 Service Provider LSMS SPID Recovery Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SPID Recovery Indicator tunable parameter. (NANC 351)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

RR6-205 Service Provider SOA Cancel-Pending-to-Conflict Cause Code Tunable

NPAC SMS shall provide a Service Provider SOA Cancel-Pending-to-Conflict Cause Code 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-140)

NOTE: If True on a query and notification reply the NPAC SMS returns the cancel-pending-to-conflict cause code value. If False on a query the NPAC SMS does not return the cancel-pending-to-conflict cause code value. On a notification the NPAC SMS inserts a cause code value of “1” instead of the “cancel-pending-to-conflict” cause code value.

RR6-206 Service Provider SOA Cancel-Pending-to-Conflict Cause Code Tunable Default

NPAC SMS shall default the Service Provider SOA Cancel-Pending-to-Conflict Cause Code tunable parameter to FALSE. (previously NANC 138, Req 2, RR5-141)

RR6-207 Service Provider SOA Cancel-Pending-to-Conflict Cause Code Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Cancel-Pending-to-Conflict Cause Code tunable parameter. (previously NANC 138, Req 3, RR5-142)

RR6-208 Service Provider LSMS Cancel-Pending-to-Conflict Cause Code Tunable

NPAC SMS shall provide a Service Provider LSMS Cancel-Pending-to-Conflict Cause Code tunable parameter which defines whether a LSMS supports a Conflict message that uses the Cancel-Pending-to-Conflict Cause Code. (previously NANC 138)

NOTE: If True the NPAC SMS returns the cancel-pending-to-conflict cause code value on a query request. If False the NPAC SMS does not return the cancel-pending-to-conflict cause code value on a query.

RR6-209 Service Provider LSMS Cancel-Pending-to-Conflict Cause Code Tunable Default

NPAC SMS shall default the Service Provider LSMS Cancel-Pending-to-Conflict Cause Code tunable parameter to FALSE. (previously NANC 138)

RR6-210 Service Provider LSMS Cancel-Pending-to-Conflict Cause Code Tunable Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Cancel-Pending-to-Conflict Cause Code tunable parameter. (previously NANC 138)

6.7.1 Notification Recovery

The following section defines specific requirements of the Notification Recovery functionality supported by the NPAC SMS.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

• 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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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 — 200910 NeuStar, Inc.	6-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-25	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-26	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-27	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	6-28	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

NPAC SMS Interfaces

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 — 200910 NeuStar, Inc.	6-29	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

R7-24.2 Passwords — Expiration Notification Default

NPAC SMS shall default the password expiration notification time period to seven days

R7-24.3 Passwords — Require User to Enter New Password

NPAC SMS shall require any user whose password has expired to enter a new password before allowing that user access to the system.

R7-25.1 Passwords — Non-Reusable

NPAC SMS shall ensure that a password can not be reused by the same individual for specifiable period of time.

R7-25.2 Password Reuse Default

NPAC SMS shall default the time period in which a password can not be reused to six months.

R7-26.1 Passwords — Minimum Structure Standard #1

Passwords shall contain a combination of at least six case-sensitive alphanumeric characters including at least one alphabetic and one numeric or punctuation character.

R7-26.2 Passwords — Associated Userid

NPAC SMS shall ensure that passwords do not contain the associated userId.

R7-27.1 Password Generator

NPAC SMS shall provide a password generator.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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 — 200910 NeuStar, Inc.	7-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

7.6Audit

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

R7-85.1 Software Version Number

NPAC SMS shall record the exact revision number of the latest software installed.

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 — 200910 NeuStar, Inc.	7-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	7-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Security

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.

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 — 200910 NeuStar, Inc.	7-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

8. Audit Administration

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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

• 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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.

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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)

RR8-26 Audit for Support of Last Alternative SPID

NPAC SMS shall audit the Last Alternative SPID attribute as part of a full audit scope, only when a Service Provider’s LSMS supports Last Alternative SPID. (previously NANC 438, Req 9)

RR8-27 Audit for Support of Voice URI

NPAC SMS shall audit the Voice URI attribute as part of a full audit scope, only when a Service Provider’s LSMS supports Voice URI. (previously NANC 429, Req 9)

RR8-28 Audit for Support of MMS URI

NPAC SMS shall audit the MMS URI attribute as part of a full audit scope, only when a Service Provider’s LSMS supports MMS URI. (previously NANC 430, Req 9)

RR8-29 Audit for Support of SMS URI

NPAC SMS shall audit the SMS URI attribute as part of a full audit scope, only when a Service Provider’s LSMS supports SMS URI. (previously NANC 435, Req 9)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

8.6 Additional Requirements

RX8-1 Valid Audit Statuses

NPAC SMS shall support the following valid audit statuses:

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	8-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Audit Administration

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 — 200910 NeuStar, Inc.	8-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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.

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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)

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)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	9-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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)

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 — 200910 NeuStar, Inc.	9-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

R10-6.2 Detecting Communication Link Failures

NPAC shall be capable of detecting and reporting all communication link failures.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	10-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	10-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	10-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Performance and Reliability

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.

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 — 200910 NeuStar, Inc.	10-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Billing

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	11-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Billing

• 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 — 200910 NeuStar, Inc.	11-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 1 — NPAC Business Process Flows Legend

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 2 — NPAC SMS Provision Service Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 3 — Flow 2.1.2 NPAC SMS Subscription Version Creation Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 4 — Flow 2.1.4 NPAC SMS Activate and Data Download Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 5 — Flow 2.2 NPAC SMS Disconnect Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 6 — Flow 2.3 NPAC SMS Repair Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 7 — Flow 2.4.1 Conflict Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 8 — Flow 2.5 NPAC SMS Disaster Recovery Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 9 — Flow 2.6 Cancellation Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 10 — Flow 2.7 Audit Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Business Process Flow Diagrams

Figure A- 11 — Flow 2.8 Report Process

Release 3.3: © 1997 — 200910 NeuStar, Inc.	A-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	B-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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
NSAP	Network Layer Service Access Point
Number Pooling Block Holder	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.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	B-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Glossary

Information
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.
SSAP	Session Layer Service Access Point
SSN	Subsystem Number
TN	Telephone Number

Release 3.3: © 1997 — 200910 NeuStar, Inc.	B-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Glossary

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).
URI	Uniform Resource Identifier
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 — 200910 NeuStar, Inc.	B-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

Appendix C. System Tunables

This appendix provides a comprehensive list of tunables identified throughout the FRS and their default values.

SUBSCRIPTION TUNABLES

Tunable Name	Default Value		Units	Valid Range
Long Initial Concurrence Window		9	business hours	1-72
The hours subsequent to the time the subscription version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider port and at least one of the Service Providers are using “Long” timers. (T1 timer)
Long Final Concurrence Window		9	business hours	1-72
The number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider port and at least one of the Service Providers are using “Long” timers. (T2 timer)
Short Initial Concurrence Window		1	business hours	1-72
The hours subsequent to the time the subscription version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider port and both of the Service Providers are using “Short” timers. (T1 timer)
Short Final Concurrence Window		1	business hours	1-72
The number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider port and both of the Service Providers are using “Short” timers. (T2 timer)
Conflict Expiration Window		30	calendar days	1-180
The length of time conflict subscriptions will remain in the conflict state before cancellation.
Maximum Subscription Query		50	records	10-150
The maximum number of subscription versions returned by a query to the NPAC.
Pending Subscription Retention		90	calendar days	1-180

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

SUBSCRIPTION TUNABLES

Tunable Name	Default Value		Units	Valid Range
The length of time pending subscriptions will remain in the pending state before cancellation.
Conflict Restriction Window	17:00 UTC daylight savings time 18:00 UTC standard time		HH:MM	00:00-24:00
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 New Service Provider Restriction		6	business hours	1-72
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.
Short Conflict Resolution New Service Provider Restriction		6	Business hours	1-72
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-Initial Concurrence Window		9	Business hours	1-72
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-Initial Concurrence Window		9	Business hours	1-72
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-Final Concurrence Window		9	business hours	1-72
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-Final Concurrence Window		9	business hours	1-72

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

SUBSCRIPTION TUNABLES

Tunable Name	Default Value		Units	Valid Range
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 Retention		18	calendar months	1-36
The length of time old subscriptions will be retained.
Cancel-Pending Subscription Retention		90	calendar days	1-360
The length of time canceled subscriptions, with last status of pending, will be retained.
Cancel-Conflict Subscription Retention		30	calendar days	1-360
The length of time canceled subscriptions, with last status of conflict, will be retained.
Short Business Day Duration		12	calendar hours	1-24
The number of hours from the tunable business day start time for short business days.
Long Business Day Duration		12	calendar hours	1-24
The number of hours from the tunable business day start time for long business days.
Short Business Day Start Time	13:00 UTC daylight savings time 14:00 UTC standard time		hh:mm	00:00 — 24:00
The start of the business day for short business days. The value is specified by the contracting region.
Long Business Day Start Time	9:00AM Local Time (in the predominant time zone) within each region, stored in UTC		hh:mm	00:00 — 24:00
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 — Friday		Days	Monday — Sunday

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

SUBSCRIPTION TUNABLES

Tunable Name	Default Value		Units	Valid Range
The business days available for Service Providers using short business days.
Long Business Days	Sunday — Saturday		Days	Sunday — Saturday
The business days available for Service Providers using long business days.
Regional NPAC NPA-NXX Live Indicator	TRUE			TRUE/FALSE
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 Conflict Cause Code	TRUE			TRUE/FALSE
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 Conflict Resolution 50/51 Tunable	TRUE			TRUE/FALSE
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.
Regional Un-Do Cancel-Pending Subscription Version Tunable	TRUE			TRUE/FALSE
Indicates whether or not Un-Do Cancel-Pending functionality is supported by the NPAC SMS for a particular NPAC Region.
Medium Initial Concurrence Window		3	business hours	1-72
The hours subsequent to the time the subscription version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider simple port and at least one of the Service Providers uses “Long” timers for non-simple ports. (T1 timer)
Medium Final Concurrence Window		3	business hours	1-72
The number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider simple port and at least one of the Service Providers uses “Long” timers for non-simple ports. (T2 timer)
Medium Conflict Restriction Window		21:00	HH:MM	00:00-23:59
The time on the business day prior to the New Service Provider due date that a simple port 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. This time uses the predominate time zone of the NPAC region (adjusted for Standard/Daylight, stored in UTC).

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

Tunable Name	Default Value		Units	Valid Range
Medium Conflict Resolution New Service Provider Restriction		2	business hours	1-72
The number of business hours after the simple port subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the new Service Provider using medium timers.
Medium Cancellation-Initial Concurrence Window		9	Business hours	1-72
The numbers of hours after the version is set to cancel pending by which both Service Providers using medium timers are expected to acknowledge the pending cancellation.
Medium Cancellation-Final Concurrence Window		9	business hours	1-72
The number of hours after the second cancel pending notification is sent by which both Service Providers using medium timers are expected to acknowledge the pending cancellation.
Medium Business Day Duration		17	calendar hours	1-24
The number of hours from the tunable business day start time for medium business days.
Medium Business Day Start Time		07:00	hh:mm	00:00 — 23:59
The start of the business day for short business days. The value is specified by the contracting region. This time uses the predominate time zone of the NPAC region (adjusted for Standard/Daylight, stored in UTC).
Medium Business Days	Monday — Friday		Days	Monday — Sunday
The business days available for Service Providers supporting Simple Ports.

Table C- 1 — Subscription Tunables

COMMUNICATIONS TUNABLES

Tunable Name	Default Value	Units	Valid Range
Subscription Activation Retry Attempts	3	attempts	1-10
The number of times a new subscription version will be sent to a Local SMS which has not acknowledged receipt of the activation request.
Subscription Activation Retry Interval	2	minutes	1-60

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

COMMUNICATIONS TUNABLES

Tunable Name	Default Value		Units	Valid Range
The delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request.
Subscription Modification Retry Attempts		3	attempts	1-10
The number of times a modified active subscription version will be sent to a Local SMS which has not acknowledged receipt of the modification request.
Subscription Modification Retry Interval		2	minutes	1-60
The delay between sending modified active subscription versions to a Local SMS that has not acknowledged receipt of the modification request.
Subscription Disconnect Retry Attempts		3	attempts	1-10
The number of times the NPAC SMS will resend a subscription disconnect message to an unresponsive Local SMS.
Subscription Disconnect Retry Interval		2	minutes	1-60
The amount of time that shall elapse between subscription disconnect retries.
Local SMS Retry Attempts		3	attempts	1-10
The default number of times the NPAC SMS will resend a message to an unresponsive Local SMS.
Local SMS Retry Interval		2	minutes	1-60
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 Period		60	seconds	0-300
The amount of time the NPAC SMS will wait to restart the logon process after a user has exceeded the Failed_Login_Attempts tunable.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

COMMUNICATIONS TUNABLES

Tunable Name	Default Value		Units	Valid Range
Unused User Id Disable Period		60	days	1-360
The number of days for which a userId has not been used before the NPAC SMS disables that userId.
Password Age Limit		90	days	1-360
The amount of time for password aging.
Password Expiration Notice		7	days	1-30
The amount of time prior to a password expiring that the NPAC SMS will notify a user.
Post Expiration Logins		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 Failure		10	attempts	0-100
The threshold for consecutive failed logon attempts after which logon attempts will be recorded in the audit log.
Non-Use Disconnect		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.
Maximum Download Duration		60	minutes	1-1440
The maximum time range allowed for a data download.
Maximum Number of Download Notifications		2000	records	1-2000
The maximum number of notifications for a single notification recovery download.
Service Provider and Network Data Linked Replies Blocking Factor		50	objects	1-2000

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

COMMUNICATIONS TUNABLES

Tunable Name	Default Value		Units	Valid Range
The maximum number of objects in a single service provider or network data recovery linked reply response.
Subscription Data Linked Replies Blocking Factor		50	objects	1-2000
The maximum number of objects in a single subscription data recovery linked reply response.
Notification Data Linked Replies Blocking Factor		50	notifications	1-2000
The maximum number of notifications in a single notifications recovery linked reply response.
Number Pool Block Data Linked Replies Blocking Factor		50	Objects	1-2000
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.
Subscription Data Maximum Linked Recovered Objects		10000	objects	1-10000
The maximum number of objects sent in a subscription data recovery response, when the LSMS supports Linked Replies.
Notification Data Maximum Linked Recovered Notifications		2000	notifications	1-10000
The maximum number of notifications sent in a notification recovery response, when the SOA/LSMS supports Linked Replies.
Number Pool Block Data Maximum Linked Recovered Objects		10000	objects	1-10000
The maximum number of objects sent in a number pool block data recovery response, when the LSMS supports Linked Replies.
SOA SWIM Maximum Tunable		50000	objects	10000 — 100000
The maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery.
LSMS SWIM Maximum Tunable		50000	objects	10000 — 100000

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

COMMUNICATIONS TUNABLES

Tunable Name	Default Value		Units	Valid Range
The maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery.
Out-Bound Flow Control Upper Threshold Tunable		100	Messages	50 — 500
The number of non-responsive messages sent to a SOA/LSMS before Out-Bound Flow Control is invoked.
Out-Bound Flow Control Lower Threshold Tunable		75	Messages	1 — 500
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 Tunable		15	Minutes	1 — 60
The number of minutes before roll-up activity is initiated for an event involving a single SV.
Roll-Up Activity Timer Expire SVRange Tunable		60	Minutes	1 — 60
The number of minutes before roll-up activity is initiated for an event involving a range of SVs.
Abort Processing Behavior Upper Threshold Tunable		60	Minutes	1 — 180
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 Edit Flag Indicator	False		Boolean	True/False
An indicator as to whether or not NPA edits will be enforced by the NPAC SMS for a particular NPAC region.
NPAC SMS Application Level Heartbeat Tunable		15	Minutes	5 — 60
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 Level Heartbeat Timeout Tunable		1	Minutes	1 — 5
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

AUDIT TUNABLES

Tunable Name	Default Value		Units	Valid Range
Canceled Audit Retention Period		30	days	1-360
The length of time canceled audits will be retained.
Data Integrity Sample Size		1000	SVs	1-5000
The number of active Subscription Versions in a sample to be monitored by the NPAC SMS.
Data Integrity Sample Frequency		7	Days	1-90
The interval in days between Data Integrity Samples conducted by the NPAC SMS.
Subscription Query Record Limit		50	Subscriptions	1-5000
The maximum number of records that can be returned from a query.

Table C- 3 — Audit Tunables

LOGS TUNABLES

Tunable Name	Default Value		Units	Valid Range
Local SMS Activation Log Retention Period		90	days	1-360
The number of days Local SMS activation responses will remain in the log.
Audit Log Retention Period		90	days	1-360
The length of time audit logs will be retained.
Error Log Retention Period		90	days	1-360
The length of time system error logs will be retained.
History File Data Storage		365	days	1-365
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

KEYS TUNABLES

Tunable Name	Default Value		Units	Valid Range
Key Change Interval		365	days	1-365
How often the key is changed automatically.

Table C- 5 — Keys Tunables

BLOCK TUNABLES

Tunable Name	Default Value		Units	Valid 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 — 200910 NeuStar, Inc.	C-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

#	Notification Name	Priority
L-11.0 A1.5	Subscription Version Status Attribute Value Change Notification — Activates — To the Old Service Provider	MEDIUM
	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 A2	Subscription Version Status Attribute Value Change Notification — re-sends to fail list — To The New Service Provider	MEDIUM
	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 A2.5	Subscription Version Status Attribute Value Change Notification — re-sends to fail list — To The Old Service Provider	MEDIUM
	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 A3	Subscription Version Status Attribute Value Change Notification — clear Fail List — To The New Service Provider	MEDIUM
	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 A3.5	Subscription Version Status Attribute Value Change Notification — clear Fail List — To The Old Service Provider	MEDIUM
	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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

#	Notification Name	Priority
	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 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

#	Notification Name	Priority
	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
A	(T2 expiration for Old SP concurrence sent to Old SP)
L-12.0	Subscription Version Old SP Final Concurrence Timer Expiration Notification	NONE
B	(T2 expiration for Old SP concurrence sent to New SP)
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;
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).

Release 3.3: © 1997 — 200910 NeuStar, Inc.	C-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

System Tunables

#	Notification Name	Priority
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 — 200910 NeuStar, Inc.	C-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

1.	The size of the public exponent is determined by the previous field of the key data, public exponent size.
2.	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 — 200910 NeuStar, Inc.	D-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Encryption Key Exchange

ENCRYPTION KEY EXCHANGE FILE FORMAT

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	D-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

Key Exchange using PGP

Release 3.3: © 1997 — 200910 NeuStar, Inc.	D-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Encryption Key Exchange

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 — 200910 NeuStar, Inc.	D-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	E-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)
12	CNAM DPC	123123123 (This value is 3 octets)
13	CNAM SSN	123 (This value is 1 octet and usually set to 000)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE FIELDS IN THE SUBSCRIPTION DOWNLOAD FILE

Field
Number	Field Name	Value in Example
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.
23	Alt-End User Location Value	Not present if LSMS or SOA does not support the Alt-End User Location Value as shown in this example. If it were present the value would be as defined in the SV Data Model.
24	Alt-End User Location Type	Not present if LSMS or SOA does not support the Alt-End User Location Type as shown in this example. If it were present the value would be as defined in the SV Data Model.
25	Alt-Billing ID	Not present if LSMS or SOA does not support the Alt-Billing ID as shown in this example. If it were present the value would be as defined in the SV Data Model.
26	Last Alternative SPID	Not present if LSMS or SOA does not support the Last 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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

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 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 — 200910 NeuStar, Inc.	E-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

Figure E-2a — Network Service Provider Download File Example, SP Does Not Support SP Type

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

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

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

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
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 — 200910 NeuStar, Inc.	E-8	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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
2	NPA-NXX-X	3031231
3	LRN	1234567890
4	New Current Service Provider Id	0001

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-9	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE FIELDS IN THE BLOCK DOWNLOAD FILE

Field
Number	Field Name	Value in Example
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 NPB Data Model.
18	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 NPB Data Model.
19	Alt-End User Location Value	Not present if LSMS or SOA does not support the Alt-End User Location Value as shown in this example. If it were present the value would be as defined in the NPB Data Model.
20	Alt-End User Location Type	Not present if LSMS or SOA does not support the Alt-End User Location Type as shown in this example. If it were present the value would be as defined in the NPB Data Model.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-10	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE FIELDS IN THE BLOCK DOWNLOAD FILE

Field
Number	Field Name	Value in Example
21	Alt-Billing ID	Not present if LSMS or SOA does not support the Alt-Billing ID as shown in this example. If it were present the value would be as defined in the NPB Data Model.
22	Last Alternative SPID	Not present if LSMS or SOA does not support the Last Alternative SPID as shown in this example. If it were present the value would be as defined in the NPB Data Model.

Table E- 6 — Explanation of the Fields in The Block Download File

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-11	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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)

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-12	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF FIELDS IN A HYPOTHETICAL NOTIFICATIONS DOWNLOAD FILE

Field
Number	Field Name	Value in Example
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	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.
9	SV Type	0 This attribute (pipes) is included if the Service Provider supports SV Type at the time of notification BDD generation. If the Service Provider does not support SV Type at the time of notification, the pipes are not included in the notification BDD. 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 SV Type at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-13	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF FIELDS IN A HYPOTHETICAL NOTIFICATIONS DOWNLOAD FILE

Field
Number	Field Name	Value in Example
10	Alternative SPID	2020 This attribute (pipes) is included if the Service Provider supports Alternative SPID at the time of notification BDD generation. If the Service Provider does not support Alternative SPID at the time of notification, the pipes are not included in the notification BDD. 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 Alternative SPID at the time of notification generation.
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 — 200910 NeuStar, Inc.	E-14	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	E-15	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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
9	Version ID	1234567899

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-16	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
6	Customer Disconnect Date	20050530230000
7	Effective Release Date	20050530230000
8	Range Type Format	2

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-17	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
11	Subscription Timer Type	0
12	Subscription Business Type	1
13	Version TN	1232201999
14	Version ID	1234000099

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-18	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
17	Ending Version ID	1234000013
subscriptionVersionRangeNewSP-CreateRequest (* if not a consecutive list)
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-19	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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	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
19	... Version ID “n”	2340000023
subscriptionVersionOldSP-ConcurrenceRequest
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	0001
3	System Type	0

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-20	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-21	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-22	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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.
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-23	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-24	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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”.
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-25	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
13	Conflict Time Stamp
14	Status Change Cause Code
15	Subscription Version Status	1
16	Timer Type	0
17	Business Hours	0
18	New SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Data Model. The value that will be included in the Object Creation Notification is based on the SP that first sent up the request.
19	Old SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Data Model. The value that will be included in the Object Creation Notification is based on the SP that first sent up the request.
20	Version TN	3034401000

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-26	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
21	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
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	Timer Type	0
16	Business Hours	0

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-27	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
17	New SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Data Model. The value that will be included in the Object Creation Notification is based on the SP that first sent up the request.
18	Old SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Data Model. The value that will be included in the Object Creation Notification is based on the SP that first sent up the request.
19	Subscription Version Status	1
20	Range Type Format	1
21	Starting Version TN	3034401000
22	Ending Version TN	3034402000
23	Starting Version ID	1234500001
24	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
7	New Service Provider Due Date	20050530230000

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-28	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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	Timer Type	0
17	Business Hours	0
18	New SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Data Model. The value that will be included in the Object Creation Notification is based on the SP that first sent up the request.
19	Old SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Data Model. The value that will be included in the Object Creation Notification is based on the SP that first sent up the request.
20	Range Type Format	2
21	Starting Version TN	3034401000
22	Ending Version TN	3034401097
23	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 98).

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-29	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
24	Version ID	2050505050
25	Version ID	2050505059
26	... 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	Timer Type
13	Business Hours
14	New SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Requirements and Data Model.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-30	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
15	Old SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Requirements and Data Model.
16	Version TN	3034401000
17	Version ID	1234567890
subscriptionVersionRangeAttributeValueChange (* if 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	Timer Type	0
13	Business Hours	0

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-31	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
14	New SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Requirements and Data Model.
15	Old SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Requirements and Data Model.
16	Range Type Format	1
17	Starting Version TN	3034401000
18	Ending Version TN	3034401009
19	Starting Version ID	1000000000
20	Ending Version ID	1000000009
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-32	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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	Conflict Time Stamp
12	Timer Type	0
13	Business Hours	0
14	New SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Requirements and Data Model.
15	Old SP Medium Timer Indicator	0
		Not present if SOA does not support the Medium Timers Support Indicator as shown in this example. If it were present the value would be as defined in the SV Requirements and Data Model.
1216	Range Type Format	2
1317	Starting Version TN	3034401000
1418	Ending Version TN	3034401009
1519	Variable Field Length	Indicates the number of dynamic values for the following field (e.g. 10).
1620	Version ID	1000000000
1721	Version ID	1000000013
1822	... Version ID “n”	1000000016
subscriptionAudit-DiscrepancyRpt
1	Creation TimeStamp	For example: 19960101155555
2	Service Provider ID	1003
3	System Type	0

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-33	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-34	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-35	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-36	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-37	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
2	Service Provider ID	1003
3	System Type	0
4	Notification ID	1006
5	Object ID	30
6	Number Pool Block Creation	20050501122000
	Time Stamp
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-38	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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
23	SV Type	0
		This attribute (pipes) is included if the ServiceProvider supports SV Type at the time of notification BDD generation. If the ServiceProvider does not support SV Type at the time ofnotification, the pipes are not included in the notification BDD.
		Data for this attribute is included if theattribute was included in the originalnotification which depends on whether or not the Service Provider supported SV Type at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-39	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
2224	Alternative SPID	2020 This attribute (pipes) is included if the Service Provider supports Alternative SPID at the time of notification BDD generation. If the Service Provider does not support Alternative SPID at the time of notification, the pipes are not included in the notification BDD. 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 Alternative SPID at the time of notification generation.
2325	Alt-End User Location Value	123456789 This attribute (pipes) is included if the Service Provider supports Alt-End User Location Value at the time of notification BDD generation. If the Service Provider does not support Alt-End User Location Value at the time of notification, the pipes are not included in the notification BDD.
		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 Alt-End User Location Value at the time of notification generation.
2426	Alt-End User Location Type	12 This attribute (pipes) is included if the Service Provider supports Alt-End User Location Type at the time of notification BDD generation. If the Service Provider does not support Alt-End User Location Type at the time of notification, the pipes are not included in the notification BDD. 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 Alt-End User Location Type at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-40	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
2527	Billing ID	1234 This attribute (pipes) is included if the Service Provider supports Alt-Billing ID at the time of notification BDD generation. If the Service Provider does not support Alt-Billing ID at the time of notification, the pipes are not included in the notification BDD. 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 Alt-Billing ID at the time of notification generation.
2628	Voice URI	10.100.150.200 This attribute (pipes) is included if the Service Provider supports Voice URI at the time of notification BDD generation. If the Service Provider does not support Voice URI at the time of notification, the pipes are not included in the notification BDD. 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 Voice URI at the time of notification generation.
2729	MMS URI	10.111.150.200 This attribute (pipes) is included if the Service Provider supports MMS URI at the time of notification BDD generation. If the Service Provider does not support MMS URI at the time of notification, the pipes are not included in the notification BDD. 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 MMS URI at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-41	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
2830	SMS URI	10.20.3.10 This attribute (pipes) is included if the Service Provider supports SMS URI at the time of notification BDD generation. If the Service Provider does not support SMS URI at the time of notification, the pipes are not included in the notification BDD. 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 SMS URI at the time of notification generation.
2931	Last Alternative SPID	2022 This attribute (pipes) is included if the Service Provider supports Last Alternative SPID at the time of notification BDD generation. If the Service Provider does not support Last Alternative SPID at the time of notification, the pipes are not included in the notification BDD. 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 Last Alternative SPID at the time of notification generation.
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-42	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
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)
16	ISVM DPC	123123123 (This value is 3 octets)
17	ISVM SSN	123 (This value is 1 octet and usually set to 000)
18	WSMSC DPC	123123123 (This value is 3 octets)
19	WSMSC SSN	123 (This value is 1 octet and usually set to 000)
20	SV Type	0 This attribute (pipes) is included if the Service Provider supports SV Type at the time of notification BDD generation. If the Service Provider does not support SV Type at the time of notification, the pipes are not included in the notification BDD. 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 SV Type at the time of notification generation.
21	Alternative SPID	2020 This attribute (pipes) is included if the Service Provider supports Alternative SPID at the time of notification BDD generation. If the Service Provider does not support Alternative SPID at the time of notification, the pipes are not included in the notification BDD. 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 Alternative SPID at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-43	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
22	Alt-End User Location Value	123456789 This attribute (pipes) is included if the Service Provider supports Alt-End User Location Value at the time of notification BDD generation. If the Service Provider does not support Alt-End User Location Value at the time of notification, the pipes are not included in the notification BDD. 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 Alt-End User Location Value at the time of notification generation.
23	Alt-End User Location Type	12 This attribute (pipes) is included if the Service Provider supports Alt-End User Location Type at the time of notification BDD generation. If the Service Provider does not support Alt-End User Location Type at the time of notification, the pipes are not included in the notification BDD. 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 Alt-End User Location Type at the time of notification generation.
24	Alt-Billing ID	1234 This attribute (pipes) is included if the Service Provider supports Alt-Billing ID at the time of notification BDD generation. If the Service Provider does not support Alt-Billing ID at the time of notification, the pipes are not included in the notification BDD. 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 Alt-Billing ID at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-44	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
25	Voice URI	10.100.150.200 This attribute (pipes) is included if the Service Provider supports Voice URI at the time of notification BDD generation. If the Service Provider does not support Voice URI at the time of notification, the pipes are not included in the notification BDD. 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 Voice URI at the time of notification generation.
26	MMS URI	10.111.150.200 This attribute (pipes) is included if the Service Provider supports MMS URI at the time of notification BDD generation. If the Service Provider does not support MMS URI at the time of notification, the pipes are not included in the notification BDD. 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 MMS URI at the time of notification generation.
27	SMS URI	10.20.3.10 This attribute (pipes) is included if the Service Provider supports SMS URI at the time of notification BDD generation. If the Service Provider does not support SMS URI at the time of notification, the pipes are not included in the notification BDD. 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 SMS URI at the time of notification generation.

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-45	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
28	Last Alternative SPID	2022 This attribute (pipes) is included if the Service Provider supports Last Alternative SPID at the time of notification BDD generation. If the Service Provider does not support Last Alternative SPID at the time of notification, the pipes are not included in the notification BDD. 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 Last Alternative SPID at the time of notification generation.
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-46	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-47	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
7	Old Service Provider ID	2001
8	Old Service Provider Due Date	20050530230000
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-48	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
	Old Service Provider
10	Authorization TimeStamp	20050530231632
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

Release 3.3: © 1997 — 200910 NeuStar, Inc.	E-49	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Download File Examples

EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE

Notification

Field
Number	Field Name	Sample Value
9	Additional Download Time	(graphic string 255)
	Information
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 — 200910 NeuStar, Inc.	E-50	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	E-51	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	E-52	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	E-53	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	F-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	G-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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

RR5-10.4

Release 3.3: © 1997 — 200910 NeuStar, Inc.	G-2	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Deleted Requirements

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

R5-40.2 (Duplicate — refer to R5-34)

RR5-43 Activation with Old Service Provider Authorization

Release 3.3: © 1997 — 200910 NeuStar, Inc.	G-3	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Deleted Requirements

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

RX6-3.1

RR6-6 (Duplicate — refer to R10-10.1)

RR6-7 (Duplicate — refer to R10-10.1)

Release 3.3: © 1997 — 200910 NeuStar, Inc.	G-4	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Deleted Requirements

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

R6-4.1

R6-4.2

R6-4.3

R6-5.1

Release 3.3: © 1997 — 200910 NeuStar, Inc.	G-5	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Deleted Requirements

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

R8-7.1

R8-7.2

R8-7.3

R8-8

R8-13

Release 3.3: © 1997 — 200910 NeuStar, Inc.	G-6	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

Deleted Requirements

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 — 200910 NeuStar, Inc.	G-7	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

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 — 200910 NeuStar, Inc.	H-1	North American Numbering Council (NANC)
		Functional Requirements Specification Release 3.3.4ab

Freely distributable subject to the terms of the GNU GPL, see inside cover notice. December January 822, 200910

EX-99.2

Exhibit 99.2

NPAC SMS

INTEROPERABLE INTERFACE SPECIFICATION

NANC Version 3.3.4ab

Prepared for:
The North American Numbering Council (NANC)

December January 8 22, 200910

Release 3.3: ^© 1997 — 200910 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	2
	1.4.4	Release 3.1	3
	1.4.5	Release 3.2	3
	1.4.6	Release 3.3	3
1.5	References		43
	1.5.1	Standards	43
	1.5.2	Related Publications	5
1.6	Abbreviations/Definitions		5
2	Interface Overview		7
2.1	Overview		7
2.2	OSI Protocol Support		7
2.3	SOA to NPAC SMS Interface		8
	2.3.1	Subscription Administration	8
	2.3.2	Audit Requests	8
	2.3.3	Notifications	9
	2.3.4	Service Provider Data Administration	10
	2.3.5	Network Data Download	10
	2.3.6	Number Pool Block Administration	10
2.4	NPAC SMS to Local SMS Interface		10
	2.4.1	Subscription Version, Number Pool Block and Network Data Download	11
	2.4.2	Service Provider Data Administration	11
	2.4.3	Notifications	11
3	Hierarchy Diagrams		13
3.1	Overview		13
	3.1.1	Managed Object Model Inheritance Hierarchy	13
	3.1.2	Log Record Managed Object Hierarchy	15
	3.1.3	NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS	16
	3.1.4	NPAC SMS to Local SMS Naming Hierarchy for the Local SMS	17
	3.1.5	SOA to NPAC SMS Naming Hierarchy for the NPAC SMS	18
	3.1.6	NPAC SMS to SOA Naming Hierarchy for the SOA	19
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
	4.1.4	Notification Interface Functionality	30

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		1

Table of Contents

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		36
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		37
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
4.9	NPAC Rules for Handling of Optional Data Fields:			39
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	46
		5.2.1.10	Signature	47
	5.2.2	Association Establishment		47
	5.2.3	Data Origination Authentication		49
	5.2.4	Audit Trail		50
5.3	Association Management and Recovery			51
	5.3.1	Establishing Associations		51
		5.3.1.1	NpacAssociationUserInfo	51
		5.3.1.2	Unbind Requests and Responses	52
		5.3.1.3	Aborts	52
		5.3.1.4	NPAC SMS Failover Behavior	52
		5.3.1.5	Service Provider SOA and Local SMS Procedures	52
	5.3.2	Releasing or Aborting Associations		54
	5.3.3	Error Handling		54
		5.3.3.1	NPAC SMS Error Handling	54
		5.3.3.2	Processing Failure Error	54
		5.3.3.3	NPAC SMS Detailed Error Codes	55
	5.3.4	Recovery		55
		5.3.4.1	Local SMS Recovery	60
		5.3.4.2	SOA Recovery	60
		5.3.4.3	Linked Action Replies during Recovery	60
5.4	Congestion Handling			62
	5.4.1	NPAC SMS Congestion		62

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		2

Table of Contents

	5.4.2	NPAC Handling of Local SMS and SOA Congestion	62
	5.4.3	Out-Bound Flow Control	63
5.5	Abort Processing Behavior		63
5.6	Single Association for SOA/LSMS		6465
5.7	Separate SOA Channel for Notifications		6465
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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		3

Introduction

1 Introduction

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 inclusion in this new major release.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		1

Introduction

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.

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		2

Introduction

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, released on 10/14/05 contains documentation changes from the NANC IIS Version 3.3.0d.

NANC Version 3.3.2a, released on 3/9/2006 contains changes from the NANC IIS Version 3.3.1a.

NANC Version 3.3.3a, released on 2/28/2006 contains changes from the NANC IIS Version 3.3.2a.

1.4.7 Release 3.3.4

NANC Version 3.3.4a, released on 12/08/2009 contains the following changes from the NANC IIS Version 3.3.3a:

• Change Order NANC 429 — URI Field (Voice)

• Change Order NANC 430 — URI Field (MMS)

• Change Order NANC 435 — URI Field (SMS)

• Change Order NANC 436 —Alt-End User Location and Alt-Billing ID

• Change Order NANC 438 — Last Alternative SPID

• Change Order NANC 441 — FCC Order, SOA Indicator

NANC Version 3.3.4b, released on 1/22/2010 contains the following changes from the NANC IIS Version 3.3.4a:

• Change Order NANC 443 — Doc-Only Change Order: IIS Updates

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		3

Introduction

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.

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		4

Introduction

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.

North American Number Council (NANC) Functional Requirements Specification, Number Portability Administration Center (NPAC), Service Management System (SMS), Version 3.3.4ab December January 822, 200910.

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		5

Introduction

(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	Operating Company Number
OSI	Open Systems Interconnect
PPP	Point-To-Point Protocol
RFP	Request for Proposal
RSA	Encryption Scheme
SOA	Service Order Activation
SMS	Service Management System
TMN	Telecommunications Management Network
TN	Telephone Number
URI	Uniform Resource Identifier
WSMSC	Wireless Short Message Service Center

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		6

Interface Overview

2 Interface Overview

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		7

Interface Overview

Layer		Mechanized Interface	Function
	4	TCP, RFC1006, TPO	Transport
	3	IP	Network
	2	PPP, MAC, FRAME Relay, ATM (IEEE 802.3)	Link
	1	DS-1, DS-0 x n, ISDN, V.34	Physical

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		8

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 attempted to sent them. Alternatively, notifications can be recovered using SWIM (Send What I Missed) recovery.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		9

Interface Overview

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.

• 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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		10

Interface Overview

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		11

Hierarchy Diagrams

3 Hierarchy Diagrams

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		12

Hierarchy Diagrams

Exhibit 2. The Managed Object Model Inheritance Hierarchy

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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.

Exhibit 3 . Log Record Managed Object Hierarchy

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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 FunctionsAssociation Functions.

Exhibit 4. The NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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 FunctionsAssociation Functions.

Exhibit 5. The NPAC SMS to Local SMS Naming Hierarchy for the Local SMS.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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 FunctionsAssociation Functions.

Exhibit 6. The SOA to NPAC SMS Naming Hierarchy for the NPAC SMS.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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 FunctionsAssociation Functions.

Exhibit 7. NPA SMS to SOA Naming Hierarchy for the SOA.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		18

Interface Functionality to CMIP Definition Mapping

4 Interface Functionality to CMIP Definition Mapping

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 8. 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 Acknowledgement	from SOA (new service provider)	M-ACTION:	lnpSubscriptions
		subscriptionVersionNewSP-
		CancellationAcknowledge
Cancellation Acknowledgment	from SOA (old service provider)	M-ACTION:	lnpSubscriptions
		subscriptionVersionOldSP-CancellationAcknowledge
Conflict Removal	from SOA (new service provider)	M-ACTION:	lnpSubscriptions
		subscriptionVersionRemoveFromConflict
Customer Disconnect Date	to SOA	M-EVENT-REPORT:	subscriptionVersionNPAC
		subscriptionVersionDonorSP-CustomerDisconnectDate or	or
		subscriptionVersionRangeDonorSP-CustomerDisconnectDate	lnpSubscriptions

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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:	subscriptionVersionNPAC
		subscriptionVersionOldSPFinalConcurrenceWindowExpiration or	or
		subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration	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:	lnpNetwork
		lnpDownload
		or
		M-GET:
		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:	SubscriptionVersionNPAC
		subscriptionVersionNewNPA-NXX	lnpNPAC-SMS
Number Pool Block	to SOA	M-EVENT-REPORT	numberPoolBlockNPAC
Change Notification		attributeValueChange Notification or numberPoolBlockStatusAttributeValueChange Notification
Number Pool Block Create	from SOA	M-ACTION:	lnpSubscriptions
		numberPoolBlock-Create
Number Pool Block Create	to LOCAL SMS	M-CREATE:	numberPoolBlock
		for a single numberPoolBlock

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		20

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Number Pool Block Modify	from SOA	M-SET:	numberPoolBlockNPAC or
		to a single numberPoolBlock	lnpSubscriptions
Number Pool Block Modify	to LOCAL SMS	MSET:	numberPoolBlock or
		to a single numberPoolBlock or	lnpSubscriptions
		scoped and filtered by NPA-NXX-X range for mass update
Number Pool Block Delete	to LOCAL SMS	M-DELETE:	numberPoolBlock
		for a single numberPoolBlock
Number Pool Block Query	from LOCAL SMS or SOA	M-GET:	lnpSubscriptions
		To a single numberPoolBlockNPAC or	numberPoolBlockNPAC
		scoped and filtered for intended numberPoolBlocks
Number Pool Block Query	to LOCAL SMS	M-GET:	lnpSubscriptions
		scoped and filtered for intended numberPoolBlock
Notification Recovery	from LOCAL SMS or from SOA	M-ACTION:	lnpNPAC-SMS
		lnpNotificationRecovery
Recovery Complete	from LOCAL SMS or from SOA	M-ACTION:	lnpNPAC-SMS
		lnpRecoveryComplete
Request for Cancellation	to SOA	M-EVENT-REPORT:	subscriptionVersionNPAC
Acknowledg-ment		subscription VersionCancellationAcknowledgment	or
		Request or	lnpSubscriptions
		subscriptionVersionRangeCancellationAcknowledgeRequest
Request for Version Create	to SOA (new service provider)	M-EVENT-REPORT:	subscriptionVersionNPAC
		subscriptionVersionNewSP-Create
		Request or subscriptionVersionRangeNewSP-CreateRequest
Request for Version Create	to SOA (old service provider)	M-EVENT-REPORT:	subscriptionVersionNPAC
		subscriptionVersionOldSP-Concurrence	or
		Request or subscriptionVersionRangeOldSP-ConcurrenceRequest	lnpSubscriptions
Service Provider Network	to LOCAL SMS or to SOA	M-CREATE	serviceProvNetwork
Creation
Service Provider Network	to LOCAL SMS or to SOA	M-DELETE	serviceProvNetwork
Deletion
Service Provider Network	to LOCAL SMS or to SOA	M-SET:	serviceProvNetwork
Service Provider Name Change		serviceProvName

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		21

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Subscription Version Activate	from SOA	M-ACTION:	lnpSubscriptions
		subscriptionVersionActivate
Subscription Version Cancel	from SOA	M-ACTION	lnpSubscriptions
		subscriptionVersionCancel
Subscription Version Change	to SOA	M-EVENT-REPORT:	subscriptionVersionNPAC
Notification		attributeValueChangeNotification and	or
		subscriptionVersionStatusAttributeValue	lnpSubscriptions
		Change or subscriptionVersionRangeAttribute
		ValueChange
		subscriptionVersionRangeStatusAttribute
		ValueChange
Subscription	from SOA (old service provider)	M-ACTION:	subscriptionVersion
Version Conflict		subscriptionVersionOldSP-Create
		setting subscriptionOldSP-Authorization = FALSE
Subscription	to LOCAL SMS	M-ACTION:	lnpSubscriptions
Version Create		subscriptionVersionLocalSMS-Create	subscriptionVersion
		for multiple creates (i.e., range operations) where the data
		in the subscription versions is the same
		M-CREATE:
		for an individual subscriptionVersion
Subscription	from SOA	M-ACTION:	lnpSubscriptions
Version Create		subscriptionVersionOldSP-Create or
		subscriptionVersionNewSP-Create
Subscription	to LOCAL SMS	M-DELETE:	subscriptionVersion
Version Delete		scoped and filtered for intended
		subscriptionVersion criteria
Subscription Version	from SOA	M-ACTION:	lnpSubscriptions
Disconnect		subscriptionVersionDisconnect
Subscription	to LOCAL SMS	M-ACTION:	lnpSubscriptions
Version Download		subscriptionVersionLocalSMS-Create
		or
		M-CREATE:
		for an individual subscriptionVersion
Subscription	from LOCAL SMS	M-ACTION:	lnpSubscriptions
Version		lnpDownload
Download Request		or
		M-GET:
		scoped and filtered for intended
		subscriptionVersionNPAC criteria
Subscription Version Modify	from SOA	M-ACTION: subscriptionVersion Modify	lnpSubscriptions
		or
		M-SET:
		on relevant subscriptionVersionNPAC attributes for pending
		and conflict versions

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		21

Interface Functionality to CMIP Definition Mapping

	Direction		Referenced
Function	(To/From)	CMIP Operation	Object Type
Subscription Version Modify	to LOCAL SMS	M-SET:	lnpSubscriptions
		scoped and filtered for intended subscriptionVersion criteria
		setting relevant attributes
Subscription Version Query	from SOA from LOCAL SMS	M-GET:	lnpSubscriptions
		scoped and filtered for intended subscriptionVersionNPAC
		criteria setting relevant attributes
Subscription Version Query	to LOCAL SMS	M-GET:	lnpSubscriptions
		scoped and filtered for intended subscriptionVersion criteria

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 9. 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.
lnpLogAuditResultsRecord	Object used to log information from a subscriptionAuditResults notification.
lnpLogCancellation AcknowledgeRequest Record	Object used to log information from a subscriptionVersionCancellationAcknowledgeRequest notification.
lnpLogDonorSP-CustomerDisconnectDate Record	Object used to log information from a subscriptionVersionDonorSP-CustomerDisconnectDate notification.
lnpLogLocalSMS-ActionResultsRecord	Object used to log information from a subscriptionVersionLocalSMS-ActionResults notification.
lnpLogNewNPA-NXXRecord	Object used to log information from a subscriptionVersionNewNPA-NXX notification.
lnpLogNewSP-CreateRequestRecord	Object used to log information from a subscriptionVersionNewSP-CreateRequest notification.
lnpLogNumberPoolBlockStatusAttributeValueChangeRecord	Object used to log information from a numberPoolBlockStatusAttributeValueChange notification.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		23

Interface Functionality to CMIP Definition Mapping

Managed Object Name	Interface Functionality Mapping
lnpLogOldSP-ConcurrenceRequestRecord	Object used to log information from a subscriptionVersionOldSP-ConcurrenceRequest notification.
lnpLogOldSP- FinalConcurrenceWindow- Expiration	Object used to log information from a subscriptionVersionOldSPFinalConcurrenceWindowExpiration notification
lnpLogOperational-InformationRecord	Object used to log information from a lnpNPAC-SMS-Operational-Information notification.
lnpLogRangeAttributeValueChangeRecord	Object used to log information from a lnpLogRangeAttributeValueChange notification.
lnpLogRangeObjectCreationRecord	Object used to log information from a lnpLogRangeObjectCreation notification.
lnpLogRangeStatusAttributeValueChangeRecord	Object used to log information from a lnpLogRangeStatusAttributeValueChange notification.
lnpLogRangeDonorSP-CustomerDisconnectDateRecord	Object used to log information from a lnpLogRangeDonorSP-CustomerDisconnectDate notification.
lnpLogRangeCancellationAcknowledgeRecord	Object used to log information from a lnpLogRangeCancellationAcknowledge notification.
lnpLogRangeNewSP-CreateRequestRecord	Object used to log information from a lnpLogRangeNewSP-CreateRequest notification.
lnpLogRangeNewSP-FinalCreateWindowExpirationRecord	Object used to log information from a lnpLogRangeNewSP-FinalCreateWindowExpiration notification.
lnpLogNewSP-FinalCreateWindowExpirationRecord	Object used to log information from a lnpLogNewSP-FinalCreateWindowExpiration notification.
lnpLogRangeOldSP-ConcurrenceRequestRecord	Object used to log information from a lnpLogRangeOldSP-ConcurrenceRequest notification.
lnpLogRangeOldSPFinalConcurrenceWindowExpirationRecord	Object used to log information from a lnpLogRangeOldSPFinalConcurrenceWindowExpiration notification.
lnpLogStatusAttributeValueChangeRecord	Object used to log information from a subscriptionVersionStatusAttributeValueChange notification.
lnpLogHeartbeat-InformationRecord	Object used to log information from a Heartbeat-Information notification.
lnpLogSwimProcessing-RecoveryResultsRecord	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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		24

Interface Functionality to CMIP Definition Mapping

Managed Object Name	Interface Functionality Mapping
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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		25

Interface Functionality to CMIP Definition Mapping

Managed Object Name	Interface Functionality Mapping
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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 10. 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-CancellationAcknowledge	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-CancellationAcknowledge	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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		27

Interface Functionality to CMIP Definition Mapping

Action Name	Interface Requirements Mapping
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-CancellationAcknowledgeWithErrorCode	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.
subscriptionVersionRemoveFromConflictWithErrorCode	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-CancellationAcknowledgeWithErrorCode	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 11. 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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		28

Interface Functionality to CMIP Definition Mapping

Notification Name	Interface Requirements Mapping
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-CancellationAcknowledge	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-Create action once all the create requests have been attempted. It is issued from the Local SMS to the NPAC SMS via the NPAC SMS to Local SMS interface.
subscriptionVersionNew-NPA-NXX	This notification informs the Local SMS or SOA of a pending subscription version or new number pool block involving the first use of an NPA-NXX.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		29

Interface Functionality to CMIP Definition Mapping

Notification Name	Interface Requirements Mapping
subscriptionVersionNewSPFinalCreateWindow Expiration or subscriptionVersionRangeNewSPFinalCreateWindowExpiration	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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		30

Interface Functionality to CMIP Definition Mapping

Notification Name	Interface Requirements Mapping
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		32

Interface Functionality to CMIP Definition Mapping

Exhibit 12 — 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 numberPoolBlockNPA-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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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.

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		34

Interface Functionality to CMIP Definition Mapping

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

4.4.2 Other OIDs of Interest

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		35

Interface Functionality to CMIP Definition Mapping

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		36

Interface Functionality to CMIP Definition Mapping

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.

4.9 NPAC Rules for Handling of Optional Data Fields:

Information is provided on how the NPAC handles the XML string as well as how providers system should deal with Activate and Modify downloads that contain XML optionalData strings. Disconnects are not covered here because they don’t contain XML strings.

• Activate — String contains only those fields supported by the provider and specified in the create request.

• Provider systems should store the fields specified in the message.

• Modify — String contains only those fields supported by the provider and were modified in the modify request.

• If the modify removed a value from an optional field, it is included in the string with a value of nil.

• Provider systems should modify only the fields specified in the message. Any other optional fields should be retained.

• Audit — String is included only if there was at least one discrepancy in the fields supported by the provider.

• Only the OptionalData attribute/parameters supported by an LSMS are audited.

• Only the OptionalData attribute/parameters supported by the auditing SOA are returned to the SOA in the discrepancy notifications

• Audit discrepancy reports contain well formed XML strings (i.e., parse-able) representing the discrepant fields. Fields that are not discrepant will not be included. The SOA needs to parse the XML strings be able to act on the discrepancies.

• For Modify downloads that result from an Audit:

• String contains all fields supported by the provider, regardless of whether or not that individual field was discrepant, and regardless of whether or not the NPAC’s subscription version has values for those fields.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		37

Interface Functionality to CMIP Definition Mapping

• Fields not supported by the provider are omitted even if they were returned in the Audit query response from the LSMS.

• Fields supported by the provider but not present in the NPAC’s subscription version are included with a value of nil.

• Provider systems should store the fields as specified above for Activate or Modify downloads.

• Time Based Recovery — Same as Activate.

• Provider systems should replace all fields with those in the recovery message, including removal of optional fields not provided in the recovery message.

• SWIM Recovery — Individual operations are recovered.

• Provider systems should store the fields as specified above for Activate or Modify operations.

• Notifications —

• For a create notification (Number Pool Block only), string contains only fields supported by the provider and specified in the create request.

• For an AVC (Number Pool Block only), string contains only those fields supported by the provider that were modified. If a supported field is removed, it is included in the string with a value of nil.

• BDD — Each field supported by the provider has a position in the BDD record.

• For fields supported by the provider but not present in the NPAC’s subscription version, the field is included in the string with an empty value (two adjacent pipe characters).

• For fields not supported by the provider, no field placeholder is included in the string (no adjacent pipe characters).

• Provider systems should replace all fields with those in the BDD.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		38

Secure Association Establishment

5 Secure Association Establishment

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:

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		44

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		40

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		41

Secure Association Establishment

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		42

Secure Association Establishment

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 135 Association Functions

Association Function/Association Request Initiator	SOA	Local SMS
SOA Management (Audit and Subscription Version)	0x01
Classes:
lnpSubscriptions
numberPoolBlock
numberPoolBlockNPAC
subscriptionAudit
subscriptionVersion
subscriptionVersionNPAC

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		43

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 Classes:	0x20
LnpNetwork
Query Outbound from the NPAC SMS Classes:		0x10
All
SOA Notifications (only applicable for SOAs supporting a	0x40
separate notification association)
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.

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		44

Secure Association Establishment

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		45

Secure Association Establishment

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.

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		46

Secure Association Establishment

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		47

Secure Association Establishment

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

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		48

Secure Association Establishment

• Association termination messages.

• Invalid messages:

• Invalid digital signature.

• Sequence number out of order.

• Generalized time out of range.

• Invalid origination address.

• All incoming messages regardless of whether or not they cause changes to data stored in the NPAC SMS.

This information will be made available for report generation on the NPAC SMS system. It will not be made available through the NPAC SMS Interoperable Interface.

5.3 Association Management and Recovery

5.3.1 Establishing Associations

5.3.1.1 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 {

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		49

Secure Association Establishment

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.

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:

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		50

Secure Association Establishment

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

}

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		51

Secure Association Establishment

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

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		52

Secure Association Establishment

lnpSpecificInfoBehavior BEHAVIOUR

DEFINED AS !

This attribute is used to return more detailed error text information upon a CMIP Processing Failure error.

!;

ASN.1 Definition

LnpSpecificInfo ::= GraphicString(SIZE (1..256))

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		53

Secure Association Establishment

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.

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		54

Secure Association Establishment

Data Type	Criteria	Additional Criteria
	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
		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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		55

Secure Association Establishment

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

‘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 abort 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. If the Service Provider system returns an invalid ACTION_ID, the NPAC SMS will abort the association. 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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		56

Secure Association Establishment

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 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. If the Service Provider system returns an invalid ACTION_ID, the NPAC SMS will abort the association.

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. If the Service Provider system returns an invalid ACTION_ID, the NPAC SMS will abort the association. 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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		57

Secure Association Establishment

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.

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		58

Secure Association Establishment

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		59

Secure Association Establishment

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

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		60

Secure Association Establishment

sequence number value being larger than expected. SOA and LSMSs should use 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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 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.

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

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

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

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

• The NPAC SMS aborts the association to the SOA/LSMS and the SOA/LSMS must re-associated to the NPAC SMS.

• 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 data versus notification data. The NPAC SMS will distribute transactions across these

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		62

Secure Association Establishment

SOA associations based on functionality (different bit masks). This allows for additional throughput for the SOA as a result of two associations.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		63

GDMO Definitions

6 GDMO Definitions

6

The latest version of the GDMO interface definitions (lnp.mo_v_3_3_4_2009_12_08.txt) is available on the NPAC website (www.npac.com, under the documents section).

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		64

General ASN.1 Definitions

7 General ASN.1 Definitions

7

The latest version of the LNP ASN.1 Object Identifier definitions (lnp.asn_v_3_3_4_2009_12_08.txt) is available on the NPAC website (www.npac.com, under the documents section).

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		70

LNP XML Schema

8 LNP XML Schema

8

The latest version of the LNP XML schema (XML-US-2009-12 and XML-Canada-2007-02) is available on the NPAC website (www.npac.com, under the documents section).

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		66

Subscription Version Status

9 Subscription Version Status

9

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		67

Subscription Version Status

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
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	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. .
		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.
		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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		68

Subscription Version Status

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		69

Subscription Version Status

Subscription Version Status Interaction Descriptions

#	Interaction Name	Type	Description
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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		70

Number Pool Block Status

10 Number Pool Block Status

9

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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		71

Number Pool Block Status

Number Pool Block Version Status Interaction Descriptions

#	Interaction Name	Type	Description
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.
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.

December January 822, 200910	NANC Version 3.3.4ab		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 200910 NeuStar, Inc.		72

NPAC SMS
INTEROPERABLE INTERFACE SPECIFICATION

APPENDICES A AND B

NANC Version 3.3.34a

Prepared for:
The North American Numbering Council (NANC)

February 28December 8, 20079

Release 3.3: © 1997 — 20079 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.

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			2931
B.2	Audit Scenarios			3133
	B.2.1	SOA Initiated Audit		3133
		B.2.1.1	SOA Initiated Audit (continued)	3335
	B.2.2	SOA Initiated Audit Cancellation by the SOA		3537
	B.2.3	SOA Initiated Audit Cancellation by the NPAC		3638
	B.2.4	NPAC Initiated Audit		3739
	B.2.5	NPAC Initiated Audit Cancellation by the NPAC		3941
	B.2.6	Audit Query on the NPAC		4042
	B.2.7	SOA Audit Create for Subscription Versions within a Number Pool Block (previously NNP flow 6.1)		4143
		B.2.7.1	SOA Creates and NPAC SMS Starts Audit (previously NNP flow 6.1.1)	4143
		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)	4345
		B.2.7.3	NPAC SMS Reports Audit Results (previously NNP flow 6.1.3)	4547
	B.2.8	NPAC SMS Audit Create for Subscription Versions Within a Number Pool Block (previously NNP flow 6.2)		4649
		B.2.8.1	NPAC SMS Creates and Starts Audit (previously NNP flow 6.2.1)	4649
		B.2.8.2	NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block (previously NNP flow 6.2.2)	4851
B.3	Service Provider Scenarios			5053
	B.3.1	Service Provider Creation by the NPAC		5053
	B.3.2	Service Provider Deletion by the NPAC		5255
	B.3.3	Service Provider Modification by the NPAC		5457
	B.3.4	Service Provider Modification by the Local SMS		5659
	B.3.5	Service Provider Modification by the SOA		5760
	B.3.6	Service Provider Query by the Local SMS		5861
	B.3.7	Service Provider Query by the SOA		5962
B.4	Service Provider Network Data Scenarios			6063
	B.4.1	NPA-NXX Scenarios		6063
		B.4.1.1	NPA-NXX Creation by the NPAC	6063
		B.4.1.2	NPA-NXX Deletion by the NPAC	6265
		B.4.1.3	NPA-NXX Creation by the Local SMS	6467
		B.4.1.4	NPA-NXX Creation by the SOA	6669
		B.4.1.5	NPA-NXX Deletion by the Local SMS	6871
		B.4.1.6	NPA-NXX Deletion by SOA	7073
		B.4.1.7	NPA-NXX Query by the Local SMS	7275
		B.4.1.8	NPA-NXX Query by the SOA	7376
	B.4.2	LRN Scenarios		7477
		B.4.2.1	LRN Creation by the NPAC	7477
		B.4.2.2	LRN Creation by the SOA	7679
		B.4.2.3	LRN Deletion by the SOA	7881
		B.4.2.4	LRN Query by the SOA	8083
		B.4.2.5	LRN Deletion by the NPAC	8184

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		i

Table Of Contents

	B.4.2.6	LRN Creation by the Local SMS		8386
	B.4.2.7	LRN Deletion by the Local SMS		8588
	B.4.2.8	LRN Query by the Local SMS		8790
	B.4.2.9	Network Data Download		8891
	B.4.2.10	Scoped/Filtered GET of Network Data		8992
	B.4.2.11	Scoped/Filtered GET of Network Data from SOA		9093
B.4.3	Service Provider NPA-NXX-X			9194
	B.4.3.1	Service Provider NPA-NXX-X Create by NPAC SMS (previously NNP flow 1.1)		9194
		B.4.3.1.1	Service Provider NPA-NXX-X Create by NPAC SMS (continued)	9396
	B.4.3.2	Service Provider NPA-NXX-X Modification by NPAC SMS (previously NNP flow 1.2)		9497
	B.4.3.3	Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence (previously NNP flow 1.3)		9598
	B.4.3.4	Service Provider NPA-NXX-X Query by SOA or LSMS (previously NNP flow1.4)		97100
B.4.4	Number Pool Block			98101
	B.4.4.1	Number Pool Block Create/Activate by SOA (previously NNP flow 2.1)		98101
	B.4.4.2	Number Pool Block Create by NPAC SMS (previously NNP flow 2.2)		101104
	B.4.4.3	Number Pool Block Create Broadcast Successful to Local SMS (previously NNP flow 2.3.1)		104107
	B.4.4.4	Number Pool Block Create: Successful Broadcast (previously NNP flow 2.3.2)		106109
	B.4.4.5	Number Pool Block Create Broadcast to Local SMS: Failure (previously NNP flow 2.4)		108111
	B.4.4.6	Number Pool Block Create Broadcast to Local SMS: Partial Failure (previously NNP flow 2.5.1)		111114
	B.4.4.7	Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates (previously NNP flow2.5.2)		113116
	B.4.4.8	Number Pool Block Create Resend Broadcast (previously NNP flow 2.6)		115118
	B.4.4.9	Number Pool Block Create Successful Resend Updates (previously NNP flow 2.7)		117120
	B.4.4.10	Number Pool Block Create Failed Resend NPAC SMS Updates (previously NNP flow 2.8)		119122
	B.4.4.11	Number Pool Block Create Partial-Failure Resend NPAC SMS Updates (previously NNP flow 2.9)		121124
	B.4.4.12	Number Pool Block Modify by NPAC SMS (previously NNP flow 2.10)		123126
	B.4.4.13	Number Pool Block Modify by Block Holder SOA (previously NNP flow 2.11)		126129
	B.4.4.14	Number Pool Block Modify Successful Broadcast to Local SMS Success (previously NNP flow 2.12.1)		129132
	B.4.4.15	Number Pool Block Modify Successful Broadcast NPAC SMS Updates (previously NNP flow 2.12.2)		130133
	B.4.4.16	Number Pool Block Modify Broadcast to Local SMS Failure (previously NNP flow 2.13)		132135
	B.4.4.17	Number Pool Block Modify Partial Failure Broadcast to Local SMS (previously NNP flow 2.14.1)		135138
	B.4.4.18	Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.14.2)		136139
	B.4.4.19	Number Pool Block Modify Resend Broadcast (previously NNP flow 2.15)		138141
	B.4.4.20	Number Pool Block Modify Successful Resend Updates (previously NNP flow 2.16)		140143
	B.4.4.21	Number Pool Block Modify Failure Resend Updates (previously NNP flow 2.17)		142145
	B.4.4.22	Number Pool Block Modification of SOA-Origination Indicator (previously NNP flow 2.18)		144147
	B.4.4.23	Number Pool Block De-Pool by NPAC SMS (previously NNP flow 2.19)		145148
	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)		146149
	B.4.4.25	Number Pool Block De-Pool Broadcast Successful NPA-NXX-X Updates (previously NNP flow 2.20.2)		149152
	B.4.4.26	Number Pool Block De-Pool Broadcast to Local SMS Failure (previously NNP flow 2.21)		151154
	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)		154157
	B.4.4.28	Number Pool Block De-Pool Broadcast Partial Failure NPAC SMS Updates (previously NNP flow2.22.2)		155158
	B.4.4.29	Number Pool Block De-Pool Resend Broadcast (previously NNP flow 2.23)		157160
	B.4.4.30	Number Pool Block De-Pool Successful Resend Updates (previously NNP flow 2.24)		159162
	B.4.4.31	Number Pool Block De-Pool Resend Failure Updates (previously NNP flow 2.25)		162165
	B.4.4.32	Number Pool Block De-Pool Resend Partial Failure Updates (previously NNP flow 2.26)		164167
	B.4.4.33	Number Pool Block Query by SOA or LSMS (previously NNP flow 2.27)		166169

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		ii

Table Of Contents

B.5	SubscriptionVersion Flow Scenarios				167170
	B.5.1	SubscriptionVersion Create Scenarios			167170
		B.5.1.1	Subscription Version Create by the Initial SOA (Old Service Provider)		168171
			B.5.1.1.1	Subscription Version Create by the Initial SOA (Old Service Provider) (continued)	170173
		B.5.1.2	SubscriptionVersion Create by the Initial SOA (New Service Provider)		171175
			B.5.1.2.1	Subscription Version Create by the Initial SOA (New Service Provider) (continued)	174178
		B.5.1.3	SubscriptionVersion Create by Second SOA (New Service Provider)		175180
		B.5.1.4	SubscriptionVersion Create by Second SOA (Old Service Provider) with Authorization to Port		178183
		B.5.1.5	SubscriptionVersion Activated by New Service Provider SOA		180185
		B.5.1.6	Active SubscriptionVersion Create on Local SMS		182187
			B.5.1.6.1	Active Subscription Version Create on Local SMS Using Create Action	184189
			B.5.1.6.2	SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window	185190
			B.5.1.6.3	SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window	186191
			B.5.1.6.4	Subscription Version Create: Failure to Receive Response from New SOA	187192
			B.5.1.6.5	SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window	188193
		B.5.1.7	SubscriptionVersionCreate M-CREATE Failure to Local SMS		190195
		B.5.1.8	SubscriptionVersion M-CREATE: Partial Failure to Local SMS		192197
		B.5.1.9	Create Subscription Version: Resend Successful to Local SMS Action		194199
		B.5.1.10	Subscription Version: Resend Failure to Local SMS		196201
		B.5.1.11	SubscriptionVersion Create for Intra-Service Provider Port		198204
		B.5.1.12	SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Successful		201207
			B.5.1.12.1	Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)	203209
			B.5.1.12.2	Intra-Service Provider Subscription Version Port-to-Original: Successful (continued)	205211
		B.5.1.13	SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: All LSMSs Fail		207213
			B.5.1.13.1	Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)	209215
			B.5.1.13.2	Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)	211217
		B.5.1.14	SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Partial Failure		213219
			B.5.1.14.1	Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)	215221
			B.5.1.14.2	Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)	217223
		B.5.1.15	SubscriptionVersion Port-to-Original: Resend		219225
			B.5.1.15.1	Subscription Version Port-to-Original: Resend (continued)	221227
		B.5.1.16	SubscriptionVersion Port-to-Original: Resend Failure to Local SMS		223229
			B.5.1.16.1	SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)	225231
		B.5.1.17	Port-To-Original Subscription Version Flows for Pooled TNs		227233
			B.5.1.17.1	Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA (previously NNP flow 3.1.1)	227233
			B.5.1.17.2	Successful Broadcast of Port-to-Original Activation Request for a Pooled TN (previously NNP flow 3.1.2)	230236
			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)	231237
			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)	234240
			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)	235241
			B.5.1.17.6	Port-to-Original Activation Partial Failure Broadcast of a Pooled TN (previously NNP flow 3.3.1)	238244
			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)	239245
			B.5.1.17.8	Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN (previously NNP flow 3.4.1)	242248
			B.5.1.17.9	Successful Resend Broadcast of a Port-to-Original of a Pooled TN (previously NNP flow 3.4.2)	244250

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		iii

Table Of Contents

		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)	245251
		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)	248254
		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)	251257
		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)	254260
	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		255261
B.5.2	Modify Scenarios			256262
	B.5.2.1	SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA		256262
	B.5.2.2	SubscriptionVersion Modify Active: Failure to Local SMS		259266
	B.5.2.3	SubscriptionVersion Modify Prior to Activate Using M-ACTION		262269
	B.5.2.4	SubscriptionVersion Modify Prior to Activate Using M-SET		265272
	B.5.2.5	Subscription Version Modify Active: Resend Successful to Local SMS		268275
	B.5.2.6	Subscription Version Modify Active: Resend Failure to Local SMS		271278
	B.5.2.7	SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA		274281
B.5.3	Cancel Scenarios			275283
	B.5.3.1	SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred		275283
		B.5.3.1.1	Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)	277285
	B.5.3.2	SubscriptionVersionCancel: No Acknowledgment from a SOA		279287
	B.5.3.3	Subscription Version Cancels With Only One Create Action Received		282290
	B.5.3.4	Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison		284292
	B.5.3.5	Un-Do Cancel-Pending Subscription Version Request		286294
B.5.4	Disconnect Scenarios			288296
	B.5.4.1	SubscriptionVersion Immediate Disconnect		288296
		B.5.4.1.1	SubscriptionVersion Immediate Disconnect (continued)	289298
	B.5.4.2	SubscriptionVersion Disconnect With Effective Release Date		290299
	B.5.4.3	SubscriptionVersion Disconnect: Failure to Local SMS		291301
	B.5.4.4	SubscriptionVersion Disconnect: Partial Failure to Local SMS		293303
	B.5.4.5	Subscription Version Disconnect: Resend Successful to Local SMS		295305
	B.5.4.6	Subscription Version Disconnect: Resend Failure to Local SMS		297307
	B.5.4.7	Disconnect Subscription Version Scenarios for TNs that are part of a Number Pool Block		299309
		B.5.4.7.1	SOA Initiates Successful Disconnect Request of Ported Pooled TN (previously NNP flow 4.1.1)	299309
		B.5.4.7.2	Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation (previously NNP flow 4.1.2)	301311
		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)	303313
		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)	305315
		B.5.4.7.5	Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates (previously NNP flow 4.3.2)	306316
		B.5.4.7.6	Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS (previously NNP flow 4.4.1)	308318
		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)	309319
		B.5.4.7.8	Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS (previously NNP flow 4.5.1)	311321
		B.5.4.7.9	Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates (previously NNP flow 4.5.2)	313323

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		iv

Table Of Contents

			B.5.4.7.10	Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS (previously NNP flow 4.6.1)	314324
			B.5.4.7.11	Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates (previously NNP flow 4.6.2)	316326
			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)	317327
			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)	320330
			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)	321331
	B.5.5	Conflict Scenarios			323333
		B.5.5.1	SubscriptionVersion Conflict by the NPAC SMS		323333
			B.5.5.1.1	Subscription Version Conflict Resolution by the NPAC SMS (continued)	325335
		B.5.5.2	Subscription Version Conflict Removal by the New Service Provider SOA		327337
		B.5.5.3	SubscriptionVersion Conflict: No Conflict Resolution		329339
			B.5.5.3.1	Subscription Version Conflict: No Conflict Resolution (continued)	331341
		B.5.5.4	Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)		332342
		B.5.5.5	Subscription Version Conflict Removal by the Old Service Provider SOA		335345
	B.5.6	SubscriptionVersion Query			337347
		B.5.6.1	Subscription Data Download		340350
B.6	LSMS Filter NPA-NXX Scenarios				341351
	B.6.1	lsmsFilterNPA-NXX Creation by the Local SMS			341351
	B.6.2	lsmsFilterNPA-NXX Deletion by the Local SMS			342352
	B.6.3	lsmsFilterNPA-NXX Query by the Local SMS			343353
	B.6.4	lsmsFilterNPA-NXX Creation by the SOA			344354
	B.6.5	lsmsFilterNPA-NXX Deletion by the SOA			345355
	B.6.6	lsmsFilterNPA-NXX Query by the SOA			346356
B.7	Local SMS and SOA Recovery				347357
	B.7.1	Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS (previously NNP flow 5.2)			348358
		B.7.1.1	Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM		352362
	B.7.2	Sequencing of Events on Initialization/Resynchronization of EDR Local SMS (previously NNP flow 5.1)			358368
		B.7.2.1	Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM		362372
	B.7.3	Sequencing of Events on Initialization/Resynchronization of SOA			368378
		B.7.3.1	Sequencing of Events on Initialization/Resynchronization of SOA using SWIM		370380
B.8	Miscellaneous				374384
	B.8.1	SOA/Local SMS Notification of Scheduled NPAC Downtime			374384
	B.8.2	NPA-NXX Split			375385
		B.8.2.1	NPA-NXX Split that contains a block of pooled TNs Part 1 (previously NNP flow 7)		377387
		B.8.2.2	NPA-NXX Split that contains a block of pooled TNs Part 2 (previously NNP flow 7)		379389
	B.8.3	Mass Update			382392
		B.8.3.1	Mass Update for a range of TNs that contains a Number Pool Block (previously NNP flow 8)		383393
	B.8.4	Application Level Heartbeat Requests			385395
		B.8.4.1	NPAC initiated Application Level Heartbeat Request to local system		385395
		B.8.4.2	Local system initiated Application Level Heartbeat request		386396

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		1

Appendix A: Errors

Appendix A. Errors

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		2

Appendix A: Errors

• The version selected for a disconnect is not active.

duplicateManagedObjectInstance

For create operations, the requested object already exists.

Examples:

• Pending subscription version, NPA-NXX or LRN already exist on NPAC SMS.

classInstanceConflict

The object specified is not a member of the specified class.

complexityLimitation

A parameter was too complex to complete the operation.

invalidArgumentValue

A specified argument is not valid.

Examples:

• An argument value does not pass validation for an action or event report.

• A required parameter is missing for an action or event report.

• An argument value does not exist.

invalidAttributeValue

A specified attribute is not valid.

invalidFilter

A filter specified is not valid.

invalidScope

The scope specified is not valid.

noSuchAction

A specified action is not recognized.

noSuchArgument

A specified argument is not recognized.

noSuchAttribute

A specified attribute is not recognized.

noSuchObjectClass

A specified object class is not recognized.

noSuchObjectInstance

The requested object does not exist.

Examples:

• A query fails based on the search criteria.

• The referenced object (subscription version, NPA-NXX, LRN, etc.) does not exist.

processingFailure

A general failure has occurred in processing the operation or notification A text string is needed to qualify the error message.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		3

Appendix A: Errors

Exhibit 2. processingFailure Errors

	processingFailure Errors
	Error ID	Description
0	lnpSpecificInfo (GraphicString)	Invalid CLASS DPC value.

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	Description	CMIP Error		Description
0	No error		10	processingFailure_er
1	No error, used to signal multi-pass events that the processing is complete.		10	processingFailure_er
2	No error, used to signal multi-pass events that this is the first pass in processing.		10	processingFailure_er
100	Timer expected event that was missing, timer will be removed		10	processingFailure_er
101	Timer could not post event to queue due to database error		10	processingFailure_er
102	System call failed, PLEASE specify call in additional text.		10	processingFailure_er
103	operator new failed		10	processingFailure_er
104	Exception w/descriptive text thrown		10	processingFailure_er
105	Unknown Exception		10	processingFailure_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		4

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
106	Unable to access CurrentEvent		10	processingFailure_er
107	Unable to access Events Manager		10	processingFailure_er
108	Could not open a directory		10	processingFailure_er
200	Timer expected event that was missing, timer will be removed		2	accessDenied_er
201	Timer could not post event to queue due to database error		2	accessDenied_er
202	System call failed, PLEASE specify call in additional text.		6	invalidAttributeValue_er
203	Operator new failed		10	processingFailure_er
204	Exception w/descriptive text thrown		10	processingFailure_er
205	Unknown Exception		2	accessDenied_er
206	Unable to access CurrentEvent		2	accessDenied_er
207	Unable to access Events Manager		2	accessDenied_er
208	Could not open a directory		2	accessDenied_er
209	Event retry limit reached		10	processingFailure_er
210	Can’t open a file		10	processingFailure_er
211	Event failed, unknown reason		10	processingFailure_er
212	Event failed, loaded with unknown reason		10	processingFailure_er
213	Event failed, sms engine couldn’t acquire lock		10	processingFailure_er
214	Array bounds exception		10	processingFailure_er
215	Event missing expected attribute		10	processingFailure_er
216	Array bounds error		10	processingFailure_er
2000	Required data for TN field(s) missing.		6	invalidAttributeValue_er
2001	Required due date entry missing from the subscription version.		6	invalidAttributeValue_er
2002	Required Customer Disconnect Date missing from the subscription version.		6	invalidAttributeValue_er
2003	Required New Service Provider ID missing from the subscription version.		6	invalidAttributeValue_er
2004	Required Old Service Provider ID missing from the subscription version.		6	invalidAttributeValue_er
2005	Required LRN missing.		6	invalidAttributeValue_er
2006	Required CLASS DPC missing.		6	invalidAttributeValue_er
2007	Required CLASS SSN missing.		6	invalidAttributeValue_er
2008	Required CNAM DPC missing.		6	invalidAttributeValue_er
2009	Required CNAM SSN missing.		6	invalidAttributeValue_er
2010	Required ISVM DPC missing.		6	invalidAttributeValue_er
2011	Required ISVM SSN missing.		6	invalidAttributeValue_er
2012	Required LIDB DPC missing.		6	invalidAttributeValue_er
2013	Required LIDB SSN missing.		6	invalidAttributeValue_er
2014	Required value for Date is missing from Network Data.		6	invalidAttributeValue_er
2015	Required value for Time is missing from Network Data.		6	invalidAttributeValue_er
2016	Required value for NPAC Customer Name is missing.		6	invalidAttributeValue_er
2017	Required value for NPAC Customer Id is missing.		6	invalidAttributeValue_er
2018	Required value for Transmission Media is missing from Network Data.		2	accessDenied_er
2019	Required value for NPAC Customer Type is missing from NPAC Customer.		6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		5

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
2020	Required value for Allowable Functions is missing from NPAC Customer.		2	accessDenied_er
2021	Required value for Download is missing from NPAC Customer.		2	accessDenied_er
2022	Required value for Maximum Query is missing from NPAC Customer.		2	accessDenied_er
2023	Required value for Contact Name is missing from NPAC Customer.		10	processingFailure_er
2024	Required value for Address Line 1 is missing from NPAC Customer.		10	processingFailure_er
2025	Required value for NPAC Customer City is missing from NPAC Customer.		10	processingFailure_er
2026	Required value for Repair Center City is missing from NPAC Customer.		10	processingFailure_er
2027	Required value for NPAC Customer State is missing from NPAC Customer.		10	processingFailure_er
2028	Required value for Repair Center State is missing from NPAC Customer.		10	processingFailure_er
2029	Required value for NPAC Customer Zip Code is missing from NPAC Customer.		10	processingFailure_er
2030	Required value for Repair Center Zip Code is missing from NPAC Customer.		10	processingFailure_er
2031	Required value for Pager is missing from NPAC Customer.		10	processingFailure_er
2032	Required value for Pager PIN is missing from NPAC Customer.		10	processingFailure_er
2033	Required value for Fax is missing from NPAC Customer.		10	processingFailure_er
2034	Required value for Email is missing from NPAC Customer.		10	processingFailure_er
2035	Required value for NSAP is missing from NPAC Customer.		10	processingFailure_er
2036	Required value for TSAP is missing from NPAC Customer.		10	processingFailure_er
2037	Required value for SSAP is missing from NPAC Customer.		10	processingFailure_er
2038	Required value for PSAP is missing from NPAC Customer.		10	processingFailure_er
2039	Required value for IP is missing from NPAC Customer.		6	invalidAttributeValue_er
2040	Invalid value for CLASS DPC entered.		6	invalidAttributeValue_er
2041	Invalid value for CLASS SSN entered.		6	invalidAttributeValue_er
2042	Invalid value for CNAM DPC entered.		6	invalidAttributeValue_er
2043	Invalid value for CNAM SSN entered.		6	invalidAttributeValue_er
2044	Invalid value for ISVM DPC entered.		6	invalidAttributeValue_er
2045	Invalid value for ISVM SSN entered.		6	invalidAttributeValue_er
2046	Invalid value for LIDB DPC entered.		6	invalidAttributeValue_er
2047	Invalid value for LIDB SSN entered.		6	invalidAttributeValue_er
2048	TN NPA contains invalid data.		6	invalidAttributeValue_er
2049	TN NXX contains invalid data.		6	invalidAttributeValue_er
2050	TN extension field contains invalid data.		6	invalidAttributeValue_er
2051	Month field contains invalid data.		6	invalidAttributeValue_er
2052	Day field contains invalid data.		6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		6

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
2053	Year field contains invalid data.		6	invalidAttributeValue_er
2054	TN range `through’ field (ending extension value) contains invalid data.		6	invalidAttributeValue_er
2055	The entered due date and time must be greater than or equal to today’s date and time.		6	invalidAttributeValue_er
2056	Billing Service Provider ID contains invalid data.		6	invalidAttributeValue_er
2057	End-User Location Value contains invalid data.		6	invalidAttributeValue_er
2058	End-User Location Type contains invalid data.		6	invalidAttributeValue_er
2059	Invalid value for Time entered.		6	invalidAttributeValue_er
2060	Invalid value for NPAC Customer Name entered.		6	invalidAttributeValue_er
2061	Invalid value for NPAC Customer Id entered.		6	invalidAttributeValue_er
2062	Invalid value for LRN entered.		6	invalidAttributeValue_er
2063	Invalid value for Transmission Media entered.		6	invalidAttributeValue_er
2064	Invalid value for NPAC Customer Type entered.		6	invalidAttributeValue_er
2065	Invalid value for Allowable Functions entered.		6	invalidAttributeValue_er
2066	Invalid value for Download entered.		6	invalidAttributeValue_er
2067	Invalid value for Maximum Query entered.		6	invalidAttributeValue_er
2068	Invalid value for Contact Name entered.		10	processingFailure_er
2069	Invalid value for Address Line 1 entered.		10	processingFailure_er
2070	Invalid value for Address Line 2 entered.		10	processingFailure_er
2071	Invalid value for City entered.		10	processingFailure_er
2072	Invalid value for State entered.		10	processingFailure_er
2073	Invalid value for Zip Code entered.		10	processingFailure_er
2074	Invalid value for Pager entered.		10	processingFailure_er
2075	Invalid value for Pager PIN entered.		10	processingFailure_er
2076	Invalid value for Fax entered.		10	processingFailure_er
2077	Invalid value for Email entered.		10	processingFailure_er
2078	Invalid value for NSAP entered.		10	processingFailure_er
2079	Invalid value for TSAP entered.		10	processingFailure_er
2080	Invalid value for SSAP entered.		10	processingFailure_er
2081	Invalid value for PSAP entered.		10	processingFailure_er
2082	Invalid value for IP entered.		6	invalidAttributeValue_er
2083	Identical values must be entered into both PASSWORD fields.		2	accessDenied_er
2084	Password field must be non-null.		6	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.		6	invalidAttributeValue_er
2086	Password may not contain the associated userid.		6	invalidAttributeValue_er
2087	Input attribute not recognized		2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		7

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
2088	Required value for contact type is missing from NPAC Customer.		10	processingFailure_er
2089	Required data for TN field(s) missing from contact list		10	processingFailure_er
2090	PDP Start Date cannot be modified while split is in progress		6	invalidAttributeValue_er
2091	Modify disconnect SVs must be in ‘disconnect-pending’ state.		2	accessDenied_er
2092	unnecessary optional field if old spid		6	invalidAttributeValue_er
2093	unnecessary sv_type if old spid		6	invalidAttributeValue_er
2094	unnecessary optional field if pto		6	invalidAttributeValue_er
2095	unnecessary sv_type if pto		6	invalidAttributeValue_er
2096	optional field is not valid		6	invalidAttributeValue_er
2097	sv_type is not valid		6	invalidAttributeValue_er
2098	spid supplied an optional field it does not support		6	invalidAttributeValue_er
2099	spid supports sv_type but fails to provide		18	missingAttributeValue
2100	optional field is not known		6	invalidAttributeValue_er
2101	unnecessary optional field		6	invalidAttributeValue_er
2102	unnecessary sv_type		6	invalidAttributeValue_er
2103	spid supplied sv_type it does not support		6	invalidAttributeValue_er
2105	SP must support linked reply for SWIM recovery		2	accessDenied_er
2106	SP requesting SWIM recovery does not support SWIM		2	accessDenied_er
2107	Action ID not valid		6	invalidAttributeValue_er
2108	Required service provider type is not supplied		6	invalidAttributeValue_er
2109	Service provider type is not valid		6	invalidAttributeValue_er
2110	SP is not allowed to modify service provider type		2	accessDenied_er
2111	Service provider type is not consistent with its name		6	invalidAttributeValue_er
2112	new SP can not resolve conflict with cause code of 50 or 51		2	accessDenied_er
2113	SV in wrong status for undo-cancel operation		1	noSuchObjectInstance
2114	SV in wrong new status for undo-cancel operation		6	invalidAttributeValue_er
2115	Undo-cancel originator SP has not canceled the SV		2	accessDenied_er
2116	Missing input data for undo-cancel operation		6	invalidAttributeValue_er
2117	SP exceeded LSMS or SOA SWIM recovery limit		10	processingFailure_er
2118	Undo Cancel Not Supported In This Region.		2	accessDenied_er
2119	SP Does Not Support SPID Recovery.		2	accessDenied_er
2120	A dashx operation can not be performed if there is an operation already scheduled.		2	accessDenied_er
3000	Value entered for system tunable is out of range.		2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		8

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
3001	You entered an invalid logon name or password.		6	invalidAttributeValue_er
3002	The User Group and User Level have conflicting access levels.		2	accessDenied_er
3003	Non-unique userid was entered for this user.		6	invalidAttributeValue_er
3004	Your password has expired.		2	accessDenied_er
3005	New password must differ from old passwords		2	accessDenied_er
3006	System was unable to add user		2	accessDenied_er
3007	Not all user data needed was provided		6	invalidAttributeValue_er
3008	Operation referenced a user that does not exist.		6	invalidAttributeValue_er
3009	Update of a tunable failed or tunable is missing.		2	accessDenied_er
3010	Unable to load holiday collection from DB.		10	processingFailure_er
3011	Unable to add a holiday to the collection		2	accessDenied_er
3012	Unable to delete a holiday from the collection		2	accessDenied_er
3013	Unable to find a holiday in the collection		2	accessDenied_er
3014	Event has incorrect subtype		6	invalidAttributeValue_er
3015	End time is before start time		6	invalidAttributeValue_er
3016	Start time is before now		6	invalidAttributeValue_er
3017	Tunable already exists		11	duplicateManagedObjectInstance
3018	Tunable doesn’t exist and must in order to be modified		1	noSuchObjectInstance
3019	Tunable has invalid value		6	invalidAttributeValue_er
3500	Password will expire in <x> days.		2	accessDenied_er
3501	The user about to be deleted is currently logged on to the system.		2	accessDenied_er
3502	This action will affect the entire NPAC SMS.		2	accessDenied_er
3503	Your password has expired.		2	accessDenied_er
3504	The NPAC is not accepting logins at this time		10	processingFailure_er
4000	Key List creation failure.		2	accessDenied_er
4001	Mismatch of hash values for key in key list.		10	processingFailure_er
4002	Failure calculating checksum for key list.		2	accessDenied_er
4003	No keys available for this NPAC Customer in any active key list.		2	accessDenied_er
4004	Non-unique keys found in key list.		6	invalidAttributeValue_er
4005	No active key list available for this NPAC Customer.		2	accessDenied_er
4006	Invalid Key File Format.		6	invalidAttributeValue_er
4007	Key List generation is already in progress.		2	accessDenied_er
4008	Illegal key list state change failure		2	accessDenied_er
4009	Missing required data in key management event		6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		9

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
4010	Key File event failed to process correctly		2	accessDenied_er
4011	New key specified by service provider is not usable		2	accessDenied_er
4012	Failure reading key file, invalid key data or list id.		6	invalidAttributeValue_er
4013	Failure reading keys from key list in database.		10	processingFailure_er
4500	There are fewer than 100 keys remaining for this Service Provider.		6	invalidAttributeValue_er
4750	No match found in the database for the search criteria.		1	noSuchObjectInstance
5000	Item being added already exists in the database.		11	duplicateManagedObjectInstance
5001	One or more subscriptions will be affected by change. Change is denied.		2	accessDenied_er
5002	One or more LRNs will be affected by change. Change/Delete is denied.		2	accessDenied_er
5003	One or more NPA-NXXs will be affected by change. Change/Delete is denied.		2	accessDenied_er
5004	Subscriptions in either partial failed or sending state are associated with the change. Change/Delete is denied.		2	accessDenied_er
5005	GTT data is not equivalent across TN range specified. Modify the TN range.		6	invalidAttributeValue_er
5006	Bulk Download — invalid criteria specified		10	processingFailure_er
5007	Bulk Download — file error		10	processingFailure_er
5008	Resync Data — invalid criteria specified		6	invalidAttributeValue_er
5009	LrnId is required if no customer id, on delete lrn action.		6	invalidAttributeValue_er
5010	The requested LRN does not exist in the NPAC SMS system.		1	noSuchObjectInstance
5011	No network data match for search criteria in database.		1	noSuchObjectInstance
5012	Requestor doesn’t own item being deleted.		2	accessDenied_er
5014	Resync Data — Maximum records reached or exceeded.		2	accessDenied_er
5015	Npa required for delete if no NpaNxxId.		6	invalidAttributeValue_er
5016	Nxx required for delete if no NpaNxxId.		6	invalidAttributeValue_er
5017	Lrn required for delete if no lrnId.		6	invalidAttributeValue_er
5018	NpaNxx Accept — invalid or missing npa		6	invalidAttributeValue_er
5019	NpaNxx Accept — invalid or missing nxx		6	invalidAttributeValue_er
5020	NpaNxx Accept — invalid or missing customer id		6	invalidAttributeValue_er
5021	NpaNxx Accept — invalid or missing accepted id		6	invalidAttributeValue_er
5022	CustomerId and name passed in do not match those in database.		6	invalidAttributeValue_er
5024	Ending npa/nxx doesn’t exist in database.		6	invalidAttributeValue_er
5027	Npa required for npa split.		6	invalidAttributeValue_er
5028	New Npa required for npa split.		6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		10

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
5031	PDP Start required for npa split.		6	invalidAttributeValue_er
5032	PDP End required for npa split.		6	invalidAttributeValue_er
5033	Resync Type required for resync.		6	invalidAttributeValue_er
5034	Resync Start TS required for resync.		6	invalidAttributeValue_er
5035	Npa required for resync of type npa range.		6	invalidAttributeValue_er
5036	Ending Npa required for resync of type npa range.		6	invalidAttributeValue_er
5037	Nxx required for resync of type npa range.		6	invalidAttributeValue_er
5038	Ending Nxx required for resync of type npa range.		6	invalidAttributeValue_er
5039	Lrn required for resync of type lrn range.		6	invalidAttributeValue_er
5040	End Lrn required for resync of type lrn range.		6	invalidAttributeValue_er
5041	No NpaNxx is available from the NPANXX::SelectRandom() method.		6	invalidAttributeValue_er
5042	Request failed on previous npaNxx.		10	processingFailure_er
5043	Request failed on previous lrn.		10	processingFailure_er
5044	There are no npanxx’s in the specified range		6	invalidAttributeValue_er
5045	Supplied customer id does not match any npanxx’s in range		6	invalidAttributeValue_er
5046	Resync rollup failed		2	accessDenied_er
5047	Resync returned zero records		2	accessDenied_er
5048	Resync time range exceeds duration tunable		2	accessDenied_er
5050	Active SVs found for the new NPA-NXX.		6	invalidAttributeValue_er
5051	Invalid Permissive Dialing Period Date entered.		6	invalidAttributeValue_er
5052	NPA-NXX Already involved in another split.		6	invalidAttributeValue_er
5053	Missing required data: NXX List.		6	invalidAttributeValue_er
5054	Missing required data: NPA Split Id.		6	invalidAttributeValue_er
5055	Permissive Dialing Period End Date must be after now.		6	invalidAttributeValue_er
5056	Missing required data: PDP End Date and/or Nxx List.		6	invalidAttributeValue_er
5057	Permissive Dialing Period Start Date must be after now.		6	invalidAttributeValue_er
5058	PDP Start date must be before PDP End date.		6	invalidAttributeValue_er
5059	PDP Start value must equal Effective timestamp of each new NPA-NXX involved in the split.		6	invalidAttributeValue_er
5060	New and old NPA-NXX records must be owned by same SP.		6	invalidAttributeValue_er
5061	Cannot Delete a split after the start of PDP.		6	invalidAttributeValue_er
5062	The NPA-NXX is currently involved in a split.		6	invalidAttributeValue_er
5070	FAILURE attempting to update NPA-NXX.		2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		11

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
5071	FAILURE attempting to delete NPA_SPLIT_LOG records.		2	accessDenied_er
5072	FAILURE attempting to delete NPA_SPLIT records.		2	accessDenied_er
5073	Delete denied due to associated NPA-NXX-Xs.		6	invalidAttributeValue_er
5074	Block action denied due to spid not owning lrn.		6	invalidAttributeValue_er
5075	Create block failed due to too many tns in block.		6	invalidAttributeValue_er
5076	Create block failed due to tns already in another block.		6	invalidAttributeValue_er
5077	NPA-NXX-X action denied due to effective date before NpaNxx effective ts.		6	invalidAttributeValue_er
5078	Block id is required for block modify.		6	invalidAttributeValue_er
5079	Lrn or GTT Data is required for block modify.		6	invalidAttributeValue_er
5080	Block does not exist in database.		6	invalidAttributeValue_er
5081	NPA-NXX-X delete denied due to non-active block.		2	accessDenied_er
5082	Customer delete denied due to associated NPA-NXX-Xs.		6	invalidAttributeValue_er
5083	BlockId does not exist in the NPAC system.		6	invalidAttributeValue_er
5084	The TUNA_MAXIMUM_BLOCK_RANGE value for querying blocks is missing.		6	invalidAttributeValue_er
5085	Blocks found: exceed maximum query limit.		10	processingFailure_er
5086	Block Holder cannot equal the code holder.		6	invalidAttributeValue_er
5087	The NpaNxxAcceptId does not exist in the NpaNxxAcceptTable.		6	invalidAttributeValue_er
5088	NPA-NXX-X action denied: effective date is before NPA-NXX live timestamp.		2	accessDenied_er
5089	SV action denied because due date is before NPA-NXX live timestamp.		2	accessDenied_er
5090	NetworkNotificationRecoveryAction time range is invalid		6	invalidAttributeValue_er
5091	NetworkNotificationRecoveryAction time range exceeds tunable		2	accessDenied_er
5092	NPA-NXX-X delete denied due to associated failed LSMS entries.		2	accessDenied_er
5093	Pending-like with active pooled SVs and Pending-like PTO SVs exist.		2	accessDenied_er
5094	Cannot delete NPA-NXX-X using new Npa for a scheduled split.		2	accessDenied_er
5095	The NPA-NXX-X ID is required.		6	invalidAttributeValue_er
5096	No matching NPA-NXX-X exists in the database.		1	noSuchObjectInstance
5097	The NPA-NXX-X is required.		18	missingAttributeValue
5098	The SOA Origination Indicator is required.		18	missingAttributeValue

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		12

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
5099	A scheduled create block event is required.		18	missingAttributeValue
5100	The effective date specified for the DashX is prior to today.		6	invalidAttributeValue_er
5101	Block Create request is before NPA-NXX-X’s effective date.		6	invalidAttributeValue_er
5102	A pending/conflict/cancel-pending/failed PTO SV exists.		2	accessDenied_er
5103	LIDB SSN is not allowed.		6	invalidAttributeValue_er
5104	LIDB DPC is not allowed.		6	invalidAttributeValue_er
5105	ISVM SSN is not allowed.		6	invalidAttributeValue_er
5106	ISVM DPC is not allowed.		6	invalidAttributeValue_er
5107	CNAM SSN is not allowed.		6	invalidAttributeValue_er
5108	CNAM DPC is not allowed.		6	invalidAttributeValue_er
5109	CLASS SSN is not allowed.		6	invalidAttributeValue_er
5110	CLASS DPC is not allowed.		6	invalidAttributeValue_er
5111	LRN is not allowed.		6	invalidAttributeValue_er
5112	A pooled block already exists.		2	accessDenied_er
5113	Cannot modify an NPA-NXX-X using the new Npa of a scheduled split.		2	accessDenied_er
5114	Cannot create an NPA-NXX-X using the new Npa of a scheduled split.		2	accessDenied_er
5115	Effective date is not allowed.		6	invalidAttributeValue_er
5116	An NPA-NXX-X exists for the new Npa.		2	accessDenied_er
5117	PDP Start, PDP End, or NXX List must be supplied in modify request.		6	invalidAttributeValue_er
5118	New NPA-NXX already exists.		6	invalidAttributeValue_er
5119	PDP Start Date cannot be changed if pending SVs exist in new NPA-NXX		6	invalidAttributeValue_er
5120	At least one of old and new NPA-NXX must exist.		6	invalidAttributeValue_er
5121	PDP Start date cannot change after PDP Start.		6	invalidAttributeValue_er
5122	An SV exists in both the old and new NPA-NXX.		6	invalidAttributeValue_er
5123	A DashX exists in the new NPA-NXX.		6	invalidAttributeValue_er
5124	Cannot create LISP PTO with scheduled block creation.		2	accessDenied_er
5125	Deferred disconnect timer is firing, modify denied.		2	accessDenied_er
5126	LRN specified for SV is in a different LATA from TN.		6	invalidAttributeValue_er
5127	LRN specified for Block is in a different LATA from DashX.		6	invalidAttributeValue_er
5128	SPID migration file open error.		6	invalidAttributeValue_er
5129	LATA ID Not Found in the LATA File.		6	invalidAttributeValue_er
5130	LATA File Access Error.		6	invalidAttributeValue_er
5131	Notification recovered exceeded max tunable for sp supports linked reply.		2	accessDenied_er
5132	BDD response file invalid		6	invalidAttributeValue_er
5133	Processing BDD response file failed		2	accessDenied_er
5134	Consistency check failed for network item (i.e. LRN, NPANXX, and DashX)		2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		13

Appendix A: Errors

SMS Error	Description	CMIP Error		Description
5135	NPA-NXX not valid for this region.		6	invalidAttributeValue_er
5500	One or more subscriptions will be affected by change. Require user acknowledgment to proceed.		2	accessDenied_er
6000	Item being added already exists in the database.		6	invalidAttributeValue_er
6001	One or more subscriptions will be affected by change. Change is denied.		2	accessDenied_er
6002	One or more npa-nxxs are associated with this customer, Delete is denied.		2	accessDenied_er
6003	One or more lrns are associated with this customer, Delete is denied.		2	accessDenied_er
6004	NPAC Customer ID cannot be modified.		6	invalidAttributeValue_er
6005	The NPAC Customer being modified does not exist in the database.		1	noSuchObjectInstance
6006	The NPAC Customer being deleted does not exist in the database, or has already been deleted.		1	noSuchObjectInstance
6007	Invalid contact type for NPAC Customer		10	processingFailure_er
6008	The contact info array is missing from the Customer.		6	invalidAttributeValue_er
6009	The network address list array is missing from the Customer.		6	invalidAttributeValue_er
6010	The network address type is missing from the Customer.		10	processingFailure_er
6011	The npac customer contact is missing from the Customer.		10	processingFailure_er
6012	The billing contact is missing from the Customer.		10	processingFailure_er
6013	The security contact is missing from the Customer.		10	processingFailure_er
6014	The repair contact is missing from the Customer.		10	processingFailure_er
6015	At least one network address is required for Customer.		6	invalidAttributeValue_er
6016	Required value for Contact Name is missing from Billing Contact.		10	processingFailure_er
6017	Required value for Address Line 1 is missing from Billing Contact.		10	processingFailure_er
6018	Required value for NPAC Customer City is missing from Billing Contact.		10	processingFailure_er
6019	Required value for NPAC Customer State is missing from Billing Contact.		10	processingFailure_er
6020	Required value for NPAC Customer Zip Code is missing from Billing Contact.		10	processingFailure_er
6021	Required value for Contact Name is missing from Repair Contact.		10	processingFailure_er
6022	Required value for Address Line 1 is missing from Repair Contact.		10	processingFailure_er
6023	Required value for Contact Name is missing from Security Contact.		10	processingFailure_er
6024	Required value for Address Line 1 is missing from Security Contact.		10	processingFailure_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		14

Appendix A: Errors

6025	Required value for NPAC Customer City is missing from Security Contact.	10	processingFailure_er
6026	Required value for NPAC Customer State is missing from Security Contact.	10	processingFailure_er
6027	Required value for NPAC Customer Zip Code is missing from Security Contact.	10	processingFailure_er
6028	Event subtype not recognized	6	invalidAttributeValue_er
6029	Invalid operation for this NPAC Customer	2	accessDenied_er
6030	SP User cannot modify Customer Name on modify.	6	invalidAttributeValue_er
6031	SP User cannot modify allowable functions mask on modify.	6	invalidAttributeValue_er
6032	Required value for country is missing from contact data.	10	processingFailure_er
6033	SP block indicator must be only attribute on event	6	invalidAttributeValue_er
6034	LTI-Only Customer attribute missing from event	6	invalidAttributeValue_er
6035	SP can not modify sp block indicator flag	6	invalidAttributeValue_er
6036	Customer cannot be deleted if associated with primary or secondary customer	6	invalidAttributeValue_er
6037	Active customer to modify or delete does not exist	2	accessDenied_er
6038	Customer cannot be modified to LTI User if associated customers exist.	6	invalidAttributeValue_er
6039	Customer Request denied due to duplicate Network Address PSAP.	6	invalidAttributeValue_er
6040	Customer does not exist and cannot be added as a Secondary Customer.	1	noSuchObjectInstance
6041	This customer must be removed from all router config lists before it can be deleted.	2	accessDenied_er
6500	One or more subscriptions will be affected by change. Require user acknowledgment to proceed.	6	invalidAttributeValue_er
6750	No match found in the database for the search criteria.	1	noSuchObjectInstance
6751	<x> Subscriptions found: exceed maximum query limit.	6	invalidAttributeValue_er
6752	No subscription versions found for the given input search criteria.	1	noSuchObjectInstance
6753	Warning — Primary Customer has no SOA Functionality Set.	6	invalidAttributeValue_er
6754	Warning — Secondary Customer has no SOA Functionality Set.	6	invalidAttributeValue_er
7000	The NPA-NXX for this operation does not exist in the NPAC SMS system.	1	noSuchObjectInstance
7001	Service Provider ID does not exist in the NPAC SMS system.	6	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	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		15

Appendix A: Errors

7003	This Service Provider has already issued a create for the subscription version.	11	duplicateManagedObjectInstance
7004	The entered LRN is not associated with the New Service Provider in the NPAC SMS system.	6	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.	2	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.	2	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.	2	accessDenied_er
7008	Releasing a subscription version for an Intra-Service Provider port does not apply.	2	accessDenied_er
7009	The Old Service Provider ID must match the New Service Provider ID for an Intra-Service Port.	6	invalidAttributeValue_er
7010	The New and Old Service Provider Due Dates must match.	6	invalidAttributeValue_er
7011	An active subscription version must exist for an Intra-SP port.	2	accessDenied_er
7012	A subscription version with sending status cannot be modified.	2	accessDenied_er
7013	A subscription version with failed status cannot be modified.	2	accessDenied_er
7014	A subscription version with partial failure status cannot be modified.	2	accessDenied_er
7015	A subscription version with canceled status cannot be modified.	2	accessDenied_er
7016	A subscription version with old status cannot be modified.	2	accessDenied_er
7017	A subscription version with disconnect pending status cannot be modified.	2	accessDenied_er
7018	A subscription version with cancel pending status cannot be modified.	2	accessDenied_er
7019	A subscription version must be in pending status to be activated.	2	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.	2	accessDenied_er
7021	The Service Provider originating the modification request is not the current Service Provider.	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		16

Appendix A: Errors

7022	The subscription version cannot be put in conflict because its current status is not pending, or cancel pending.	2	accessDenied_er
7023	The subscription version cannot be disconnected because there is no current subscription version in active status.	2	accessDenied_er
7024	This active subscription version cannot be disconnected until a sending subscription version successfully completes.	2	accessDenied_er
7025	This active subscription version cannot be disconnected until a failed or partial failure subscription version is re-sent and successfully completes.	2	accessDenied_er
7026	The subscription version cannot be canceled because its current status is not pending, conflict or disconnect pending.	2	accessDenied_er
7027	The subscription version cannot be resent because its current status is not partial failure, failure, disconnect pending, old or active.	2	accessDenied_er
7028	Active subscription version may not be modified because a related subscription version for this TN has been activated.	2	accessDenied_er
7029	Pending subscription version may not be activated until a related subscription version in sending status becomes active.	2	accessDenied_er
7030	Deferred disconnect request is not allowed because a pending subscription version exists for this TN.	2	accessDenied_er
7031	This subscription version may not be activated because authorization for transfer of service has not been received from the New SP.	2	accessDenied_er
7032	The due date of a subscription version with active status cannot be modified.	6	invalidAttributeValue_er
7033	Porting To Original must be false for inter-service ports.	6	invalidAttributeValue_er
7034	Required Port Type is missing from input data.	6	invalidAttributeValue_er
7035	Required TN data (NPA) is missing from input data.	6	invalidAttributeValue_er
7036	Required TN data (NXX) is missing from input data.	6	invalidAttributeValue_er
7037	Required TN data (starting station) is missing from input data.	6	invalidAttributeValue_er
7038	Required TN data (ending station) is missing from input data.	6	invalidAttributeValue_er
7039	Required Old Service Provider Authorization Flag missing from the subscription version.	6	invalidAttributeValue_er
7040	Required Porting To Original Flag is missing from input data.	6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		17

Appendix A: Errors

7041	NPAC SMS allows only one of pending, cancel pending, conflict, disconnect pending, failed or partial failure Subscription Version per TN.	6	invalidAttributeValue_er
7043	LIDB SSN is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7044	LIDB SSN is not allowed for old service provider input.	6	invalidAttributeValue_er
7045	LIDB DPC is not allowed for old service provider input.	6	invalidAttributeValue_er
7046	LIDB DPC is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7047	ISVM SSN is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7048	ISVM SSN is not allowed for old service provider input.	6	invalidAttributeValue_er
7049	ISVM DPC is not allowed for old service provider input.	6	invalidAttributeValue_er
7050	ISVM DPC is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7051	CNAM SSN is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7052	CNAM SSN is not allowed for old service provider input.	6	invalidAttributeValue_er
7053	CNAM DPC is not allowed for old service provider input.	6	invalidAttributeValue_er
7054	CNAM DPC is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7055	CLASS SSN is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7056	CLASS SSN is not allowed for old service provider input.	6	invalidAttributeValue_er
7057	CLASS DPC is not allowed for old service provider input.	6	invalidAttributeValue_er
7058	CLASS DPC is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7059	LRN is not allowed for Porting-to-Original ports.	6	invalidAttributeValue_er
7060	LRN is not allowed for old service provider input.	6	invalidAttributeValue_er
7061	New Service Provider due date is not allowed for Old Service Provider input.	6	invalidAttributeValue_er
7062	Old Service Provider due date is not allowed for New Service Provider input.	6	invalidAttributeValue_er
7063	Old Service Provider Authorization Flag is not allowed for New Service Provider input.	6	invalidAttributeValue_er
7064	Old Service Provider Authorization Flag is not allowed for Intra-Service Ports.	6	invalidAttributeValue_er
7065	Billing Service Provider ID is not allowed for Old Service Provider input.	6	invalidAttributeValue_er
7066	End User Location is not allowed for Old Service Provider input.	6	invalidAttributeValue_er
7067	End User Location Type is not allowed for Old Service Provider input.	6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		18

Appendix A: Errors

7068	Either the Ported Telephone Number or the Subscription Version ID is required to activate a subscription version.	6	invalidAttributeValue_er
7069	The Old Service Provider cannot modify an intra-service port.	2	accessDenied_er
7070	Only the Current Service Provider can disconnect a subscription version.	2	accessDenied_er
7071	SV cannot be disconnected if it has failed list, or an active-like, or pending-like SV exists for that TN	2	accessDenied_er
7072	The subscription version cannot be removed from conflict because its current status is not conflict.	2	accessDenied_er
7073	Only the Current Service Provider can activate a subscription version.	6	invalidAttributeValue_er
7074	A pending subscription version cannot be activated before its npa_nxx’s effective date.	6	invalidAttributeValue_er
7075	NPAC SMS allows only one sending Subscription Version per TN.	2	accessDenied_er
7076	NPAC SMS allows only one active Subscription Version per TN.	2	accessDenied_er
7077	Request failed on previous subscription version.	10	processingFailure_er
7078	Required subscription version ID is missing from input data.	6	invalidAttributeValue_er
7079	Required TimerId is missing from input data.	2	accessDenied_er
7080	Required ConflictDate is missing from input data.	6	invalidAttributeValue_er
7081	Required PendingDate is missing from input data.	6	invalidAttributeValue_er
7082	The Service Provider requesting this cancel did not create the subscription version.	2	accessDenied_er
7083	There is no subscription version with the requested status.	6	invalidAttributeValue_er
7084	The subscription version status is required to modify a subscription version.	6	invalidAttributeValue_er
7085	The action ID field is required for LsmsSvNotifyResponseEvent event type.	10	processingFailure_er
7086	The old service provider cannot request conflict resolution.	2	accessDenied_er
7087	Mass Update requires at least one of the following as input:	6	invalidAttributeValue_er
	LRN, a gtt data item, billing id, end user location, end user location type.
7088	Active subscription versions cannot be modified via CMIP set.	2	accessDenied_er
7089	The Old Service Provider has already put this subscription version into conflict the maximum number of times.	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		19

Appendix A: Errors

7090	It is too close to the New Service Provider due date for the Old Service Provider to place the subscription version into conflict.	2	accessDenied_er
7091	This subscription version may not be activated because the Old Service Provider’s concurrence window has not yet expired.	2	accessDenied_er
7092	Required originating SPID is missing from input data.	6	invalidAttributeValue_er
7093	SV — Notification SV_MODIFIED missing response.	6	invalidAttributeValue_er
7094	Either the Ported Telephone Number or the Subscription Version ID is required to modify a subscription version.	6	invalidAttributeValue_er
7095	Required Resync Type is missing from input data.	6	invalidAttributeValue_er
7096	Required Resync Start Timestamp is missing from input data.	6	invalidAttributeValue_er
7097	Either the Ported Telephone Number or the Subscription Version ID is required to cancel a subscription version.	6	invalidAttributeValue_er
7098	Either the Ported Telephone Number or the Subscription Version ID is required to resolve a conflicted subscription version.	6	invalidAttributeValue_er
7099	Either the Ported Telephone Number or the Subscription Version ID is required to disconnect a subscription version.	6	invalidAttributeValue_er
7100	Either the Ported Telephone Number or the Subscription Version ID is required to create a subscription version.	6	invalidAttributeValue_er
7101	The NPA-NXX of the TN has been split. The entered TN is the old NPA-NXX.	6	invalidAttributeValue_er
7102	Either the subscription version ID or TN is required for concurrence.	6	invalidAttributeValue_er
7104	The Status Change Cause Code is required if the authorization flag is false.	6	invalidAttributeValue_er
7105	The Status Change Cause Code cannot be set if the authorization flag is true.	6	invalidAttributeValue_er
7106	The Status Change Cause Code cannot be set if the new service provider is the originator.	6	invalidAttributeValue_er
7107	Invalid Status Change Cause Code.	6	invalidAttributeValue_er
7108	A pending subscription version cannot be activated before its due date.	6	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.	6	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.	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		20

Appendix A: Errors

7111	Porting To Original Flag is not allowed for old service provider input.	6	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.	10	processingFailure_er
7113	LSMS did not respond in allotted time.	10	processingFailure_er
7114	Missing SV Tunable value.	6	invalidAttributeValue_er
7115	The Status Change Cause Code is required if the old service provider is the originator.	6	invalidAttributeValue_er
7116	The subscription version cannot be resent because it does not have a failed LSMS list.	2	accessDenied_er
7117	Either the due date or the authorization flag is required to modify a subscription version by the old Service Provider.	6	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.	6	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.	2	accessDenied_er
7120	The LNP Type input in the event does not match the LNP type of a pending SV for this TN.	6	invalidAttributeValue_er
7121	A subscription version with cancel pending status exists. A new one cannot be created for this TN.	2	accessDenied_er
7122	A pending subscription version for the TN exists.	2	accessDenied_er
7123	A subscription version with disconnect pending status exists. A new one cannot be created for this TN.	2	accessDenied_er
7124	The old authorization flag of a subscription version with active status cannot be modified.	6	invalidAttributeValue_er
7125	The change cause code of a subscription version with active status cannot be modified.	6	invalidAttributeValue_er
7126	A Failed subscription version for the TN exists. This failure must be resolved before a modify is allowed.	2	accessDenied_er
7127	There is no subscription version matching the query filter data.	1	noSuchObjectInstance
7128	The Service Provider requesting this modify did not create the subscription version.	2	accessDenied_er
7129	The Ending Station must be a number greater than the Starting Station.	6	invalidAttributeValue_er
7130	The LNP Type must be either LISP or LSPP.	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		21

Appendix A: Errors

7131	The Old Service Provider cannot cancel a disconnect pending subscription version.	2	accessDenied_er
7132	A subscription version with sending status exists. A new one cannot be created for this TN.	2	accessDenied_er
7133	The Service Provider requesting this conflict did not create the subscription version.	2	accessDenied_er
7134	Waiting on New SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.	2	accessDenied_er
7135	Waiting on Old SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.	2	accessDenied_er
7136	There must be an active non-Pooled SV for a porting to original port.	2	accessDenied_er
7137	The requested subscription version does not exist.	1	noSuchObjectInstance
7138	A subscription version with pending status exists. A new one cannot be created for this TN.	2	accessDenied_er
7139	The Service Provider requesting this conflict resolution did not create the subscription version.	2	accessDenied_er
7140	The Old Service Provider ID must not match the New Service Provider ID for an Inter-Service Port.	6	invalidAttributeValue_er
7141	Subscription version must be in cancel pending state for concurrence.	2	accessDenied_er
7142	The action ID does not belong to originator.	10	processingFailure_er
7143	NPAC SMS allows only two sending Subscription Versions per tn for port to original.	2	accessDenied_er
7144	The change cause code of a subscription version cannot be modified if it is already set.	6	invalidAttributeValue_er
7145	NPAC SMS allows only three sending Subscription Versions per tn for port to original of sv in block.	2	accessDenied_er
7146	The user originating the Block request is not an NPAC Personnel user.	2	accessDenied_er
7148	The New Service Provider ID must match the Block Holder ID for a Block.	6	invalidAttributeValue_er
7149	Required BlockId is missing from input data.	6	invalidAttributeValue_er
7150	Old Service Provider due date is not allowed for a block creation.	6	invalidAttributeValue_er
7151	Old Service Provider ID is not allowed for a block.	6	invalidAttributeValue_er
7152	LRN is not allowed for a block.	6	invalidAttributeValue_er
7163	A pending subscription version exists for this NPA-NXX-X. A block cannot be created.	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		22

Appendix A: Errors

7164	New Service Provider due date is not allowed for a block.	6	invalidAttributeValue_er
7165	A block cannot be created before the NPA-NXX-X’s effective date.	2	accessDenied_er
7166	A block cannot be created before the NpaNxx’s effective date.	2	accessDenied_er
7167	A subscription version with LNP Type POOL cannot be activated.	2	accessDenied_er
7168	Only NPAC Personnel may disconnect a pooled SV.	2	accessDenied_er
7169	Effective Release Date cannot be set for pooled SV disconnect.	6	invalidAttributeValue_er
7170	NPAC SMS allows only two sending Subscription Versions per tn for ports of SVs in a block.	2	accessDenied_er
7171	New Service Provider ID is not allowed for a block create.	6	invalidAttributeValue_er
7172	All TNs in the block range are currently ported.	2	accessDenied_er
7173	An old subscription version with a failed LSMS list exists. A new one cannot be created.	2	accessDenied_er
7174	The new SP for this Port To Original SV is not the donor of the NpaNxx.	2	accessDenied_er
7175	Time Range exceeds tunable value.	6	invalidAttributeValue_er
7176	Delete denied, tunable does not exist.	1	noSuchObjectInstance
7177	Create denied, tunable already exists.	11	duplicateManagedObjectInstance
7178	Modify denied, tunable does not exist.	1	noSuchObjectInstance
7179	WSMSC DPC required if SOA supports it.	6	invalidAttributeValue_er
7180	WSMSC SSN required if SOA supports it.	6	invalidAttributeValue_er
7181	WSMSC DPC not valid input for this action.	6	invalidAttributeValue_er
7182	WSMSC SSN not valid input for this action.	6	invalidAttributeValue_er
7183	Query expression required on mass update.	6	invalidAttributeValue_er
7184	Either subscription version ID, block ID, TN or all failures is required on resend.	6	invalidAttributeValue_er
7185	Cannot retrieve svs from temp table.	10	processingFailure_er
7186	The Event does not contain any data to process.	6	invalidAttributeValue_er
7187	Failure changing viewed indicator.	10	processingFailure_er
7188	Modify failed: the notification does not exist in the database.	6	invalidAttributeValue_er
7189	Either BlockId or NPA-NXX-X and status are required for block modify	6	invalidAttributeValue_er
7190	NPA-NXX-X is required for block create	6	invalidAttributeValue_er
7191	Cannot create LISP, after dashX creation, before block is created	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		23

Appendix A: Errors

7192	Pending like svs exist with matching pto svs	2	accessDenied_er
7193	Non active non pooled svs exist	2	accessDenied_er
7194	Only npac personnel can create lisp with pending block creation	2	accessDenied_er
7195	New sp of lisp create must be code holder with pending block creation	2	accessDenied_er
7196	Cannot create lisp if active sv exists and pending block creation	2	accessDenied_er
7197	Cannot create lspp with pending block creation	2	accessDenied_er
7198	Cannot create sv if dashx has failed lsms list	2	accessDenied_er
7199	WSMSC DPC entered is invalid	6	invalidAttributeValue_er
7200	WSMSC SSN entered is invalid	6	invalidAttributeValue_er
7201	Can only modify pooled svs with block modify request	2	accessDenied_er
7202	Only npac personnel can modify the soa indicator	6	invalidAttributeValue_er
7203	Cannot modify pooled block if block has failed lsms list	2	accessDenied_er
7204	Cannot modify non active pooled svs	2	accessDenied_er
7205	Cannot activate lisp if active sv exists	2	accessDenied_er
7206	Cannot activate pto during dashx deletion.	2	accessDenied_er
7207	Cannot activate pto due to failed dashX deletion.	2	accessDenied_er
7208	Cannot cancel a pooled sv	2	accessDenied_er
7209	Cannot conflict a pooled sv	2	accessDenied_er
7210	Pending-like SVs exist with no matching active SVs.	2	accessDenied_er
7211	Can only modify one pooled block at a time.	2	accessDenied_er
7212	Mass Update of pooled block must wholly encompass block.	2	accessDenied_er
7213	You cannot resend a pooled SV.	2	accessDenied_er
7214	No subscription versions found for the given input search criteria.	1	noSuchObjectInstance
7215	Subscriptions found exceed maximum query limit.	20	complexityLimitation
7216	Subscription version must be in pending or conflict state for create timeout.	2	accessDenied_er
7217	Subscription version must be in cancel pending state for cancel timeout.	2	accessDenied_er
7218	The old customer id on the create does not match the owner of the associated npa-nxx.	2	accessDenied_er
7219	Found active-like SV for block creation.	6	invalidAttributeValue_er
7220	A subscription version’s due date cannot be before its npa_nxx’s effective date.	6	invalidAttributeValue_er
7221	Status change cause code is not allowed on an LISP creation, modification, or set to conflict.	6	invalidAttributeValue_er
7222	Old due date is not allowed on an LISP creation or modification.	6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		24

Appendix A: Errors

7223	A subscription version with failed status exists. A new one cannot be created for this TN.	2	accessDenied_er
7224	A subscription version with partial failed status exists. A new one cannot be created for this TN.	2	accessDenied_er
7225	Recovered objects found exceed maximum limit.	20	complexityLimitation
7226	An active subscription version with failed list can not be modified. This failure must be resolved before a modify is allowed.	2	accessDenied_er
7227	Old SP cant modify NewSPDueDate Or RoutingData.	2	accessDenied_er
7228	New SP cant modify OldSPDueDate, Authorization or CauseCode.	2	accessDenied_er
7229	Slow SV query denied, system workload too high.	10	processingFailure_er
7230	Slow SV query denied, too many outstanding slow queries for this SP.	10	processingFailure_er
7231	SV query denied, too many outstanding queries for this SP.	10	processingFailure_er
7500	The entered due date differs from the due date entered by the other Service Provider.	6	invalidAttributeValue_er
7751	Block successfully activated.	10	processingFailure_er
7752	Block successfully modified.	10	processingFailure_er
7753	Block successfully disconnected.	10	processingFailure_er
7754	Block activate partially failed.	10	processingFailure_er
7755	Block modify partially failed.	10	processingFailure_er
7756	Block disconnect partially failed.	10	processingFailure_er
7757	Block activate totally failed.	10	processingFailure_er
7758	Block modify totally failed.	10	processingFailure_er
7759	Block disconnect totally failed.	10	processingFailure_er
7760	Found Same TN for Old and New NPA at Start of PDP.	10	processingFailure_er
7761	No more than three related svs are allowed.	2	accessDenied_er
7762	With three related svs, one must be pooled in old, partial failed, failed or sending status.	2	accessDenied_er
7763	With three related svs, one must be pto.	2	accessDenied_er
7764	With three related svs, one must be non-pto and non-pooled.	2	accessDenied_er
7765	With two related svs, at least one must be non-pto.	2	accessDenied_er
7766	With no related svs, the sv cannot be pto.	2	accessDenied_er
9000	Invalid date entered.	6	invalidAttributeValue_er
9001	Invalid time entered.	6	invalidAttributeValue_er
9002	Audit Profile name too long.	6	invalidAttributeValue_er
9003	Invalid TN data entered.	6	invalidAttributeValue_er
9004	Audit Profile name is not unique.	11	duplicateManagedObjectInstance
9005	No audits match the entered criteria.	6	invalidAttributeValue_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		25

Appendix A: Errors

9006	Could not cancel specified Audit(s)	6	invalidAttributeValue_er
9007	Audit validation failed.	6	invalidAttributeValue_er
9008	No LSMSs to audit.	6	invalidAttributeValue_er
9009	Need required event input data	6	invalidAttributeValue_er
9010	Failed to generate a unique name for a periodic audit.	6	invalidAttributeValue_er
9011	Failed to generate a discrepancy for an SV mismatch.	6	invalidAttributeValue_er
9012	Failed to issue query events.	6	invalidAttributeValue_er
9013	Starting Station > Ending Station Error	6	invalidAttributeValue_er
9014	CMIP bounced, which killed our query.	6	invalidAttributeValue_er
9015	We can’t use input data that conflicts with itself	6	invalidAttributeValue_er
9016	Failed to issue SP Notification events.	10	processingFailure_er
9017	Failed to retrieve allowable function mask	6	invalidAttributeValue_er
9018	Event Process failed	10	processingFailure_er
9019	Discrepancy created with invalid reason code.	6	invalidAttributeValue_er
9500	NPA does not exist in the NPAC SMS data.	6	invalidAttributeValue_er
9501	NPA-NXX combination does not exist in the NPAC SMS data.	6	invalidAttributeValue_er
9750	No TNs found within the range entered.	1	noSuchObjectInstance
9751	No results have yet been reported for the selected audit.	6	invalidAttributeValue_er
10000	Invalid NPA data entered.	6	invalidAttributeValue_er
10001	Invalid NXX data entered.	6	invalidAttributeValue_er
10002	Invalid LRN data entered.	6	invalidAttributeValue_er
10003	Invalid range for NXXs (second must be greater than first).	6	invalidAttributeValue_er
10004	Invalid range for LRNs (second must be greater than first).	6	invalidAttributeValue_er
10005	Invalid printer name entered.	6	invalidAttributeValue_er
10006	Too many characters entered in printer field.	6	invalidAttributeValue_er
10007	Invalid TN entered in fax field.	10	processingFailure_er
10008	Too many characters entered in file name field.	6	invalidAttributeValue_er
10009	Invalid file name entered.	6	invalidAttributeValue_er
10010	No generated file name entered.	2	accessDenied_er
10011	No destination designated for report.	2	accessDenied_er
10012	Invalid date entered.	6	invalidAttributeValue_er
10013	Invalid parameters detected in Report Parameters.	6	invalidAttributeValue_er
10014	End date occurs before the start date.	6	invalidAttributeValue_er
10015	Requester does not have privileges to generate this report.	2	accessDenied_er
10016	Event missing customer ID	6	invalidAttributeValue_er
10017	No existing report or incorrect permissions	2	accessDenied_er
10018	Failure scanning existing report directory	2	accessDenied_er
10019	Failure opening existing report directory	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		26

Appendix A: Errors

10020	Failure retrieving originator information	2	accessDenied_er
10021	Failure printing report file	2	accessDenied_er
10022	Failure emailing report file	2	accessDenied_er
10023	Failure faxing report file	2	accessDenied_er
10024	Failure moving report file	2	accessDenied_er
10025	Failure renaming report file	2	accessDenied_er
10026	Failure running report	10	processingFailure_er
10750	No billing data exists for the entered criteria.	2	accessDenied_er
10751	Unknown report name for report id.	2	accessDenied_er
11000	Invalid date entered.	6	invalidAttributeValue_er
11001	Invalid printer name entered.	6	invalidAttributeValue_er
11002	Too many characters entered in printer field.	6	invalidAttributeValue_er
11003	Invalid TN entered in fax field.	10	processingFailure_er
11004	Too many characters entered in file name field.	6	invalidAttributeValue_er
11005	End date occurs before the start date.	6	invalidAttributeValue_er
11006	You cannot post-date service element collection changes.	2	accessDenied_er
11007	Invalid file name entered.	6	invalidAttributeValue_er
11008	Incomplete Request Parameter Set.	2	accessDenied_er
11009	Invalid category for billing	6	invalidAttributeValue_er
11010	Invalid Multiplier Specified.	6	invalidAttributeValue_er
11011	Unable To Read Multiplier.	2	accessDenied_er
11500	Unable to connect to entered fax number.	2	accessDenied_er
12000	Oracle RDBMS has reported the following Database Server Error:	2	accessDenied_er
	ORA-nnnnn
12001	Oracle RDBMS has reported the following SQL Execution Error:	2	accessDenied_er
	ORA-nnnnn
12002	Oracle RDBMS has reported the following Stored Procedure/Trigger Error: ORA-nnnnn	2	accessDenied_er
12003	Oracle RDBMS has reported the following Database Networking (SQL*NET) Error: ORA-nnnnn	2	accessDenied_er
12004	Oracle RDBMS has reported the following Replication Server Error ORA-nnnnn	2	accessDenied_er
12005	Oracle RDBMS has reported the following Report Writer Error:	2	accessDenied_er
	ORA-nnnnn
12006	Oracle RDBMS database has been disconnected.	2	accessDenied_er
12110	Dispatcher found bad event	2	accessDenied_er
12120	Corrupt data found	2	accessDenied_er
12140	Resource Failure	10	processingFailure_er
12150	Hard (non-retryable) Resource Failure	10	processingFailure_er
13000	Housekeeping error	6	invalidAttributeValue_er
13001	Housekeeping tuna value error	2	accessDenied_er
13002	Invalid event subtype	2	accessDenied_er

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		27

Appendix A: Errors

13003	Tunable Not Found	2	accessDenied_er
13004	InvalidPurgeAction	2	accessDenied_er
14000	CMIP:Access Denied Error	2	accessDenied_er
14001	CMIP:Class Instance Conflict	19	classInstanceConflict
14002	CMIP:Complexity Limitation	20	complexityLimitation
14003	CMIP:Duplicate Managed Object Instance	11	duplicateManagedObjectInstance
14004	CMIP:GetListError	7	getListError_er
14005	CMIP:Invalid Argument Value	15	invalidArgumentValue_er
14006	CMIP:Invalid Attribute Value	6	invalidAttributeValue_er
14007	CMIP:Invalid Filter	4	invalidFilter
14008	CMIP:Invalid Scope	16	invalidScope
14009	CMIP:No Such Action	9	noSuchAction_er
14010	CMIP:No Such Argument	14	noSuchArgument_er
14011	CMIP:No Such Attribute	5	noSuchAttribute_er
14012	CMIP:No Such Object Class	0	noSuchObjectClass
14013	CMIP:No Such Object Instance	1	noSuchObjectInstance
14014	CMIP:Resource Limitation	6	invalidAttributeValue_er
14015	CMIP:Synch Not Supported	3	syncNotSupported
14016	CMIP process restarted	10	processingFailure_er
14017	CMIP:Sap Create failure	10	processingFailure_er
14018	CMIP:Processing failure	10	processingFailure_er
14019	CMIP:Bind Error	10	processingFailure_er
14020	CMIP:Received Unexpected Message	10	processingFailure_er
14021	CMIP:Retrieve Attribute Failed	10	processingFailure_er
14022	CMIP:Invalid Data Type	10	processingFailure_er
14023	CMIP:Invalid Message Type	10	processingFailure_er
14024	CMIP:Invalid Attribute	5	noSuchAttribute_er
14025	CMIP:No Existing Event	13	noSuchEventType
14026	CMIP:SetListError	8	setListError_er
14027	CMIP:DeleteListError	10	processingFailure_er
14028	CMIP:Invalid Error Mapping	10	processingFailure_er
14029	CMIP:Invalid Object Instance	17	invalidObjectInstance
14030	CMIP:Missing Attribute Value	18	missingAttributeValue
14031	CMIP:Mistyped Operation	21	mistypedOperation
14032	CMIP:No Such Reference Object	12	noSuchReferenceObject
14033	CMIP:Operation Canceled	23	operationCancelled
14034	CMIP:No Such Invoke ID	22	noSuchInvokeId
14035	NPAC:Sending Abort	2	accessDenied_er
14036	NPAC:Received Abort	23	operationCancelled

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		28

Appendix B: Message Flow Diagrams

Appendix B. Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		29

Appendix B: Message Flow Diagrams

B.2 Audit Scenarios

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		30

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		31

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		32

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		33

Appendix B: Message Flow Diagrams

B.2.2 SOA Initiated Audit Cancellation by the SOA

The SOA cancels an audit that it initiated.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		34

Appendix B: Message Flow Diagrams

B.2.3 SOA Initiated Audit Cancellation by the NPAC

The NPAC cancels an audit that was initiated by an SOA.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		35

Appendix B: Message Flow Diagrams

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

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:

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		36

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		37

Appendix B: Message Flow Diagrams

B.2.5 NPAC Initiated Audit Cancellation by the NPAC

The NPAC SMS cancels an audit that it initiated.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		38

Appendix B: Message Flow Diagrams

B.2.6 Audit Query on the NPAC

This scenario shows a service provider query on an existing audit that it initiated.

     

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		39

Appendix B: Message Flow Diagrams

B.2.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.2.7.1 SOA Creates and NPAC SMS Starts Audit (previously NNP flow 6.1.1)

     

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:

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		40

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		41

Appendix B: Message Flow Diagrams

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)

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.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		42

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		43

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		44

Appendix B: Message Flow Diagrams

B.2.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.2.8.1 NPAC SMS Creates and Starts Audit (previously NNP flow 6.2.1)

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:

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		45

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		46

Appendix B: Message Flow Diagrams

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

NPAC SMS performs object comparisons.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		47

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		48

Appendix B: Message Flow Diagrams

B.3 Service Provider Scenarios

B.3.1 Service Provider Creation by the NPAC

In this scenario, the NPAC SMS creates data for a new LNP service provider. The addition of NPA-NXX and LRN data for a new service provider will be shown in flows that follow.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		49

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		50

Appendix B: Message Flow Diagrams

B.3.2 Service Provider Deletion by the NPAC

In this scenario, the NPAC SMS deletes data for an LNP service provider with no network data.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		51

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		54

Appendix B: Message Flow Diagrams

B.3.3 Service Provider Modification by the NPAC

In this scenario, the NPAC SMS modifies the LNP service provider data.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		53

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		54

Appendix B: Message Flow Diagrams

B.3.4 Service Provider Modification by the Local SMS

In this scenario, the Local SMS modifies its own service provider data.

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		55

Appendix B: Message Flow Diagrams

B.3.5 Service Provider Modification by the SOA

In this scenario, the SOA modifies its own service provider data.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		56

Appendix B: Message Flow Diagrams

B.3.6 Service Provider Query by the Local SMS

In this scenario, the Local SMS queries their own service provider data.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		57

Appendix B: Message Flow Diagrams

B.3.7 Service Provider Query by the SOA

In this scenario, the SOA queries their own service provider data.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		58

Appendix B: Message Flow Diagrams

B.4 Service Provider Network Data Scenarios

B.4.1 NPA-NXX Scenarios

B.4.1.1 NPA-NXX Creation by the NPAC

In this scenario, NPAC SMS creates new NPA-NXX data for an LNP service provider.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		59

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		60

Appendix B: Message Flow Diagrams

B.4.1.2 NPA-NXX Deletion by the NPAC

In this scenario, NPAC SMS deletes an NPA-NXX for an LNP service provider.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		61

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		62

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		63

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		64

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		65

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		66

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		67

Appendix B: Message Flow Diagrams

	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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		68

Appendix B: Message Flow Diagrams

B.4.1.6 NPA-NXX Deletion by SOA

In this scenario, the SOA deletes a new NPA-NXX for its own service provider network data.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		69

Appendix B: Message Flow Diagrams

	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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		70

Appendix B: Message Flow Diagrams

B.4.1.7 NPA-NXX Query by the Local SMS

In this scenario, the Local SMS queries for NPA-NXX data.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		71

Appendix B: Message Flow Diagrams

B.4.1.8 NPA-NXX Query by the SOA

In this scenario, the SOA queries for NPA-NXX updates.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		72

Appendix B: Message Flow Diagrams

B.4.2 LRN Scenarios

B.4.2.1 LRN Creation by the NPAC

In this scenario, the NPAC SMS creates an LRN.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		73

Appendix B: Message Flow Diagrams

6. The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		74

Appendix B: Message Flow Diagrams

B.4.2.2 LRN Creation by the SOA

In this scenario, the SOA creates an LRN for its own service provider network data.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		75

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		76

Appendix B: Message Flow Diagrams

B.4.2.3 LRN Deletion by the SOA

In this scenario, the SOA deletes an LRN for their own service provider network data.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		77

Appendix B: Message Flow Diagrams

	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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		78

Appendix B: Message Flow Diagrams

B.4.2.4 LRN Query by the SOA

In this scenario, the SOA queries LRN data.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		79

Appendix B: Message Flow Diagrams

B.4.2.5 LRN Deletion by the NPAC

In this scenario, the NPAC SMS deletes an LRN.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		80

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		81

Appendix B: Message Flow Diagrams

B.4.2.6 LRN Creation by the Local SMS

In this scenario, the Local SMS creates an LRN for its own service provider network data.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		82

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		83

Appendix B: Message Flow Diagrams

B.4.2.7 LRN Deletion by the Local SMS

In this scenario, the Local SMS deletes an LRN for their own service provider network data.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		84

Appendix B: Message Flow Diagrams

	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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		85

Appendix B: Message Flow Diagrams

B.4.2.8 LRN Query by the Local SMS

In this scenario, the Local SMS queries LRN data.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		86

Appendix B: Message Flow Diagrams

B.4.2.9 Network Data Download

DELETED. This scenario is superceded by the text and flows in section B.7, Local SMS and SOA Recovery.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		87

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		88

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		89

Appendix B: Message Flow Diagrams

B.4.3 Service Provider NPA-NXX-X

This section contains the flows that demonstrate service provider NPA-NXX-X creation, modification, deletion and query.

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		90

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		91

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		92

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		93

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		94

Appendix B: Message Flow Diagrams

6. The SOA responds by sending the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was deleted successfully.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		95

Appendix B: Message Flow Diagrams

B.4.3.4 Service Provider NPA-NXX-X Query by SOA or LSMS (previously NNP flow1.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.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		96

Appendix B: Message Flow Diagrams

B.4.4 Number Pool Block

This section contains the flows that demonstrate number pool block creation, modification and deletion.

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

Action is taken by the block holder service provider SOA to create a number pool block.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		97

Appendix B: Message Flow Diagrams

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 Based on the Optional Data parameter settings in the service provider’s profile on the NPAC SMS, the following attributes Optional Data parameters listed in the Optional Data XML 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’.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		98

Appendix B: Message Flow Diagrams

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

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 Based on the Optional Data parameter settings in the service provider’s profile on the NPAC SMS, the following attributes Optional Data parameters listed in the Optional Data XML may optionally be included:
	alternativeSPID
8.	The block holder SOA confirms the M-EVENT-REPORT.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		99

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		100

Appendix B: Message Flow Diagrams

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 Based on the Optional Data parameter settings in the service provider’s profile on the NPAC SMS, the following attributes Optional Data parameters listed in the Optional Data XML 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.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		101

Appendix B: Message Flow Diagrams

5.	NPAC SMS responds to the M-CREATE.
6.	NPAC SMS responds to the M-ACTION.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		102

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		103

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		104

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		105

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		106

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		107

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 20079 NeuStar, Inc.		108

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		109

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		110

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		111

Appendix B: Message Flow Diagrams

B.4.4.7 Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates (previously NNP flow2.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.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		112

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		113

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		114

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 20079 NeuStar, Inc.		115

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		116

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		117

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		118

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		119

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		120

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		121

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		122

Appendix B: Message Flow Diagrams

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 Based on the Optional Data parameter settings in the service provider’s profile on the NPAC SMS, the following attributes Optional Data parameters listed in the Optional Data XML may be updated:

alternative SPID

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		123

Appendix B: Message Flow Diagrams

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 Optional Data parameters listed in the Optional Data XML will be sent if they are updated and the “SOA Supports Alternative SPID” is set based on the Optional Data parameter settings in the service provider’s profile:

numberPoolBlockAlternativeSPID

6. Block holder SOA confirms the M-EVENT-REPORT.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		124

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		125

Appendix B: Message Flow Diagrams

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 Based on the Optional Data parameter settings in the service provider’s profile on the NPAC SMS, the following attributes Optional Data parameters listed in the Optional Data XML 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
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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		126

Appendix B: Message Flow Diagrams

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 Optional Data parameters listed in the Optional Data XML will be sent if they are updated and the “SOA Supports Alternative SPID” is set in based on the Optional Data parameter settings the service provider’s profile:

numberPoolBlockAlternativeSPID

6. Block holder SOA confirms the M-EVENT-REPORT.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		127

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		128

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		129

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		130

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		131

Appendix B: Message Flow Diagrams

1. NPAC SMS sends the M-SET with the modifications for the subscriptionVersion to the non-EDR Local SMS.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		132

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		133

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		134

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		135

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		136

Appendix B: Message Flow Diagrams

B.4.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’.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		137

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		138

Appendix B: Message Flow Diagrams

B.4.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’.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		139

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		140

Appendix B: Message Flow Diagrams

B.4.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’.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		141

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		142

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		143

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		144

Appendix B: Message Flow Diagrams

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)

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		145

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3:ã1997 — 20079 NeuStar, Inc.		146

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		147

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		148

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		149

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		150

Appendix B: Message Flow Diagrams

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		151

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		152

Appendix B: Message Flow Diagrams

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)

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.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		153

Appendix B: Message Flow Diagrams

B.4.4.28 Number Pool Block De-Pool Broadcast Partial Failure NPAC SMS Updates (previously NNP flow2.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.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		154

Appendix B: Message Flow Diagrams

	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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		155

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		156

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		157

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		158

Appendix B: Message Flow Diagrams

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		160

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		160

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 20079 NeuStar, Inc.		161

Appendix B: Message Flow Diagrams

6. SOA confirms M-EVENT-REPORT.

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		162

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		163

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		164

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		165

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		166

Appendix B: Message Flow Diagrams

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

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

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		167

Appendix B: Message Flow Diagrams

subscriptionOldSPMediumTimerIndicator — if support 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.
	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)

subscriptionVersionStatus

subscriptionVersionConflictTimeStamp — (if subscriptionOldSP-Authorization set to false)

subscriptionTimerType — if supported by the Service Provider SOA

subscriptionBusinessType — if supported by the Service Provider SOA

subscriptionOldSPMediumTimerIndicator — if support by the Service Provider SOA

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.

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		168

Appendix B: Message Flow Diagrams

B.5.1.1.1 Subscription Version Create by the Initial SOA (Old Service Provider) (continued)

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

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		169

Appendix B: Message Flow Diagrams

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

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

February 28 December 8, 20079,	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		170

Appendix B: Message Flow Diagrams

subscriptionPortingToOriginal-SP Switch

subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

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 when PortingToOrignal-SP is false:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

subscriptionAlternativeSPID Optional Data parameters defined in the Optional Data

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

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.

The following attributes are optional when PortingToOrignal-SP is true:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

	If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. 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 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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		171

Appendix B: Message Flow Diagrams

subscriptionTimerType — if supported by the Service Provider SOA

subscriptionBusinessType — if supported by the Service Provider SOA

subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		172

Appendix B: Message Flow Diagrams

B.5.1.2.1 Subscription Version Create by the Initial SOA (New Service Provider) (continued)

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		173

Appendix B: Message Flow Diagrams

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

New service provider SOA personnel take action to create a new subscription version.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		174

Appendix B: Message Flow Diagrams

subscriptionPortingToOriginal-SP Switch

subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

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 when PortingToOriginal-SP is false:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

subscriptionAlternativeSPID Optional Data parameters defined in the Optional Data

XML — if supported by the Service

If a TN range is specified in the request, it would result in an M-SET request and M-EVENT-REPORT for each TN.

If the new service provider is not the new service provider specified in the initial create by the old service provider, an accessDenied error will be returned.

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

The following attributes are optional when PortingToOrignal-SP is true:

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

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.

1.	If successful, the NPAC SMS sets the subscriptionModifiedTimeStamp, subscriptionCreationTimeStamp, and all data specified in the M-ACTION.
2.	NPAC SMS responds to M-SET.
3.	NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.
4.	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 with the following attributes to the old service provider when the subscriptionNewSP-DueDate changes value.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		175

Appendix B: Message Flow Diagrams

subscriptionNewSP-DueDate

subscriptionNewSP-CreationTimeStamp

subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

5. Old service provider SOA issues M-EVENT-REPORT confirmation.

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

subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

7. New service provider SOA issues M-EVENT-REPORT confirmation.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		176

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		177

Appendix B: Message Flow Diagrams

subscriptionOldSP-DueDate (seconds set to zeros)

subscriptionLNPType

subscriptionOldSPMediumTimerIndicator — 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 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

subscriptionTimerType — if supported by the Service Provider SOA and the value changed as a result of the OldSP-Create Action

subscriptionBusinessType — if supported by the Service Provider SOA and the value changed as a result of the OldSP-Create Action

subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA

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

subscriptionTimerType — if supported by the Service Provider SOA and the value changed as a result of the OldSP-Create Action

subscriptionBusinessType — if supported by the Service Provider SOA and the value changed as a result of the OldSP-Create Action

subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA

8. New service provider issues M-EVENT-REPORT confirmation.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		178

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		179

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		180

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		181

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		182

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		183

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		184

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

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.

3. NPAC SMS sends the new service provider, if they support the notification according to their NPAC Customer SOA Supports New SP Notification of Old SP T2 Expiration Indicator in their service provider profile on the NPAC SMS, of the expiration of the final concurrence window where the old 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 subscriptionVersionOldSPFinalConcurrenceWindowExpiration or subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration M-EVENT-REPORT.

4. The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		185

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		186

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		187

Appendix B: Message Flow Diagrams

B.5.1.7 SubscriptionVersionCreate M-CREATE Failure to Local SMS

This scenario shows a failure to all of the Local SMS on M-CREATE.

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		188

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3: ã 1997 — 20079 NeuStar, Inc.		189

Appendix B: Message Flow Diagrams

B.5.1.8 SubscriptionVersion M-CREATE: Partial Failure to Local SMS

This scenario shows a partial failure to a Local SMS on an M-CREATE.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		190

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã1997 — 20079 NeuStar, Inc.		191

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		192

Appendix B: Message Flow Diagrams

	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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		193

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		194

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		195

Appendix B: Message Flow Diagrams

B.5.1.11 SubscriptionVersion Create for Intra-Service Provider Port

This scenario shows how an intra-service port is processed.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		196

Appendix B: Message Flow Diagrams

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

The following attributes are optional when PortingToOriginal-SP is false:

subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscrptionAlternativeSPIDOptional Data parameters defined in the Optional Data

XML — 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 when PortingToOriginal-SP is true:

subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId

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. The request will be accepted, and any of the following attributes will be ignored:

subscriptionNewSPMediumTimerIndicator
subscriptionOldSPMediumTimerIndicator

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		197

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		198

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		199

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		200

Appendix B: Message Flow Diagrams

B.5.1.12.1 Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		201

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		202

Appendix B: Message Flow Diagrams

B.5.1.12.2 Intra-Service Provider Subscription Version Port-to-Original: Successful (continued)

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		203

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		204

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		205

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		206

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		207

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		208

\

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		209

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		210

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		211

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		212

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		213

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		214

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		215

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		216

Appendix B: Message Flow Diagrams

B.5.1.15  SubscriptionVersion Port-to-Original: Resend

This scenario shows how a port-to-original (resend) port is processed.

	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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		217

Appendix B: Message Flow Diagrams

Each previously failed Local SMS responds with a successful M-DELETE reply.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		218

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		219

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		220

Appendix B: Message Flow Diagrams

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

	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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		221

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		222

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		223

Appendix B: Message Flow Diagrams

	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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		224

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		225

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		226

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		227

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		228

Appendix B: Message Flow Diagrams

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)

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		229

Appendix B: Message Flow Diagrams

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		230

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		231

Appendix B: Message Flow Diagrams

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)

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.

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		232

Appendix B: Message Flow Diagrams

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)

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		233

Appendix B: Message Flow Diagrams

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		234

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		235

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		236

Appendix B: Message Flow Diagrams

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)

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		237

Appendix B: Message Flow Diagrams

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		238

Appendix B: Message Flow Diagrams

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.

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		239

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		240

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		241

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		242

Appendix B: Message Flow Diagrams

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)

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		243

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		244

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		245

Appendix B: Message Flow Diagrams

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)

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		246

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		247

Appendix B: Message Flow Diagrams

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.
12.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		248

Appendix B: Message Flow Diagrams

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)

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		249

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		250

Appendix B: Message Flow Diagrams

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.
12.	The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		251

Appendix B: Message Flow Diagrams

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)

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.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		252

Appendix B: Message Flow Diagrams

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

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.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		253

Appendix B: Message Flow Diagrams

B.5.2	Modify Scenarios
B.5.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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		254

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		255

Appendix B: Message Flow Diagrams

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

subscriptionAlternativeSPIDOptional Data parameters defined in the Optional Data XML — 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).
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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		256

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		257

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		258

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		259

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		260

Appendix B: Message Flow Diagrams

The old service provider can only update the following attributes:

subscriptionOldSP-DueDate (seconds set to zeros)

subscriptionOldSP-Authorization

subscriptionStatusChangeCauseCode

subscriptionOldSPMediumTimerIndicator — if supported by the Old Service Prov SOA

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

subscriptionSVType — if supported by the Service Provider SOA

subscriptionEndUserLocationValue

subscriptionEndUserLocationType

subscriptionBillingId

subscriptionAlternativeSPIDOptional Data parameters defined in the Optional Data
XML — if supported by the Service Provider SOA AND only when the PortingToOriginal-SP is set to false
subscriptionNewSPMediumTimerIndicator — if supported by the New Service Provider SOA

	Note: subscriptionAlternativeSPIDOptional Data parameters defined in the Optional Data XML cannot be specified when the PortingToOriginal-SP is set to true.
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.
	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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		261

Appendix B: Message Flow Diagrams

• subscriptionNewSP-CreationTimeStamp

• subscriptionOldSP-Authorization

• subscriptionOldSP-AuthorizationTimeStamp

• subscriptionStatusChangeCauseCode

• subscriptionTimerType — if supported by the Service Provider SOA

• subscriptionBusinessType — if supported by the Service Provider SOA

• subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA

• subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

	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

• subscriptionTimerType — if supported by the Service Provider SOA

• subscriptionBusinessType — if supported by the Service Provider SOA

• subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA

• subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		262

Appendix B: Message Flow Diagrams

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

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

subscriptionOldSPMediumTimerIndicator — if supported by the Old Service Provider SOA

NOTE: The subscriptionStatusChangeCauseCode can only be modified when the subscriptionOldSP-Authorization is set to FALSE

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		263

Appendix B: Message Flow Diagrams

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
subscriptionSVType — if supported by the Service Provider SOA
subscriptionEndUserLocationValue
subscriptionEndUserLocationType
subscriptionBillingId
subscriptionAlternativeSPID Optional Data parameters defined in the Optional Data XML — if supported by the Service Provider SOA AND only when the PortingToOriginal-SP is set to false
subscriptionNewSPMediumTimerIndicator — if supported by the New Service Provider SOA

Note: subscriptionAlternativeSPID Optional Data parameters defined in the Optional Data XML cannot be specified when the PortingToOriginal-SP is set to true.

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
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 •     subscriptionTimerType — if supported by the Service Provider SOA •     subscriptionBusinessType — if supported by the Service Provider SOA •     subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA •     subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA
	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		264

Appendix B: Message Flow Diagrams

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 •     subscriptionTimerType — if supported by the Service Provider SOA •     subscriptionBusinessType — if supported by the Service Provider SOA •     subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA •     subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA
	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		265

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		266

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		267

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		268

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		269

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		270

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		271

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		272

Appendix B: Message Flow Diagrams

B.5.3     Cancel Scenarios

A subscription version can be canceled when the current status is conflict, pending or disconnect pending.

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

	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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		273

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		274

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		275

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		276

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		277

Appendix B: Message Flow Diagrams

     NPAC SMS is waiting for the cancellation acknowledgments from both service provider SOAs.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		278

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		279

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		280

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		281

Appendix B: Message Flow Diagrams

B.5.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”.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		282

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		283

Appendix B: Message Flow Diagrams

B.5.3.5     Un-Do Cancel-Pending Subscription Version Request

This scenario can only be performed when the subscription VersionStatus is cancel-pending.

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 or conflict (i.e. returned to the last status as prior to the cancellation that caused the subscription version to go to a cancel-pending status).

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		284

Appendix B: Message Flow Diagrams

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 or conflict (i.e. returned to the last status as prior to the cancellation that caused the subscription version to go to a cancel-pending status).
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 or conflict (i.e. returned to the last status as prior to the cancellation that caused the subscription version to go to a cancel-pending status).
8.	The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		285

Appendix B: Message Flow Diagrams

B.5.4 Disconnect Scenarios

B.5.4.1 SubscriptionVersion Immediate Disconnect

The current service provider can disconnect an active subscription version. In this scenario, the disconnect is immediate.

NOTE: The “Donor SOA” is the SOA of the donor service provider.

NOTE: The “donor service provider” is the NPA-NXX Holder, or in cases of a TN within a Number Pool Block, it is the NPA-NXX-X Holder.

     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 subscriptionVersionNPAC according to the disconnect action. The subscription version status is set to sending. The subscriptionCustomerDisconnectDate, subscriptionEffectiveReleaseDate and subscriptionModifiedTimeStamp are set.
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 subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange notification to the current service provider SOA setting the subscriptionVersionStatus equal to disconnect-pending.
6.	The current service provider SOA confirms the M-EVENT-REPORT.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		286

Appendix B: Message Flow Diagrams

B.5.4.1.1 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 an M-EVENT-REPORT subscirptionVersionDonorSP-CustomerDisconnectDate to the Donor SOA indicating the TN is being disconnected.
4.	Donor SOA issues an M-EVENT-REPORT confirmation to the NPAC SMS.
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 current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange an M-EVENT-REPORT for the subscriptionVersionStatus equal to “old” to the current service provider SOA.
8.	The current 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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		287

Appendix B: Message Flow Diagrams

B.5.4.2 SubscriptionVersion Disconnect With Effective Release Date

In this scenario, a future dated request is submitted to disconnect an active subscriptionVersion.

	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 issues an M-SET to set the subscriptionVersionNPAC according to the disconnect action. The subscription version status is set to sending. 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 setting the subscriptionVersionStatus equal to disconnect-pending.
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 the SubscriptionVersion Immediate Disconnect (continued) scenario (B.5.4.1.1). The NPAC SMS proceeds to issue M-DELETEs for the subscriptionVersion to the Local SMS and then the donor service provider’s SOA is notified of the impending disconnect.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		288

Appendix B: Message Flow Diagrams

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

	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 subscription Version. NPAC SMS waits for a response from each Local SMS.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		289

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		290

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		291

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		292

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		293

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		294

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		295

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		296

Appendix B: Message Flow Diagrams

B.5.4.7 Disconnect Subscription Version Scenarios for TNs that are part of a Number Pool Block

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		297

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		298

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		299

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		300

Appendix B: Message Flow Diagrams

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)

In this scenario, a future dated request is submitted to disconnect an active subscription version that will return to the block holder.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		301

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		302

Appendix B: Message Flow Diagrams

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)

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.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		303

Appendix B: Message Flow Diagrams

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

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3 ã 1997 — 20079 NeuStar, Inc.		304

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		305

Appendix B: Message Flow Diagrams

B.5.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’.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		306

Appendix B: Message Flow Diagrams

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)

NPAC SMS is attempting to disconnect a subscription version whose TN is a part of a number pool block.

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		307

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		308

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		309

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		310

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		311

Appendix B: Message Flow Diagrams

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

1. NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		312

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		313

Appendix B: Message Flow Diagrams

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

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		314

Appendix B: Message Flow Diagrams

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)

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		315

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		316

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		317

Appendix B: Message Flow Diagrams

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)

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.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		318

Appendix B: Message Flow Diagrams

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)

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.

Current service provider SOA personnel take action to disconnect a subscription version.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		319

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		320

Appendix B: Message Flow Diagrams

B.5.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.5.5.1 SubscriptionVersion Conflict by the NPAC SMS

This scenario shows a version being placed into conflict by the NPAC personnel.

     NPAC personnel or NPAC SMS take action to set the status of a subscription to “conflict.”

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		321

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		322

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		323

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		329

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		325

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		326

Appendix B: Message Flow Diagrams

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

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		327

Appendix B: Message Flow Diagrams

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		328

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		329

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		330

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		331

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		332

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		333

Appendix B: Message Flow Diagrams

	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		334

Appendix B: Message Flow Diagrams

B.5.6 SubscriptionVersion Query

This scenario shows subscriptionVersion query from service provider systems to the NPAC SMS.

	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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		335

Appendix B: Message Flow Diagrams

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)

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

subscriptionAlternativeSPIDOptional Data parameters defined in the Optional Data

XML — if supported by the Service Provider

subscriptionNewSPMediumTimerIndicator — if supported by the Service Provider SOA (not returned for query by Service Provider LSMS)

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		336

Appendix B: Message Flow Diagrams

subscriptionOldSPMediumTimerIndicator — if supported by the Service Provider SOA (not returned for query by Service Provider LSMS)

Note: If the New SP Medium Timer Indicator value or Old SP Medium Timer Indicator value is not set on the Subscription Version, then it will not be returned in the query response.

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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		337

Appendix B: Message Flow Diagrams

B.5.6.1 Subscription Data Download

DELETED. This scenario is superceded by the text and flows in section B.7, Local SMS and SOA Recovery.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		338

Appendix B: Message Flow Diagrams

B.6	LSMS Filter NPA-NXX Scenarios
B.6.1	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.

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		339

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		340

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		341

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		342

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		343

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		344

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		345

Appendix B: Message Flow Diagrams

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

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		348

Appendix B: Message Flow Diagrams

February 28December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		347

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		348

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		349

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		350

Appendix B: Message Flow Diagrams

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		351

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		352

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		353

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		354

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		355

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		356

Appendix B: Message Flow Diagrams

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		357

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		358

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 - 20079 NeuStar, Inc.		359

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		360

Appendix B: Message Flow Diagrams

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		361

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		362

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		365

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		364

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		365

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		366

Appendix B: Message Flow Diagrams

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.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		367

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		368

Appendix B: Message Flow Diagrams

SOA takes action to resynchronize their SOA with the NPAC SMS.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		369

Appendix B: Message Flow Diagrams

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

February 28 December 8 , 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã1997 — 20079 NeuStar, Inc.		370

Appendix B: Message Flow Diagrams

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.

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		371

Appendix B: Message Flow Diagrams

B.8 Miscellaneous

B.8.1 SOA/Local SMS Notification of Scheduled NPAC Downtime

This scenario shows 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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		372

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		373

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		374

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		375

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		376

Appendix B: Message Flow Diagrams

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

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		377

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		378

Appendix B: Message Flow Diagrams

B.8.3 Mass Update

NPAC SMS personnel can perform a mass update on subscription data.

	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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		379

Appendix B: Message Flow Diagrams

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

Action is taken by NPAC SMS personnel to perform a mass update.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		380

Appendix B: Message Flow Diagrams

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		381

Appendix B: Message Flow Diagrams

B.8.4 Application Level Heartbeat Requests

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		382

Appendix B: Message Flow Diagrams

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

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.

February 28 December 8, 20079	NANC Version 3.3.34a		NPAC SMS Interoperable Interface Specification
Release 3.3ã 1997 — 20079 NeuStar, Inc.		383