NEUSTAR INC
Risks Related to Our Business           Failures or interruptions of our clearinghouse could     materially harm our revenue and impair our ability to conduct     our operations.         We provide addressing, interoperability and infrastructure services that are critical to the operations of our customers. Notably, our clearinghouse is essential to the orderly operation of the national telecommunications system because it enables CSPs to ensure that telephone calls are routed to the appropriate destinations. Our system architecture is integral to our ability to process a high volume of transactions in a timely and effective manner. We could experience failures or interruptions of our systems and services, or other problems in connection with our operations, as a result of:            •       damage to, or failure of, our computer software or hardware or     our connections and outsourced service arrangements with third     parties;         •       errors in the processing of data by our system;         •       computer viruses or software defects;         •       physical or electronic break-ins, sabotage, intentional acts of     vandalism and similar events;         •       increased capacity demands or changes in systems requirements of     our customers; or         •       errors by our employees or third-party service providers.         If we cannot adequately protect the ability of our clearinghouse to perform consistently at a high level or otherwise fail to meet our customers’ expectations:            •       we may experience damage to our reputation, which may adversely     affect our ability to attract or retain customers for our     existing services, and may also make it more difficult for us to     market our services;         •       we may be subject to significant damages claims, under our     contracts or otherwise, including the requirement to pay     substantial penalties related to service level requirements in     our contracts;         •       our operating expenses or capital expenditures may increase as a     result of corrective efforts that we must perform;         •       our customers may postpone or cancel subsequently scheduled work     or reduce their use of our services; or         •       one or more of our significant contracts may be terminated     early, or may not be renewed.         Any of these consequences would adversely affect our revenue and performance.           Security breaches could result in an interruption of     service or reduced quality of service, which could increase our     costs or result in a reduction in the use of our services by our     customers.         Our systems may be vulnerable to physical break-ins, computer viruses, attacks by computer hackers or similar disruptive problems. If unauthorized users gain access to our databases, they may be able to steal, publish, delete or modify sensitive information that is stored or transmitted on our networks and that we are required by our contracts and FCC rules to keep confidential. A security or privacy breach could result in an interruption of service or reduced quality of service and we may be required to make significant expenditures in connection with corrective efforts we are required to perform. In addition, a security or privacy breach may  15       harm our reputation and cause our customers to reduce their use of our services, which could harm our revenue and business prospects.           The loss of, or damage to, a data center could interrupt     our operations and materially harm our revenue and     growth.         Because telecommunications service providers must query a copy of our continuously updated databases to route virtually every telephone call in North America, the integrity of our data centers is essential to our business. We may not have sufficient redundant systems or back-up facilities to allow us to receive and process data in the event of a loss of, or damage to, a data center. We could lose, or suffer damage to, a data center in the event of power loss; natural disasters such as fires, earthquakes, floods and tornadoes; telecommunications failures, such as transmission cable cuts; or other similar events that could adversely affect our customers’ ability to access our clearinghouse. We may be required to make significant expenditures to repair or replace a data center. Any interruption to our operations due to the loss of, or damage to, a data center could harm our reputation and cause our customers to reduce their use of our services, which could harm our revenue and business prospects.           The failure of the third-party software and equipment used     by our customers or that we use in our clearinghouse could cause     interruptions or failures of our systems.         We incorporate hardware, software and equipment developed by third parties in our clearinghouse. Our third-party vendors include, among others, IBM, and Oracle Corporation for database systems and software, and EMC Corporation and Sun Microsystems, Inc. for equipment. Similarly, to access our clearinghouse and utilize our services, many of our customers rely on hardware, software and other equipment developed, supported and maintained by third-party providers. As a result, our ability to provide clearinghouse services depends in part on the continued performance and support of the third-party products on which we and our customers rely. If these products experience failures or have defects and the third parties that supply the products fail to provide adequate support, this could result in or exacerbate an interruption or failure of our systems or services.           Our seven contracts with North American Portability     Management LLC represent in the aggregate a substantial portion     of our revenue, are not exclusive and could be terminated or     modified in ways unfavorable to us, and we may be unable to     renew these contracts at the end of their term.         Our seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States, to provide telephone number portability and other clearinghouse services are not exclusive and could be terminated or modified in ways unfavorable to us. These seven separate contracts, each of which represented between 8.5% and 14.8% of our total revenue in 2005, represented in the aggregate approximately 77.9% of our total revenue in 2005. North American Portability Management LLC could, at any time, solicit or receive proposals from other providers to provide services that are the same as or similar to ours. In addition, these contracts have finite terms and are currently scheduled to expire in May 2011. Furthermore, any of these contracts could be terminated in advance of its scheduled expiration date in limited circumstances, most notably if we are in default of these agreements. Although these contracts do not contain cross-default provisions, conditions leading to a default by us under one of our contracts could lead to a default under others, or all seven.        We may be unable to renew these contracts on acceptable terms when they are being considered for renewal if we fail to meet our customers’ expectations, including for performance and other reasons, or if another provider offers to provide the same or similar services at a lower cost. In addition, competitive forces resulting from the possible entrance of a competitive provider could create significant pricing pressure, which could then cause us to reduce the selling price of our services under our contracts. If these contracts are terminated or modified in a manner that is adverse to us, or if we are unable to renew these contracts on acceptable terms upon their expiration, it would have a material adverse effect on our business, prospects, financial condition and results of operations. See “Business — Contracts” in Item 1 of this report.  16               Our contracts with North American Portability Management     LLC contain provisions that may restrict our ability to use data     that we administer in our clearinghouse, which may limit our     ability to offer services that we currently, or intend to,     offer.         In addition to offering telephone number portability and other clearinghouse services under our contracts with North American Portability Management LLC, some of our service offerings not related to these contracts require that we use certain data from our clearinghouse. We have been informed by North American Portability Management LLC that they believe that use of this data, which is unrelated to our performance under these contracts, may not be permissible under the current agreements. If we are subject to burdensome terms of access or are not permitted to use this data, our ability to offer new services requiring the use of this data may be limited.           Certain of our other contracts may be terminated or we may     be unable to renew these contracts, which may reduce the number     of services we can offer and damage our reputation.         In addition to our contracts with North American Portability Management LLC, we rely on other contracts to provide some of the services that we offer, including the contracts that appoint us to serve as the:            •       North American Numbering Plan Administrator, under which we     maintain the authoritative database of telephone numbering     resources in North America;         •       National Pooling Administrator, under which we perform the     administrative functions associated with the administration and     management of telephone number inventory and allocation of     pooled blocks of unassigned telephone numbers;         •       provider of number portability services in Canada;         •       operator of the .us registry;         •       operator of the .biz registry; and         •       operator of the registry of U.S. Common Short Codes.         Each of these contracts provides for early termination in limited circumstances, most notably if we are in default. In addition, our contracts to serve as the North American Numbering Plan Administrator and as the National Pooling Administrator and to operate the .us registry, each of which is with the U.S. government, may be terminated by the government at will. If we fail to meet the expectations of the FCC, the U.S. Department of Commerce or our customers, as the case may be, for any reason, including for performance-related or other reasons, or if another provider offers to perform the same or similar services for a lower price, we may be unable to extend or renew these contracts. In that event, the number of services we are able to offer may be reduced, which would adversely affect our revenue from the provision of these services. Each of the contracts listed above establishes us as the sole provider of the particular services covered by that contract during its term. If one of these contracts were terminated, or if we were unable to renew or extend the term of any particular contract, we would no longer be able to provide the services covered by that contract and could suffer a loss of prestige that would make it more difficult for us to compete for contracts to provide similar services in the future.           Failure to comply with neutrality requirements could     result in loss of significant contracts.         Pursuant to orders and regulations of the U.S. government and provisions contained in our material contracts, we must continue to comply with certain neutrality requirements, meaning generally that we cannot favor any particular telecommunications service provider, telecommunications industry segment or technology or group of telecommunications consumers over any other telecommunications service provider, industry segment, technology or group of consumers in the conduct of our business. See “Business — Regulatory Environment — Telephone Numbering — Neutrality” in Item 1 of this report. The FCC oversees our compliance with the neutrality requirements applicable to us in connection with some of the services we provide. We provide to the FCC and the North American Numbering Council, a federal advisory committee established by the FCC to advise and make recommendations on telephone numbering issues, regular  17       certifications relating to our compliance with these requirements. Our ability to comply with the neutrality requirements to which we are subject may be affected by the activities of our stockholders or other parties. For example, if the ownership of our capital stock subjects us to undue influence by parties with a vested interest in the outcome of numbering administration, the FCC could determine that we are not in compliance with our neutrality obligations. Our failure to continue to comply with the neutrality requirements to which we are subject under applicable orders and regulations of the U.S. government and commercial contracts may result in fines, corrective measures or termination of our contracts, any one of which could have a material adverse effect on our results of operations.           Regulatory and statutory changes that affect us or the     communications industry in general may increase our costs or     impair our growth.         The FCC has regulatory authority over certain aspects of our operations, most notably our compliance with our neutrality requirements. We are also affected by business risks specific to the regulated communications industry. Moreover, the business of our customers is subject to regulation that indirectly affects our business. As communications technologies and the communications industry continue to evolve, the statutes governing the communications industry or the regulatory policies of the FCC may change. If this were to occur, the demand for our clearinghouse services could change in ways that we cannot easily predict and our revenue could decline. These risks include the ability of the federal government, most notably the FCC, to:            •       increase regulatory oversight over the services we provide;         •       adopt or modify statutes, regulations, policies, procedures or     programs that are disadvantageous to the services we provide, or     that are inconsistent with our current or future plans, or that     require modification of the terms of our existing contracts,     including the manner in which we charge for certain of our     services. For example, in November 2005, BellSouth Corporation     filed a petition with the FCC seeking changes in the way our     customers are billed for services provided by us under our     contracts with North American Portability Management LLC;         •       prohibit us from entering into new contracts or extending     existing contracts to provide services to the communications     industry based on actual or suspected violations of our     neutrality requirements, business performance concerns, or other     reasons;         •       adopt or modify statutes, regulations, policies, procedures or     programs in a way that could cause changes to our operations or     costs or the operations of our customers;         •       appoint, or cause others to appoint, substitute or add     additional parties to perform the services that we currently     provide; and         •       prohibit or restrict the provision or export of new or expanded     services under our contracts, or prevent the introduction of     other services not under the contracts based upon restrictions     within the contracts or in FCC policies.         In addition, we are subject to risks arising out of the delegation of the Department of Commerce’s responsibilities for the domain name system to the International Corporation for Assigned Names and Numbers, or ICANN. Changes in the regulations or statutes to which our customers are subject could cause our customers to alter or decrease the services they purchase from us. We cannot predict when, or upon what terms and conditions, further regulation or deregulation might occur or the effect future regulation or deregulation may have on our business.           If we do not adapt to rapid technological change in the     communications industry, we could lose customers or market     share.         Our industry is characterized by rapid technological change and frequent new service offerings. Significant technological changes could make our technology and services obsolete. We must adapt to our rapidly changing market by continually improving the features, functionality, reliability and responsiveness of our addressing, interoperability and infrastructure services, and by developing new features, services and  18       applications to meet changing customer needs. We cannot guarantee that we will be able to adapt to these challenges or respond successfully or in a cost-effective way. Our failure to do so would adversely affect our ability to compete and retain customers or market share. Although we currently provide our services primarily to traditional telecommunications companies, many existing and emerging companies are providing, or propose to provide, IP-based voice services. Our future revenue and profits will depend, in part, on our ability to provide services to IP-based service providers. For example, we are currently conducting trial tests of SIP-IX, a comprehensive suite of services designed to enable direct network-to-network peering between trading partners for voice, video and content services using Session Initiation Protocol (SIP)-based technologies such as IP multimedia subsystem (IMS) and Voice over Internet Protocol (VoIP). There can be no assurance that IP communications will grow in any meaningful fashion, or that SIP-IX will be adopted by potential customers, nor can we guarantee that we will be able to reach acceptable contract terms with customers to provide this service. In addition, we may experience delays in the development of one or more features of SIP-IX, which could materially reduce the potential benefits to us for providing this service.           The market for certain of our addressing,     interoperability, and infrastructure services is competitive,     which could result in fewer customer orders, reduced revenue or     margins or loss of market share.         Our services most frequently compete against the legacy in-house systems of our customers. In addition, although we are not a telecommunications service provider, we compete in some areas against communications service companies, communications software companies and system integrators that provide systems and services used by CSPs to manage their networks and internal operations in connection with telephone number portability and other telecommunications transactions. We face competition from large, well-funded providers of addressing, interoperability and infrastructure services. Moreover, we are aware of other companies that are focusing significant resources on developing and marketing services that will compete with us. We anticipate continued growth of competition. Some of our current and potential competitors have significantly more employees and greater financial, technical, marketing and other resources than we have. Our competitors may be able to respond more quickly to new or emerging technologies and changes in customer requirements than we can. Also, many of our current and potential competitors have greater name recognition that they can use to their advantage. Increased competition could result in fewer customer orders, reduced revenue, reduced gross margins and loss of market share, any of which could harm our business.           Our failure to achieve or sustain market acceptance at     desired pricing levels could impact our ability to maintain     profitability or positive cash flow.         Our competitors and customers may cause us to reduce the prices we charge for services. The primary sources of pricing pressure include:            •       competitors offering our customers services at reduced prices,     or bundling and pricing services in a manner that makes it     difficult for us to compete. For example, a competing provider     of interoperability services might offer its services at lower     rates than we do, or a competing domain name registry provider     may reduce its prices for domain name registration;         •       customers with a significant volume of transactions may have     enhanced leverage in pricing negotiations with us; and         •       if our prices are too high, potential customers may find it     economically advantageous to handle certain functions internally     instead of using us.         We may not be able to offset the effects of any price reductions by increasing the number of transactions we handle or the number of customers we serve, by generating higher revenue from enhanced services or by reducing our costs.  19               A decline in the volume of transactions we handle could     have a material adverse effect on our results of     operations.         We earn revenue for the vast majority of the services that we provide on a per transaction basis. There are no minimum revenue requirements in our contracts, which means that there is no limit to the potential adverse effect on our revenue from a decrease in our transaction volumes. As a result, if industry participants reduce their usage of our services from their current levels, our revenue and results of operations will suffer. For example, if customer churn between CSPs in the industry stabilizes or declines, or if CSPs do not compete vigorously to lure customers away from their competitors, use of our telephone number portability and other services may decline. In addition, if CSPs develop internal systems to address their infrastructure needs, or if the cost of such transactions makes it impractical for a given carrier to use our services for these purposes, we may experience a reduction in transaction volumes. Finally, the trends that we believe will drive the future demand for our clearinghouse services, such as the emergence of IP services, growth of wireless services, consolidation in the industry, and pressure on carriers to reduce costs, may not actually result in increased demand for our services, which would harm our future revenue and growth prospects.           If we are unable to manage our growth, our revenue and     profits could be adversely affected.         Sustaining our growth has placed significant demands on our management as well as on our administrative, operational and financial resources. For us to continue to manage our growth, we must continue to improve our operational, financial and management information systems and expand, motivate and manage our workforce. If we are unable to successfully manage our growth without compromising our quality of service and our profit margins, or if new systems that we implement to assist in managing our growth do not produce the expected benefits, our revenue and profits could be adversely affected.           We may be unable to complete suitable acquisitions, or we     may undertake acquisitions that could increase our costs or     liabilities or be disruptive to our business.         We have made a number of acquisitions in the past, and one of our strategies is to pursue acquisitions selectively in the future. We may not be able to locate suitable acquisition candidates at prices that we consider appropriate or to finance acquisitions on terms that are satisfactory to us. If we do identify an appropriate acquisition candidate, we may not be able to successfully negotiate the terms of an acquisition, finance the acquisition or, if the acquisition occurs, integrate the acquired business into our existing business. Acquisitions of businesses or other material operations may require additional debt or equity financing, resulting in additional leverage or dilution to our stockholders. Integration of acquired business operations could disrupt our business by diverting management away from day-to-day operations. The difficulties of integration may be increased by the necessity of coordinating geographically dispersed organizations, integrating personnel with disparate business backgrounds and combining different corporate cultures. We also may not realize cost efficiencies or synergies or other benefits that we anticipated when selecting our acquisition candidates. In addition, we may need to record write-downs from future impairments of intangible assets, which could reduce our future reported earnings. At times, acquisition candidates may have liabilities, neutrality-related risks or adverse operating issues that we fail to discover through due diligence prior to the acquisition. The failure to discover such issues prior to such acquisition could have a material adverse effect on our business and results of operations.           Our potential expansion into international markets may be     subject to uncertainties that could increase our costs to comply     with regulatory requirements in foreign jurisdictions, disrupt     our operations, and require increased focus from our     management.         We intend to pursue international business opportunities, which could involve the growth of our operations in foreign jurisdictions. International operations and business expansion plans are subject to numerous additional risks, including economic and political risks in foreign jurisdictions in which we operate or seek to operate, the difficulty of enforcing contracts and collecting receivables through some foreign legal systems, unexpected changes in regulatory requirements and the difficulties associated with managing a large organization spread throughout various countries. If we continue to expand our business globally, our success  20       will depend, in large part, on our ability to anticipate and effectively manage these and other risks associated with our international operations. However, any of these factors could adversely affect our international operations and, consequently, our operating results.           Our senior management is important to our customer     relationships, and the loss of one or more of our senior     managers could have a negative impact on our business.         We believe that our success depends in part on the continued contributions of our Chief Executive Officer, Jeffrey Ganek, and other members of our senior management. We rely on our executive officers and senior management to generate business and execute programs successfully. In addition, the relationships and reputation that members of our management team have established and maintain with our customers and our regulators contribute to our ability to maintain good customer relations. The loss of Jeffrey Ganek or any other member of senior management could impair our ability to identify and secure new contracts and otherwise to manage our business.           We must recruit and retain skilled employees to succeed in     our business, and our failure to recruit and retain qualified     employees could harm our ability to maintain and grow our     business.         We believe that an integral part of our success is our ability to recruit and retain employees who have advanced skills in the addressing, interoperability and infrastructure services that we provide and who work well with our customers in the regulated environment in which we operate. In particular, we must hire and retain employees with the technical expertise and industry knowledge necessary to maintain and continue to develop our operations and must effectively manage our growing sales and marketing organization to ensure the growth of our operations. Our future success depends on the ability of our sales and marketing organization to establish direct sales channels and to develop multiple distribution channels with Internet service providers and other third parties. The employees with the skills we require are in great demand and are likely to remain a limited resource in the foreseeable future. If we are unable to recruit and retain a sufficient number of these employees at all levels, our ability to maintain and grow our business could be negatively impacted.           We will continue to incur increased costs as a public     company as a result of recently enacted and proposed changes in     laws and regulations.         Recently enacted and proposed changes in the laws and regulations affecting public companies, including the provisions of the Sarbanes-Oxley Act of 2002 and rules of the Securities and Exchange Commission and the New York Stock Exchange, have resulted and will continue to result in increased costs to us, including those related to corporate governance and the costs to operate as a public company. Section 404 of the Sarbanes-Oxley Act of 2002 requires companies to perform a comprehensive and costly evaluation and obtain an audit of their internal controls. The new rules could also make it more difficult or more costly for us to maintain certain types of insurance, including directors’ and officers’ liability insurance. The impact of these events could make it more difficult for us to attract and retain qualified persons to serve on our board of directors, our board committees or as executive officers.           We may need additional capital in the future and it may     not be available on acceptable terms.         We have historically relied on outside financing and cash flow from operations to fund our operations, capital expenditures and expansion. However, we may require additional capital in the future to fund our operations, finance investments in equipment or infrastructure, or respond to competitive pressures or strategic opportunities. Additional financing may not be available on terms favorable to us, or at all. In addition, the terms of available financing may place limits on our financial and operating flexibility. If we are unable to obtain sufficient capital in the future, we may:            •       not be able to continue to meet customer demand for service     quality, availability and competitive pricing;         •       be forced to reduce our operations;   21                •       not be able to expand or acquire complementary     businesses; and         •       not be able to develop new services or otherwise respond to     changing business conditions or competitive pressures.    Risks Related to Our Common Stock           Our common stock price may be volatile.         The market price of our Class A common stock may fluctuate widely. Fluctuations in the market price of our Class A common stock could be caused by many things, including:            •       our perceived prospects and the prospects of the telephone and     Internet industries in general;         •       differences between our actual financial and operating results     and those expected by investors and analysts;         •       changes in analysts’ recommendations or projections;         •       changes in general valuations for communications companies;         •       adoption or modification of regulations, policies, procedures or     programs applicable to our business;         •       sales of our Class A common stock by our officers,     directors or principal stockholders;         •       sales of significant amounts of our Class A common stock in     the public market, or the perception that such sales may occur;         •       sales of our Class A common stock due to a required     divestiture under the terms of our certificate of     incorporation; and         •       changes in general economic or market conditions and broad     market fluctuations.         Each of these factors, among others, could have a material adverse effect on the market price of our Class A common stock. In addition, in recent years, the stock market in general and the shares of technology companies in particular have experienced extreme price fluctuations. This volatility has had a substantial effect on the market prices of securities issued by many companies for reasons unrelated to the operating performance of the specific companies. Some companies that have had volatile market prices for their securities have had securities class action suits filed against them. If a suit were to be filed against us, regardless of the outcome, it could result in substantial costs and a diversion of our management’s attention and resources. This could have a material adverse effect on our business, prospects, financial condition and results of operations.           One of our stockholders holds a significant block of     shares in our company and, as a result, may have significant     influence over our company.         Our board of directors includes one representative of Warburg Pincus. Pursuant to an agreement between us and certain holders of our Class A common stock, we anticipate that one representative of Warburg Pincus will continue to serve on our board of directors. In addition, as of December 31, 2005, affiliates of Warburg Pincus owned or controlled approximately 10.9% of the outstanding shares of our Class A common stock. A portion of the shares owned by these stockholders is held in a voting trust that controls the voting rights with respect to some actions that are subject to the approval of our stockholders under applicable law. However, under the terms of the trust agreement, these stockholders may hold up to 9.9% of the voting power of our outstanding shares of capital stock directly, and they have full voting power over such shares. In addition, they have the right to direct the voting trust as to how to vote their shares held in trust with respect to, among other things, any merger, sale or similar transaction involving NeuStar, the issuance of capital stock and the incurrence of substantial indebtedness. As a result of their ownership interest, these affiliates of Warburg Pincus may have the ability to significantly influence the outcome of a vote by our stockholders, and their interests could conflict with the interests of our other stockholders. Additionally, they and their affiliates are in the business of making investments in companies and may from time to time acquire and hold interests in  22       businesses that compete or could in the future compete, directly or indirectly, with us. For example, another Warburg Pincus fund has a significant investment in Telcordia Technologies, Inc., which has competed (and may compete in the future) with us. Warburg Pincus and its affiliates may also pursue acquisition opportunities that may be complementary to our business, and as a result, those acquisition opportunities may not be available to us.           Delaware law and provisions in our certificate of     incorporation and bylaws could make a merger, tender offer or     proxy contest difficult, and the market price of our     Class A common stock may be lower as a result.         We are a Delaware corporation, and the anti-takeover provisions of the Delaware General Corporation Law may discourage, delay or prevent a change in control by prohibiting us from engaging in a business combination with an interested stockholder for a period of three years after the person becomes an interested stockholder, even if a change of control would be beneficial to our existing stockholders. In addition, our certificate of incorporation and bylaws may discourage, delay or prevent a change in our management or control over us that stockholders may consider favorable. Our certificate of incorporation and bylaws:            •       authorize the issuance of “blank check” preferred     stock that could be issued by our board of directors to thwart a     takeover attempt;         •       prohibit cumulative voting in the election of directors, which     would otherwise enable holders of less than a majority of our     voting securities to elect some of our directors;         •       establish a classified board of directors, as a result of which     the successors to the directors whose terms have expired will be     elected to serve from the time of election and qualification     until the third annual meeting following election;         •       require that directors only be removed from office for cause;         •       provide that vacancies on the board of directors, including     newly-created directorships, may be filled only by a majority     vote of directors then in office;         •       disqualify any individual from serving on our board if such     individual’s service as a director would cause us to     violate our neutrality requirements;         •       limit who may call special meetings of stockholders;         •       prohibit stockholder action by written consent, requiring all     actions to be taken at a meeting of the stockholders; and         •       establish advance notice requirements for nominating candidates     for election to the board of directors or for proposing matters     that can be acted upon by stockholders at stockholder meetings.            In order to comply with our neutrality requirements, our     certificate of incorporation contains ownership and transfer     restrictions relating to telecommunications service providers     and their affiliates, which may inhibit potential acquisition     bids that our stockholders may consider favorable, and the     market price of our Class A common stock may be lower as a     result.         In order to comply with neutrality requirements imposed by the FCC in its orders and rules, no entity that qualifies as a “telecommunications service provider” or affiliate of a telecommunications service provider, as such terms are defined under the Communications Act of 1934 and FCC rules and orders, may beneficially own 5% or more of our capital stock. As a result, subject to limited exceptions, our certificate of incorporation prohibits any telecommunications service provider or affiliate of a telecommunications service provider from beneficially owning, directly or indirectly, 5% or more of our outstanding capital stock. Among other things, our certificate of incorporation provides that:            •       if one of our stockholders experiences a change in status or     other event that results in the stockholder violating this     restriction, or if any transfer of our stock occurs that, if     effective, would violate the 5% restriction, we may elect to     purchase the excess shares (i.e., the shares that cause the     violation of the   23                     restriction) or require that the excess shares be sold to a     third party whose ownership will not violate the restriction;         •       pending a required divestiture of these excess shares, the     holder whose beneficial ownership violates the 5% restriction     may not vote the shares in excess of the 5% threshold; and         •       if our board of directors, or its permitted designee, determines     that a transfer, attempted transfer or other event violating     this restriction has taken place, we must take whatever action     we deem advisable to prevent or refuse to give effect to the     transfer, including refusal to register the transfer, disregard     of any vote of the shares by the prohibited owner, or the     institution of proceedings to enjoin the transfer.         Our board of directors has the authority to make determinations as to whether any particular holder of our capital stock is a telecommunications service provider or an affiliate of a telecommunications service provider. Any person who acquires, or attempts or intends to acquire, beneficial ownership of our stock that will or may violate this restriction must notify us as provided in our certificate of incorporation. In addition, any person who becomes the beneficial owner of 5% or more of our stock must notify us and certify that such person is not a telecommunications service provider or an affiliate of a telecommunications service provider. If a 5% stockholder fails to supply the required certification, we are authorized to treat that stockholder as a prohibited owner — meaning, among other things, that we may elect to purchase the excess shares or require that the excess shares be sold to a third party whose ownership will not violate the restriction. We may request additional information from our stockholders to ensure compliance with this restriction. Our board will treat any “group,” as that term is defined in Section 13(d)(3) of the Securities Exchange Act of 1934, as a single person for purposes of applying the ownership and transfer restrictions in our certificate of incorporation.        Nothing in our certificate of incorporation restricts our ability to purchase shares of our capital stock. If a purchase by us of shares of our capital stock results in a stockholder’s percentage interest in our outstanding capital stock increasing to over the 5% threshold, such stockholder must deliver the required certification regarding such stockholder’s status as a telecommunications service provider or affiliate of a telecommunications service provider. In addition, to the extent that a repurchase by us of shares of our capital stock causes any stockholder to violate the restrictions on ownership and transfer contained in our certificate of incorporation, that stockholder will be subject to all of the provisions applicable to prohibited owners, including required divestiture and loss of voting rights.        These restrictions and requirements may:            •       discourage industry participants that might have otherwise been     interested in acquiring us from making a tender offer or     proposing some other form of transaction that could involve a     premium price for our shares or otherwise be in the best     interests of our stockholders; and         •       discourage investment in us by other investors who are     telecommunications service providers or who may be deemed to be     affiliates of a telecommunications service provider.         The standards for determining whether an entity is a “telecommunications service provider” are established by the FCC. In general, a telecommunications service provider is an entity that offers telecommunications services to the public at large, and is, therefore, providing telecommunications services on a common carrier basis. Moreover, a party will be deemed to be an affiliate of a telecommunications service provider if that party controls, is controlled by, or is under common control with, a telecommunications service provider. A party is deemed to control another if that party, directly or indirectly:            •       owns 10% or more of the total outstanding equity of the other     party;         •       has the power to vote 10% or more of the securities having     ordinary voting power for the election of the directors or     management of the other party; or         •       has the power to direct or cause the direction of the management     and policies of the other party.         The standards for determining whether an entity is a telecommunications service provider or an affiliate of a telecommunications service provider and the rules applicable to telecommunications service providers and  24       their affiliates are complex and may be subject to change. Each stockholder is responsible for notifying us if it is a telecommunications service provider or an affiliate of a telecommunications service provider.
Not applicable.             ITEM 2.  PROPERTIES.         Our corporate headquarters are located in Sterling, Virginia under leases that are scheduled to expire in July and August 2010. We have two five-year renewal options on these leases. We also lease operating space in Concord, California; Charlotte, North Carolina; and the District of Columbia under leases that expire in August 2006, November 2007 and November 2009, respectively.        All of our facility leases are with unaffiliated third parties. We believe that our existing facilities are sufficient to meet our requirements.             ITEM 3.  LEGAL PROCEEDINGS.         From time to time, we are subject to claims in legal proceedings arising in the normal course of our business. We do not believe that we are party to any pending legal action that could reasonably be expected to have a material adverse effect on our business or operating results.        On April 9, 2004, Douglas Armentrout, the former chief executive officer of NeuLevel, Inc. filed a complaint against us, NeuLevel, Inc. and Jeffrey Ganek, our Chairman and Chief Executive Officer, in the Superior Court of the District of Columbia (Civil Action No. 04-0002814). The complaint alleges, among other things, that we, NeuLevel and Mr. Ganek convinced Mr. Armentrout to leave his former employment in January 2001 and forfeit substantial compensation benefits by means of false promises regarding the employment benefits he would enjoy with us or NeuLevel, and/or otherwise breached certain agreements with Mr. Armentrout regarding his employment status and benefits. In addition, the complaint alleges that Mr. Armentrout was wrongfully terminated in January 2002 to prevent him from investigating alleged fraudulent accounting practices as between us and NeuLevel. The complaint seeks approximately $20 million in damages, $15 million of which are alleged emotional distress and punitive damages. We, NeuLevel and Mr. Ganek dispute all of these claims and are vigorously defending ourselves against the allegations in the complaint. We are paying our, NeuLevel’s and Mr. Ganek’s legal expenses relating to this complaint.             ITEM 4.  SUBMISSION OF MATTERS TO A VOTE OF SECURITY HOLDERS.         None.       PART II             ITEM 5.  MARKET FOR REGISTRANT’S COMMON EQUITY, RELATED     STOCKHOLDER MATTERS AND ISSUER PURCHASES OF EQUITY     SECURITIES.    Market for Our Common Stock        Prior to June 29, 2005, there was no established public trading market for our Class A common stock. Since June 29, 2005, our Class A common stock has traded on the New York Stock Exchange under the symbol “NSR.” As of March 17, 2006, our Class A common stock was held by 66 stockholders of record. The  25       following table sets forth the per-share range of the high and low sales prices of our Class A common stock as reported on the New York Stock Exchange for the periods indicated:                             High   Low                 Fiscal year ended December 31, 2005                          First quarter      N/A       N/A           Second quarter    $ 26.67     $ 24.50           Third quarter    $ 33.02     $ 25.35           Fourth quarter    $ 32.95     $ 28.85            There is no established public trading market for our Class B common stock. As of March 17, 2006, our Class B common stock was held by 15 stockholders of record.   Dividends        We did not pay any cash dividends on our Class A or Class B common stock in 2004 or 2005 and we do not expect to pay any cash dividends on our common stock for the foreseeable future. We currently intend to retain any future earnings to finance our operations and growth. Our revolving credit facility limits our ability to declare or pay dividends. We are also limited by Delaware law in the amount of dividends we can pay. Any future determination to pay cash dividends will be at the discretion of our board of directors and will depend on earnings, financial condition, operating results, capital requirements, any contractual restrictions and other factors that our board of directors deems relevant.   Recent Sales of Unregistered Securities        Share numbers in the following discussion have been adjusted to give effect to the stock split effected as part of the Recapitalization.        In February 2005, we issued 35,745 shares of common stock in partial consideration for an acquisition. This issuance was undertaken in reliance upon the exemptions from the registration requirements of the Securities Act of 1933, as amended, afforded by Rule 505 promulgated thereunder, as a limited offering that, among other things, did not exceed $5.0 million. We believe that exemptions other than the foregoing exemption may exist for this transaction.        Between January 1, 2005 and September 19, 2005, under our equity incentive plans we issued to directors, officers, employees and consultants options to purchase 1,024,844 shares of common stock with per share exercise prices ranging from $10.86 to $27.85, and issued 1,031,155 shares of common stock upon exercise of options during that time. We received aggregate proceeds of $2,096,384 from the payment of the exercise price with respect to such options. These issuances were undertaken in reliance upon the exemptions from the registration requirements of the Securities Act of 1933, including by Rule 701 promulgated thereunder, as transactions pursuant to the compensatory benefit plans and contracts relating to compensation. From January 2005 through February 2005, however, we did not supply the holders of options granted under our equity incentive plan with our financial statements or information about the risks associated with investment in our securities, as required to comply with Rule 701. As a result, shares issued upon exercise of these options were issued in violation of Section 5 of the Securities Act of 1933, and holders of such shares have the right to rescind their purchases, subject to applicable statutes of limitations.        In December 1999, we issued warrants to acquire 6,361,383 shares of our common stock to affiliates of Warburg Pincus for an aggregate exercise price of approximately $424,000. In connection with the public offering of our common stock in December 2005, these affiliates of Warburg Pincus exercised these warrants. The issuance of the 6,361,383 shares of our Class A common stock upon the exercise of the warrants was undertaken in reliance upon the exemption from the registration requirements of the Securities Act provided by Section 3(a)(9) of the Securities Act. No commission or other remuneration was paid in connection with the issuance of the shares upon the exercise of the warrants. The shares issued upon exercise of these warrants were resold in the public offering of our Class A common stock in December 2005 pursuant to the  26      Registration Statement on Form S-1 (File No. 333-129700), which was declared effective on December 6, 2005, and the Registration Statement on Form S-1 (File No. 333-130176), which was effective upon filing on December 7, 2005 in accordance with Rule 462(b) under the Securities Act of 1933. We believe that exemptions other than the foregoing exemption may exist for this transaction.             ITEM 6.  SELECTED FINANCIAL DATA.         The tables below present selected consolidated statements of operations data for each of the five years ended December 31, 2005 and selected consolidated balance sheet data as of December 31, 2001, 2002, 2003, 2004 and 2005. The selected consolidated statements of operations data for each of the three years ended December 31, 2003, 2004 and 2005, and the selected consolidated balance sheet data as of December 31, 2004 and 2005, have been derived from, and should be read together with, our audited consolidated financial statements and related notes appearing in this report. The selected consolidated statements of operations data for each of the two years ended December 31, 2001 and 2002, and the selected consolidated balance sheet data as of December 31, 2001, 2002 and 2003, have been derived from our audited consolidated financial statements and related notes not included in this report. The share and per share data included in the selected consolidated statements of operations data for the years ended December 31, 2001, 2002, 2003, and 2004 reflect the 1.4-for-1 split of our common stock effected as part of the Recapitalization, but do not reflect other aspects of the Recapitalization.  27           The following information should be read together with, and is qualified in its entirety by reference to, the more detailed information contained in “Management’s Discussion and Analysis of Financial Condition and Results of Operations” in Item 7 of this report and our consolidated financial statements and related notes in Item 8 of this report.                                                         Year Ended December 31,               2001   2002   2003   2004   2005                               (In thousands, except per share data)     Consolidated Statements of Operations Data:                                                    Total revenue    $ 74,176     $ 90,972     $ 111,693     $ 165,001     $ 242,469             Operating expense:                                                      Cost of revenue (excluding depreciation and amortization shown     separately below)      40,770       36,677       37,846       49,261       64,891               Sales and marketing      27,362       13,855       14,381       22,743       29,543               Research and development      8,621       6,256       6,678       7,377       11,883               General and administrative      16,372       13,366       11,359       21,144       28,048               Depreciation and amortization      10,857       27,020       16,051       17,285       16,025               Restructuring charges (recoveries)      8,928       7,332       (1,296 )     (220 )     (389 )             Asset impairment charge      —       13,190       —       —       —               Amortization of goodwill      3,510       —       —       —       —                                             116,420       117,696       85,019       117,590       150,001                                               (Loss) income from operations      (42,244 )     (26,724 )     26,674       47,411       92,468             Other (expense) income:                                                      Interest expense      (3,416 )     (6,260 )     (3,119 )     (2,498 )     (2,121 )             Interest income      4,089       1,876       1,299       1,629       2,406                                               (Loss) income before minority interest and income taxes      (41,571 )     (31,108 )     24,854       46,542       92,753             Minority interest      1,326       1,908       10       —       (104 )                                             (Loss) income before income taxes      (40,245 )     (29,200 )     24,864       46,542       92,649             Provision for income taxes      1,250       —       836       1,166       37,251                                               Net (loss) income      (41,495 )     (29,200 )     24,028       45,376       55,398             Dividends on and accretion of preferred stock      (4,888 )     (9,102 )     (9,583 )     (9,737 )     (4,313 )                                             Net (loss) income    $ (46,383 )   $ (38,302 )   $ 14,445     $ 35,639     $ 51,085                                               Net (loss) income attributable to common stockholders per common     share:                                                      Basic    $ (12.13 )   $ (9.04 )   $ 3.09     $ 6.33     $ 1.48                                                 Diluted    $ (12.13 )   $ (9.04 )   $ 0.31     $ 0.57     $ 0.72                                               Weighted average common shares outstanding:                                                      Basic      3,825       4,236       4,680       5,632       34,437                                                 Diluted      3,825       4,236       76,520       80,237       77,046                                                                                           As of December 31,               2001   2002   2003   2004   2005                               (In thousands)     Consolidated Balance Sheet Data:                                                  Cash, cash equivalents and short-term investments    $ 33,663     $ 21,347     $ 63,987     $ 63,929     $ 103,475           Working capital      3,098       3,633       23,630       38,441       113,296           Goodwill and intangible assets      44,087       44,087       54,751       50,703       54,150           Total assets      199,067       132,544       190,245       211,454       281,771           Deferred revenue and customer credits, excluding current portion      2,175       2,910       14,840       13,892       18,463           Long-term debt and capital lease obligations, excluding current     portion      25,234       7,722       5,996       7,964       4,459           Convertible preferred stock, Series B, Series C and     Series D      142,356       151,458       161,041       140,454       —           Total stockholders’ (deficit) equity      (49,265 )     (87,300 )     (68,581 )     (31,858 )     186,163      28                 ITEM 7.  MANAGEMENT’S DISCUSSION AND ANALYSIS OF FINANCIAL     CONDITION AND RESULTS OF OPERATIONS.         You should read the following discussion and analysis in conjunction with the information set forth under “Selected Financial Data” in Item 6 of this report and our consolidated financial statements and related notes in Item 8 of this report. The statements in this discussion related to our expectations regarding our future performance, liquidity and capital resources, and other non-historical statements in this discussion, are forward-looking statements. These forward-looking statements are subject to numerous risks and uncertainties, including, but not limited to, the risks and uncertainties described in “Risk Factors” in Item 1A of this report and “Business — Cautionary Note Regarding Forward-Looking Statements” in Item 1 of this report. Our actual results may differ materially from those contained in or implied by any forward-looking statements.   Overview        We provide the North American communications industry with essential clearinghouse services. We operate the authoritative directories that manage virtually all telephone area codes and numbers, and we enable the dynamic routing of calls among thousands of competing communications service providers, or CSPs, in the United States and Canada. All CSPs that offer telecommunications services to the public at large, or telecommunications service providers, such as Verizon Communications Inc., Sprint Nextel Corporation, AT&T Corp. and Cingular Wireless LLC, must access our clearinghouse as one of our customers to properly route virtually all of their customers’ calls. We also provide clearinghouse services to emerging CSPs, including Internet service providers, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, we manage the authoritative directories for the .us and .biz Internet domains, as well as for U.S. Common Short Codes, part of the short messaging service relied upon by the U.S. wireless industry.   Our Company        We were founded to meet the technical and operational challenges of the communications industry when the U.S. government mandated local number portability in 1996. While we remain the provider of the authoritative solution that the communications industry relies upon to meet this mandate, we have developed a broad range of innovative services to meet an expanded range of customer needs. We provide the communications industry in North America with critical technology services that solve the industry’s addressing, interoperability and infrastructure needs of CSPs.        These services are now used by CSPs to manage a range of their technical and operating requirements, including:            •   Addressing. We enable CSPs to use critical, shared     addressing resources, such as telephone numbers, Internet     top-level domain names, and U.S. Common Short Codes.         •   Interoperability. We enable CSPs to exchange and share     critical operating data so that communications originating on     one provider’s network can be delivered and received on the     network of another CSP. We also facilitate order management and     work flow processing among CSPs.         •   Infrastructure and Other. We enable CSPs to more     efficiently manage changes in their own networks by centrally     managing certain critical data they use to route communications     over their own networks.         We derive a substantial portion of our annual revenue on a transaction basis, most of which is derived from long-term contracts.        Our costs and expenses consist of cost of revenue, sales and marketing, research and development, general and administrative, and depreciation and amortization.        Cost of revenue includes all direct materials, direct labor, and those indirect costs related to generation of revenue such as indirect labor, materials and supplies. Our primary cost of revenue is related to our information technology and systems department, including network costs, data center maintenance, database  29       management, data processing costs, and facilities costs. In addition, cost of revenue includes personnel costs associated with service implementation, product maintenance, customer deployment and customer care, including salaries, stock-based compensation and other personnel-related expense. Cost of revenue also includes costs relating to developing modifications and enhancements of our existing technology and services, as well as royalties paid related to our Common Short Code services.        Sales and marketing expense consists of personnel costs, advertising costs and relationship marketing costs. This expense includes personnel costs, such as salaries, sales commissions, travel, stock-based compensation, and other personnel-related expense; trade shows; costs of computer and communications equipment and support services; facilities costs; consulting fees; costs of marketing programs, such as Internet and print, including product branding, market analysis and forecasting; and customer relationship management.        Research and development expense consists primarily of personnel costs, including salaries, stock-based compensation and other personnel-related expense; consulting fees; and the costs of facilities, computer and support services used in service and technology development.        General and administrative expense consists primarily of personnel costs, including salaries, stock-based compensation, and other personnel-related expense, for our executive, administrative, legal, finance, and human resources functions. General and administrative expense also includes facilities, management information systems, support services, professional services fees, certain audit, tax and license fees, and bad debt expense.        Depreciation and amortization relates primarily to our property and equipment and includes our network infrastructure and facilities related to our services and the amortization of identifiable intangibles.   Critical Accounting Policies and Estimates        The discussion and analysis of our financial condition and results of operations are based on our consolidated financial statements, which have been prepared in accordance with U.S. generally accepted accounting principles, or U.S. GAAP. The preparation of these financial statements in accordance with U.S. GAAP requires us to utilize accounting policies and make certain estimates and assumptions that affect the reported amounts of assets and liabilities, the disclosure of contingencies as of the date of the financial statements and the reported amounts of revenue and expense during a fiscal period. The Securities and Exchange Commission considers an accounting policy to be critical if it is important to a company’s financial condition and results of operations, and if it requires significant judgment and estimates on the part of management in its application. We have discussed the selection and development of the critical accounting policies with the audit committee of our board of directors, and the audit committee has reviewed our related disclosures in this report. Although we believe that our judgments and estimates are appropriate and correct, actual results may differ from those estimates.        We believe the following to be our critical accounting policies because they are important to the portrayal of our financial condition and results of operations and they require critical management judgments and estimates about matters that are uncertain. If actual results or events differ materially from those contemplated by us in making these estimates, our reported financial condition and results of operation for future periods could be materially affected. See Item 1A of this report, “Risk Factors,” for certain matters that may bear on our future results of operations.           Revenue Recognition         Our revenue recognition policies are in accordance with Securities and Exchange Commission Staff Accounting Bulletin No. 104, Revenue Recognition. We provide the following services pursuant to various private commercial and government contracts.        Addressing. Our addressing services include telephone number administration, implementing the allocation of pooled blocks of telephone numbers, and directory services for Internet domain names and U.S. Common Short Codes. We generate revenue from our telephone number administration services under  30       two government contracts. Under our contract to serve as the North American Numbering Plan Administrator, we earn a fixed annual fee, and we recognize this fee as revenue on a straight-line basis as services are provided. In the event we estimate losses on our fixed fee contract, we recognize these losses in the period in which a loss becomes apparent. Under our contract to serve as the National Pooling Administrator, we are reimbursed for costs incurred plus a fixed fee associated with administration of the pooling system. We recognize revenue for this contract based on costs incurred plus a pro rata amount of the fixed fee.        In addition to the administrative functions associated with our role as the National Pooling Administrator, we also generate revenue from implementing the allocation of pooled blocks of telephone numbers under our long-term contracts with North American Portability Management LLC, and we recognize revenue on a per transaction fee basis as the services are performed. For our Internet domain name services, we generate revenue for Internet domain name registrations, which generally have contract terms between one and ten years. We recognize revenue on a straight-line basis over the lives of the related customer contracts. We generate revenue from our Common Short Code services under short-term contracts ranging from three to twelve months, and we recognize revenue on a straight-line basis over the term of the customer contracts.        Interoperability. Our interoperability services consist primarily of wireline and wireless number portability and order management services. We generate revenue from number portability under our long-term contracts with North American Portability Management LLC and Canadian LNP Consortium, Inc. We recognize revenue on a per transaction fee basis as the services are performed. We provide order management services consisting of customer set-up and implementation followed by transaction processing under contracts with terms ranging from one to three years. Customer set-up and implementation is not considered a separate deliverable; accordingly, the fees are deferred and recognized as revenue on a straight-line basis over the term of the contract. Per-transaction fees are recognized as the transactions are processed.        Infrastructure and Other. Our infrastructure services consist primarily of network management and connection services. We generate revenue from network management services under our long-term contracts with North American Portability Management LLC. We recognize revenue on a per transaction fee basis as the services are performed. In addition, we generate revenue from connection fees and system enhancements under our contracts with North American Portability Management LLC. We recognize our connection fee revenue as the service is performed. System enhancements are provided under contracts in which we are reimbursed for costs incurred plus a fixed fee. Revenue is recognized based on costs incurred plus a pro rata amount of the fee.           Significant Contracts         We provide wireline and wireless number portability, implement the allocation of pooled blocks of telephone numbers and provide network management services pursuant to seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States. We recognize revenue under our contracts with North American Portability Management LLC primarily on a per-transaction basis. The aggregate fees for transactions processed under these contracts are determined by the total number of transactions, and these fees are billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share is based on each respective telecommunications service provider’s share of the aggregate end-user services revenues of all U.S. telecommunications service providers as determined by the FCC. On November 4, 2005, BellSouth Corporation filed a petition seeking changes in the way our customers are billed for services provided by us under our contracts with North American Portability Management LLC. Following this filing, the FCC requested comments from interested parties with respect to this petition. As of March 15, 2006, the FCC has not initiated a formal rulemaking process, and the BellSouth petition remains pending. We do not believe that this proposed change to the manner in which we bill for services under these contracts would have a material impact on our customers’ demand for these services. Under our contracts, we also bill a revenue recovery collections, or RRC, fee of a percentage of monthly billings to our customers, which is available to us if any telecommunications service provider fails to pay its allocable share of total transactions charges. If the RRC fee is insufficient for that purpose, these contracts also provide for the recovery of such differences from the remaining telecommunications service providers.  31            The per-transaction pricing under these contracts provides for annual volume credits that are earned on all transactions in excess of the pre-determined annual volume threshold. For 2005, the maximum aggregate volume credit was $7.5 million, which was applied via a reduction in per-transaction pricing once the pre-determined annual volume threshold was surpassed. When the aggregate credit was fully satisfied, the per-transaction pricing was restored to the prevailing contractual rate. In August 2005, the pre-determined annual transaction volume threshold under these contracts was exceeded, which resulted in the issuance of $7.5 million of volume credits for the year ended December 31, 2005.        Conversely, billings in 2003 and 2004 continued at the original contractual rate after the annual volume threshold was surpassed. Billings in excess of the discounted pricing were recorded as customer credits (liability) on the consolidated balance sheet with a corresponding reduction to revenue. In the following year when the credits were applied to invoices rendered, customer credits were reduced with a corresponding credit to accounts receivable. The annual pre-determined volume threshold was surpassed in the fourth quarters of 2003 and 2004 resulting in the reduction of revenue and recognition of customer credits of $6.0 million and $11.9 million, respectively.        In December 2003, these contracts were amended to extend their expiration date from May 2006 to May 2011, and the per-transaction fee charged to our customers over the term of the contracts was reduced. As part of the amendments, we agreed to retroactively apply the new transaction fee to all 2003 transactions processed and granted credits totaling $16.0 million. These credits were applied to customer invoices over a 23-month period beginning in January 2004. Additionally, we obtained letters of credit totaling $16.0 million in January 2004 to secure a portion of these customer credits. As of December 31, 2004, approximately $15.5 million of these customer credits were outstanding; as of December 31, 2005, none of these customer credits were outstanding.           Service Level Standards         Pursuant to certain of our private commercial contracts, we are subject to service level standards and to corresponding penalties for failure to meet those standards. We record a provision for these performance-related penalties when we become aware that required service levels that would trigger such a penalty have not been met, which results in a corresponding reduction of our revenue.        For more information regarding how we recognize revenue for each of our service categories, please see the discussion above under “— Revenue Recognition.”           Valuation of Goodwill and Intangible Assets         Our acquisition of our business from the Lockheed Martin Corporation in November 1999 as well as the acquisitions of BizTelOne, NightFire, fiducianet, and Foretec in January 2003, August 2003, February 2005 and December 2005, respectively, resulted in the recording of goodwill, which represents the excess of the purchase price over the fair value of assets acquired, as well as other definite-lived intangible assets. Under present accounting rules (Statement of Financial Accounting Standards No. 142, Goodwill and Other Intangible Assets), goodwill is no longer subject to amortization; instead it is subject to impairment testing criteria. Other acquired definite-lived intangible assets are being amortized over their estimated useful lives, although those with indefinite lives are not to be amortized but are tested at least annually for impairment, using a lower of cost or fair value approach. We test for impairment on an annual basis or on an interim basis if circumstances change that would indicate the possibility of impairment. The impairment review may require an analysis of future projections and assumptions about our operating performance. If such a review indicates that the assets are impaired, an expense would be recorded for the amount of the impairment, and the corresponding impaired assets would be reduced in carrying value.           Impairment of Long-Lived Assets         Our long-lived assets primarily consist of property and equipment and intangible assets. In accordance with Statement of Financial Accounting Standards No. 144, Accounting for the Impairment or Disposal of Long-Lived Assets, we evaluate the recoverability of our long-lived assets for impairment whenever events or  32       changes in circumstances indicate the carrying value of such assets may not be recoverable. If an indication of impairment is present, we compare the estimated undiscounted future cash flows to be generated by the asset to its carrying amount. If the undiscounted future cash flows are less than the carrying amount of the asset, we record an impairment loss equal to the excess of the asset’s carrying amount over its fair value. Substantially all of our long-lived assets are located in the United States.           Accounts Receivable, Revenue Recovery Collections, and     Allowance for Doubtful Accounts         Accounts receivable are recorded at the invoiced amount and do not bear interest. In accordance with our contracts with North American Portability Management LLC, we bill a RRC fee of a percentage of monthly billings to our customers. The aggregate RRC fees collected may be used to offset uncollectible receivables from an individual customer. The RRC fees are recorded as an accrued liability when collected. For the period from January 1, 2002 through June 30, 2004, this fee was 3% of monthly billings. On July 1, 2004, the RRC fee was reduced to 2%. On July 1, 2005, the RRC fee was reduced to 1%. Any accrued RRC fees in excess of uncollectible receivables are paid back to the customers annually on a pro rata basis. RRC fees of $4.3 million and $2.5 million are included in accrued expenses as of December 31, 2004 and December 31, 2005, respectively. All other receivables related to services not covered by the RRC fees are evaluated and, if deemed not collectible, are appropriately reserved.           Deferred Income Taxes         We recognize deferred tax assets and liabilities based on temporary differences between the financial reporting bases and the tax bases of assets and liabilities. These deferred tax assets and liabilities are measured using the enacted tax rates and laws that will be in effect when such amounts are expected to reverse or be utilized. The realization of deferred tax assets is contingent upon the generation of future taxable income. When appropriate, we recognize a valuation allowance to reduce such deferred tax assets to amounts that are more likely than not to be ultimately realized. The calculation of deferred tax assets (including valuation allowances) and liabilities requires us to apply significant judgment related to such factors as the application of complex tax laws, changes in tax laws and our future operations. We review our deferred tax assets on a quarterly basis to determine if a valuation allowance is required based upon these factors. Changes in our assessment of the need for a valuation allowance could give rise to a change in such allowance, potentially resulting in additional expense or benefit in the period of change.           Stock-Based Compensation         We account for employee stock-based compensation in accordance with the provisions of Accounting Principles Board Opinion No. 25, Accounting for Stock Issued to Employees (APB No. 25) and related interpretations, which require us to recognize compensation cost for the excess of the fair value of the stock at the grant date over the exercise price, if any. An alternative method of accounting would apply the principles of Statement of Financial Accounting Standards (SFAS) No. 123, Accounting for Stock-Based Compensation (SFAS No. 123), which require the fair value of the stock option to be recognized at the date of grant and amortized as compensation expense over the stock option’s vesting period. No stock-based employee compensation cost for stock options is reflected in net income, as all options granted under the plans had an exercise price equal to the market value of the underlying common stock on the date of grant. Stock-based compensation for non-employees is accounted for using the fair value-based method in accordance with SFAS No. 123 and Emerging Issues Task Force Issue No. 96-18, Accounting for Equity Instruments that are Issued to Other than Employees for Acquiring, or in Connection with Selling Goods or Services (EITF 96-18). See the discussion under “— Recent Accounting Pronouncements” below.   Acquisitions        We have expanded the scope of our services and increased our customer base by selectively acquiring four small businesses. Our objective for each acquisition was to leverage our clearinghouse capabilities in order to maximize efficiency and provide added value to our customers. The stock consideration described below  33       reflects the 1.4-for-1 stock split effected as part of the Recapitalization, but does not reflect the other aspects of the Recapitalization.           BizTelOne, Inc.         In January 2003, we acquired BizTelOne, Inc. for $2.5 million in cash, plus a $700,000 earn-out amount accrued in 2004, which was paid in March 2005. This acquisition provided us with additional order management service technology and market presence needed to facilitate growth in the revenue generated by our interoperability services.           NightFire Software, Inc.         In August 2003, we acquired certain assets of NightFire Software, Inc. for $4.1 million in cash (net of $293,000 cash acquired) and the issuance of 855,069 shares of our Class B common stock for total purchase consideration of $7.8 million. NightFire’s products enable fully automated voice, data, and broadband access services fulfillment for competitive local exchange carriers, integrated communications carriers, incumbent local exchange carriers, inter-exchange carriers, Internet service providers, and other types of service providers. This acquisition further expanded our order management services technology and market presence and aided in the growth of our interoperability revenue.           fiducianet, Inc.         In February 2005, we acquired fiducianet, Inc. for $2.2 million in cash and the issuance of 35,745 shares of our common stock for total purchase consideration of $2.6 million. The acquisition of fiducianet enables us to serve as a single point of contact in managing all day-to-day customer obligations involving subpoenas, court orders and law enforcement agency requests under electronic surveillance laws, including CALEA, the USA Patriot Act of 2001 and the Homeland Security Act of 2002.           Foretec Seminars Inc.         In December 2005, we acquired Foretec Seminars Inc., a provider of secretariat services to the Internet Engineering Task Force (IETF), from the Corporation for National Research Initiatives (CNRI) for $875,000 in cash, of which $500,000 is payable upon the achievement of certain milestones, as well as the payment of approximately $213,000 in legal fees incurred by CNRI to establish a public trust to administer IETF-related intellectual property. In accordance with Financial Accounting Standards Board (FASB) Statement No. 141, Business Combinations, the $500,000 payable upon the achievement of certain milestones has been included in the purchase consideration since this amount was determinable as of the date of acquisition.   Current Trends Affecting Our Results of Operations        We have experienced increased demand for our clearinghouse services, which has been driven by market trends such as network expansion to meet subscriber growth, the implementation of new technologies, competitive churn, network changes, carrier vendor churn and consolidations.        Wireless carriers are expanding their networks to facilitate wireless subscriber growth, to deliver new wireless applications, and to foster wireless competition. As CSPs expand and upgrade their networks and technology to enable the delivery of high-speed wireless services, we anticipate that they will increasingly rely on our services, and wireless-related transactions will remain a major contributor to our transaction volume growth.        Advancements in the communications industry, such as changes from time division multiplexing, or TDM, to global system for mobile, or GSM, have driven increased infrastructure transactions in our clearinghouse. As the industry migrates towards next-generation technologies and applications, we anticipate that demand for our infrastructure services will increase.  34            As the communications industry has changed to meet consumer demands and new technological advancements, consolidation among industry participants has increased. Consolidation requires the integration of disparate systems and networks, which has driven increased demand for our addressing, interoperability and infrastructure services. We anticipate that future consolidations will continue to drive growth in our transaction volumes.        Competition has placed significant pressure on CSPs to reduce costs. At the same time, the complexity of back office operations has increased as CSPs work to manage the proliferation of new technologies and new, complex end-user services provided across a large number of independent networks. Our clearinghouse services assist CSPs in equipping their back office systems to manage the added complexity of sharing essential data with other CSPs in this environment, thereby allowing CSPs to reduce their capital investments and operating expenses. As the CSPs make changes to their back office to remain competitive, we anticipate that demand for our infrastructure services will increase.        During 2005, addressing transactions increased due to the emergence of IP service providers. In particular, VoIP service providers are expanding their operations. This expansion has led to an increased need for access to inventories of telephone numbers, which has driven demand for our addressing services. We expect continued growth in the number of addressing transactions in 2006 as IP service providers continue to develop an inventory of telephone number resources. In addition, we expect to see increased demand for our infrastructure services as carriers change their networks to facilitate Internet telephony services.        To support our growth, we will continue to explore opportunities to improve our operating efficiencies. In 2005, we initiated several programs to improve operating efficiencies, such as the utilization of offshore technical resources for systems engineering, implementation of new hardware and software technology in our clearinghouse, and management of process improvement teams. Having become a public company in 2005, we have experienced, and will continue to experience, increases in certain general and administrative expenses to comply with the laws and regulations applicable to public companies. These laws and regulations include the provisions of the Sarbanes-Oxley Act of 2002 and the rules of the Securities and Exchange Commission and the New York Stock Exchange. To comply with the corporate governance and operating requirements of being a public company, we have incurred, and will continue to incur, increases in such items as personnel costs, professional services fees, fees for independent directors and the cost of directors and officers liability insurance. We believe that these costs will approximate $3.0 to $3.5 million annually.        In 2003 and 2004, we were able to utilize net operating loss carryforwards and deferred tax benefits from previous years to offset taxable income and income tax expense related to U.S. federal income taxes. These carryforwards and deferrals were exhausted in 2004. In 2005, our profits were, and in future years we expect our profits to be, subject to U.S. federal income taxes at the statutory rates.  35       Consolidated Results of Operations           Year Ended December 31, 2004 Compared to the Year     Ended December 31, 2005         The following table presents an overview of our results of operations for the years ended December 31, 2004 and 2005. The 2004 share and per share data in the following table reflect the 1.4-for-1 stock split effected as part of the Recapitalization, but do not reflect the other aspects of the Recapitalization.                                                   2005   2004 vs. 2005                       2004   $   $ Change   % Change                           (In thousands, except per share data)         Revenue:                                            Addressing    $ 50,792     $ 75,036     $ 24,244       47.7 %           Interoperability      34,228       52,488       18,260       53.3 %           Infrastructure and other      79,981       114,945       34,964       43.7 %                                     Total revenue      165,001       242,469       77,468       47.0 %         Operating expense:                                            Cost of revenue (excludes depreciation and amortization shown     separately below)      49,261       64,891       15,630       31.7 %           Sales and marketing      22,743       29,543       6,800       29.9 %           Research and development      7,377       11,883       4,506       61.1 %           General and administrative      21,144       28,048       6,904       32.7 %           Depreciation and amortization      17,285       16,025       (1,260 )     (7.3 )%           Restructuring recoveries      (220 )     (389 )     (169 )     76.8 %                                     117,590       150,001       32,411       27.6 %                                     Income from operations      47,411       92,468       45,057       95.0 %         Other (expense) income:                                            Interest expense      (2,498 )     (2,121 )     377       (15.1 )%           Interest income      1,629       2,406       777       47.7 %                                     Income before minority interest and income taxes      46,542       92,753       46,211       99.3 %         Minority interest      —       (104 )     (104 )     —                                       Income before income taxes      46,542       92,649       46,107       99.1 %         Provision for income taxes      1,166       37,251       36,085       3094.8 %                                     Net income      45,376       55,398       10,022       22.1 %         Dividends on and accretion of preferred stock      (9,737 )     (4,313 )     5,424       (55.7 )%                                     Net income attributable to common stockholders    $ 35,639     $ 51,085     $ 15,446       43.3 %                                     Net income attributable to common stockholders per common share:                                            Basic    $ 6.33     $ 1.48                                                         Diluted    $ 0.57     $ 0.72                                                       Weighted average common shares outstanding:                                            Basic      5,632       34,437                                                         Diluted      80,237       77,046                                                  36               Revenue         Total revenue. Total revenue increased $77.5 million due to increases in addressing, interoperability and infrastructure transactions. Contributing to this increase was a contractual reduction in the total volume-based credits available to our customers under our contracts with North American Portability Management LLC, which resulted in an $11.9 million reduction in revenue in 2004, compared to a $7.5 million reduction in 2005.        Addressing. Addressing revenue increased $24.2 million due to the continued implementation of, and expansion of carrier networks to facilitate, new communications services, such as Internet telephony, as well as growth in the use of U.S. Common Short Codes and other wireless data services. Of this amount, revenue from pooling transactions increased $17.3 million, primarily as service providers continued to build inventories of telephone numbers in multiple area codes and rate centers to be able to offer them to Internet and wireless telephony users. In addition, U.S. Common Short Codes revenue increased $5.5 million due to an increase in the number of subscribers for U.S. Common Short Codes, as well as an increase in the number of service providers that carried U.S. Common Short Codes across their networks. Revenue from our domain name services increased $1.7 million due in large part to the increased number of names under management, offset by a reduction of approximately $0.6 million in our administration fees under our contract to serve as the North American Numbering Plan Administrator.        Interoperability. Interoperability revenue increased $18.3 million due to an increase in wireline and wireless competition and the associated movement of end users from one CSP to another, carrier consolidation, and broader usage of our expanding service offerings such as enhanced order management services for wireless data and Internet telephony providers. Specifically, revenue from number portability transactions increased $10.5 million, and revenue from our order management services increased $7.1 million.        Infrastructure and other. Infrastructure and other revenue increased $35.0 million due to an increase in the demand for our network management services. Of this amount, $28.9 million was attributable to customers making changes to their networks that required actions such as disconnects and modifications to network elements. We believe these changes were driven largely by trends in the industry, including the implementation of new technologies by our customers, wireless technology upgrades, carrier vendor changes and network optimization. Connection fees and other revenue increased $5.2 million in 2005 due in part to revenue related to one-time functionality improvements that our customers requested.           Expense         Cost of revenue. Cost of revenue increased $15.6 million due to growth in personnel, contractor costs to support higher transaction volumes and royalties related to our Common Short Code services. Of this amount, personnel and employee related expense increased $8.6 million due to increased personnel to support our customer deployment group, software engineering group and operations group. Contractor costs increased $4.1 million for software maintenance activities and managing industry changes to our clearinghouse. Additionally, cost of revenue increased by $4.1 million due to royalty expenses related to Common Short Code services and revenue share cost associated with our Internet domain names and registry gateway services. These increases were offset by a $1.2 million decrease in facilities expense, maintenance of hardware and software and other clearinghouse expenses. Cost of revenue as a percentage of revenue decreased from 29.9% for the year ended December 31, 2004 to 26.8% for the year ended December 31, 2005. This decrease in cost of revenue as a percentage of revenue is attributable to operating efficiencies in our clearinghouse operations, which allowed us to increase the number of transactions we processed without proportional increases in personnel costs.        Sales and marketing. Sales and marketing expense increased $6.8 million due to additions to our sales and marketing team to focus on branding, product launches and new business development opportunities, including international expansion. Of this amount, personnel and employee related expense increased $6.2 million, and costs related to industry events increased $0.3 million. Sales and marketing expense as a percentage of revenue decreased from 13.8% for the year ended December 31, 2004 to 12.2% for the year ended December 31, 2005.  37            Research and development. Research and development expense increased $4.5 million due to the development of Internet telephony solutions to enhance our service offerings. Of this increase, personnel and employee related costs increased $3.1 million due to increased headcount, and fees for consultants to augment our internal research and development resources increased $0.9 million. Research and development expense as a percentage of revenue increased from 4.5% for the year ended December 31, 2004 to 4.9% for the year ended December 31, 2005.        General and administrative. General and administrative expense increased $6.9 million primarily due to costs incurred to support business growth and costs incurred in preparation for, and in conjunction with, becoming a public company. We recorded $5.8 million of offering costs related to our public offerings in 2005 and other related expense, which includes legal, accounting and consulting fees. In addition, personnel and employee related expense increased $2.0 million, which was offset in part by a reduction of $0.7 million in general and administrative facility costs. General and administrative expense as a percentage of revenue decreased from 12.8% in the year ended December 31, 2004 to 11.6% for the year ended December 31, 2005.        Depreciation and amortization. Depreciation and amortization expense decreased $1.3 million due to the expiration of certain capital leases. Depreciation and amortization expense as a percentage of revenue decreased from 10.5% for the year ended December 31, 2004 to 6.6% for the year ended December 31, 2005.        Restructuring recoveries. In 2005, we recorded a net restructuring recovery of $0.4 million, which included a restructuring recovery of $0.7 million after entering into a sub-lease for our leased property in Chicago with sub-lease rates more favorable than originally assumed when the restructuring liability for the closure of excess facilities was recorded in 2002. This was offset by a restructuring charge of $317,000 for the closure of our facility in Oakland, CA, which was completed on October 31, 2005.        Interest expense. Interest expense decreased $0.4 million in 2005 as compared to 2004 due to decrease in the number of capital leases. Interest expense as a percentage of revenue decreased from 1.5% for the year ended December 31, 2004 to 0.9% for the year ended December 31, 2005.        Interest income. Interest income increased $0.8 million due to higher average cash balances. Interest income as a percentage of revenue remained flat at 1% for the year ended December 31, 2005, as compared to the year ended December 31, 2004.        Provision for income taxes. We recorded a provision for income taxes of $37.3 million in 2005 to reflect the expected 2005 effective tax rate, as compared to $1.2 million in 2004. As of June 30, 2004, we had generated operating profits for six consecutive quarters. As a result of this earnings trend, we determined that it was more likely than not that we would realize our deferred tax assets and reversed approximately $20.2 million of our deferred tax asset valuation allowance. The reversal resulted in the recognition of an income tax benefit of $16.9 million, and a reduction of goodwill of $3.3 million. The benefit was offset by current income tax expense of $7.6 million and deferred income taxes of $10.7 million, resulting in a net income tax expense of $1.2 million for 2004. Our annual effective income tax rate increased from 2.5% for the year ended December 31, 2004 to 40.2% for the year ended December 31, 2005.  38               Year Ended December 31, 2003 Compared to the Year     Ended December 31, 2004         The following table presents an overview of our results of operations for the years ended December 31, 2003 and 2004. The share and per share data in the following table reflect the 1.4-for-1 stock split effected as part of the Recapitalization, but do not reflect the other aspects of the Recapitalization.                                               2003   2004   2003 vs. 2004                       $   $   $ Change   % Change                           (In thousands, except per share data)         Revenue:                                            Addressing    $ 42,905     $ 50,792     $ 7,887       18.4 %           Interoperability      16,003       34,228       18,225       113.9 %           Infrastructure and other      52,785       79,981       27,196       51.5 %                                     Total revenue      111,693       165,001       53,308       47.7 %         Operating expense:                                            Cost of revenue (excludes depreciation and amortization shown     separately below)      37,846       49,261       11,415       30.2 %           Sales and marketing      14,381       22,743       8,362       58.1 %           Research and development      6,678       7,377       699       10.5 %           General and administrative      11,359       21,144       9,785       86.1 %           Depreciation and amortization      16,051       17,285       1,234       7.7 %           Restructuring recoveries      (1,296 )     (220 )     1,076       83.0 %                                     85,019       117,590       32,571       38.3 %                                     Income from operations      26,674       47,411       20,737       77.7 %         Other (expense) income:                                            Interest expense      (3,119 )     (2,498 )     621       (19.9 )%           Interest income      1,299       1,629       330       25.4 %                                     Income before minority interest and income taxes      24,854       46,542       21,688       87.3 %         Minority interest      10       —       (10 )     —                                       Income before minority interest      24,864       46,542       21,678       87.3 %         Provision for income taxes      836       1,166       330       39.5 %                                     Net income      24,028       45,376       21,348       88.8 %         Dividends on and accretion of preferred stock      (9,583 )     (9,737 )     (154 )     1.6 %                                     Net income attributable to common stockholders    $ 14,445     $ 35,639     $ 21,194       146.7 %                                     Net income attributable to common stockholders per common share:                                            Basic    $ 3.09     $ 6.33                                                         Diluted    $ 0.31     $ 0.57                                                       Weighted average common shares outstanding:                                            Basic      4,680       5,632                                                         Diluted      76,520       80,237                                                           Revenue         Total revenue. Total revenue increased $53.3 million due to increases in addressing, interoperability and infrastructure transactions. Revenue from increased transactions was partially offset by annual volume credits  39       under our contracts with North American Portability Management LLC, based on our exceeding pre-determined annual transaction volume thresholds under those contracts. The impact of this volume credit was $11.9 million in 2004, which was recognized in the fourth quarter and reduced fourth quarter revenue.        Addressing. Addressing revenue increased $7.9 million due primarily to the growth in the number of wireless customers, the increase in new communications services being offered by our customers and the continued expansion of carrier networks. Of this amount, revenue from pooling transactions increased $7.7 million, primarily as service providers built inventories of telephone numbers in multiple area codes and rate centers to be able to offer them to VoIP users. Carrier consolidation also required the use of our pooling service to reallocate pooled blocks of telephone numbers to consolidated networks. In addition, U.S. Common Short Codes revenue increased $2.4 million, reflecting a full year of this service, which commenced in October 2003. These increases were offset by a reduction of $2.5 million in our administration fees under our contract to serve as the North American Numbering Plan Administrator, reflecting the revised lower pricing under the new contract awarded to us in January 2004.        Interoperability. Interoperability revenue increased $18.2 million due to an increase in wireless competition, carrier consolidation and our expanding service offerings, such as order management services for wireless data. Specifically, revenue from number portability increased $9.6 million, and revenue from our order management services, which we initiated in the third quarter of 2003, increased $8.4 million.        Infrastructure and other. Infrastructure and other revenue increased $27.2 million due to an increase in the demand for our network management services. Revenue of $31.0 million was attributable to customers making changes to their networks that required actions such as disconnects and modifications to network elements. We believe these changes were driven largely by the implementation of new technologies by our customers, wireless technology upgrades and network optimization after carrier consolidation. This increase was offset by a $3.8 million decrease in connections fees and other revenue.           Expense         Cost of revenue. Cost of revenue increased $11.4 million due to growth in personnel and employee-related expenses and contractor costs to support higher transaction volumes. Of this amount, personnel and employee-related expenses increased by $3.9 million to support our customer deployment and information technology and systems groups, along with increased contractor costs of $5.2 million for the conversion of acquired software platforms to the clearinghouse. Additionally, cost of revenue increased by $2.1 million due to royalty expenses primarily related to Common Short Code services and revenue share cost associated with our Internet domain name registry gateway services. Cost of revenue as a percentage of revenue decreased from 33.9% for the year ended December 31, 2003 to 29.9% for the year ended December 31, 2004. This decrease in cost of revenue as a percentage of revenue is attributable to operating efficiencies in our clearinghouse operations, which allowed us to increase the number of transactions we processed without proportional increases in personnel costs.        Sales and marketing. Sales and marketing expense increased $8.4 million due to growth in personnel and employee-related expenses to focus on branding and product launches. Of this amount, personnel and employee-related expenses increased $6.7 million as we expanded our sales and marketing team. In addition, external costs related to branding and product launch accounted for $0.9 million of the increase. Sales and marketing expense as a percentage of revenue increased from 12.9% for the year ended December 31, 2003 to 13.8% for the year ended December 31, 2004.        Research and development. Research and development expense increased $0.7 million due to an increase in personnel and employee-related expenses. Research and development expense as a percentage of revenue decreased from 6.0% for the year ended December 31, 2003 to 4.5% for the year ended December 31, 2004.        General and administrative. General and administrative expense increased $9.8 million primarily due to costs incurred to support business growth and in preparation for becoming a public company. These costs include executive additions, systems and process controls and professional fees. General and administrative  40       personnel cost increased $4.6 million, attributable in part to stock-based compensation of $2.1 million. Professional fees and other legal expenses increased $3.4 million. General and administrative expense as a percentage of revenue increased from 10.2% for the year ended December 31, 2003 to 12.8% for the year ended December 31, 2004.        Depreciation and amortization. Depreciation and amortization expense increased $1.2 million due to an increase in capital assets to support increased transaction volume. Depreciation and amortization expense as a percentage of revenue decreased from 14.4% for the year ended December 31, 2003 to 10.5% for the year ended December 31, 2004. This decrease in depreciation and amortization expense as a percentage of revenue reflects improvement in asset utilization.        Restructuring recoveries. In 2002, we disposed of property and equipment from operations and recorded a restructuring liability that included penalties for the cancellation of facility leases, resulting in a charge of $7.3 million. In 2004, $0.2 million of these charges were recovered as a result of updates to the assumptions used in the establishment of the restructuring accrual in 2003.        Interest expense. Interest expense decreased $0.6 million as a result of lower interest charges on outstanding notes as principal was reduced, as well as a decrease in the number of capital leases. Interest expense as a percentage of revenue decreased from 2.8% for the year ended December 31, 2003 to 1.5% for the year ended December 31, 2004.        Interest income. Interest income increased $0.3 million due to higher average cash balances in 2004 compared to 2003. Interest income as a percentage of revenue decreased from 1.2% for the year ended December 31, 2003 to 1.0% for the year ended December 31, 2004.        Provision for income taxes. We recorded a provision for income taxes of $1.2 million for the year ended December 31, 2004, as compared to a provision for income taxes of $0.8 million for the year ended December 31, 2003. As of June 30, 2004, we had generated operating profits for six consecutive quarters. As a result of this earnings trend, we determined that it was more likely than not that we would realize our deferred tax assets and reversed approximately $20.2 million of our deferred tax asset valuation allowance. The reversal resulted in the recognition of an income tax benefit of $16.9 million and a reduction of goodwill of $3.3 million. The benefit was offset by current income tax expense of $7.6 million and deferred income taxes of $10.7 million, resulting in a net income tax expense of $1.2 million.   Liquidity and Capital Resources        Our principal source of liquidity has been cash provided by operations. Our principal uses of cash have been to fund facility expansions, capital expenditures, acquisitions, working capital, dividend payouts on preferred stock, and debt service requirements. We anticipate that our principal uses of cash in the future will be facility expansion, capital expenditures, acquisitions and working capital.        Total cash and cash equivalents and short-term investments were $63.9 million at December 31, 2004, increasing to $103.5 million at December 31, 2005. As of December 31, 2005, we had $4.3 million available under the revolving loan commitment of our bank credit facility, subject to the terms and conditions of that facility.        We believe that our existing cash and cash equivalents, short-term investments and cash from operations will be sufficient to fund our operations for the next twelve months.        As part of the Recapitalization, we paid accrued and unpaid dividends on our preferred stock of approximately $6.3 million. On June 28, 2005, all of the preferred stock was converted into common stock, and no dividends are currently accruing. We have paid or expect to pay offering costs, excluding underwriting discounts and commissions, and other related expenses totaling $5.8 million in connection with our initial public offering and the additional offering of our common stock in December 2005.  41       Discussion of Cash Flows           Cash flows from operations         Net cash provided by operating activities for the year ended December 31, 2005 was $61.2 million, as compared to $64.7 million for the year ended December 31, 2004. This $3.5 million decrease in net cash provided by operating activities was principally the result of a net decrease in changes in operating assets and liabilities of approximately $33.3 million. This decrease was offset by a net increase in adjustments to reconcile net income to net cash flow provided by operating activities of approximately $19.7 million, which was predominantly due to an adjustment of approximately $17.0 million related to the tax benefit from the exercise of stock options.           Cash flows from investing         Net cash used in investing activities was $46.5 million for the year ended December 31, 2005, compared to $54.4 million for the year ended December 31, 2004. This $7.9 million decrease in net cash used in investing activities was principally due to a reduction in purchases of short-term investments of $10.1 million and a decrease in purchases of property and equipment of $0.4 million, offset by the purchase of two businesses for $2.5 million.           Cash flows from financing         Net cash used in financing activities was $6.2 million for the year ended December 31, 2005, compared to $51.5 million for the year ended December 31, 2004. This $45.3 million decrease in net cash used in financing activities was principally the result of the following: a decrease of $24.1 million in the payment of preferred stock dividends, and a $5.6 million increase in proceeds received from the exercise of common stock options; a decrease of $10.4 million for required letters of credit relating to our December 2003 contract amendments with North American Portability Management LLC; and a decrease of $6.0 million in repayments of notes payable and capital leases, offset by a decrease of $2.2 million in proceeds from the issuance of notes payable.   Contractual Obligations        Our principal commitments consist of obligations under leases for office space, computer equipment and furniture and fixtures. The following table summarizes our long-term contractual obligations as of December 31, 2005.   Payments Due by Period                                                         Less Than           More Than       Total   1 Year   1-3 Years   4-5 Years   5 Years                               (In thousands)         Capital lease obligations    $ 9,923     $ 6,346     $ 3,577     $ —     $ —           Operating lease obligations      21,373     $ 4,765     $ 12,729     $ 3,879     $ —           Long-term debt      2,251     $ 1,232     $ 1,019     $ —     $ —                                             Total    $ 33,547     $ 12,343     $ 17,325     $ 3,879     $ —                                         Debt and Credit Facilities        We have a revolving credit facility, which provides us with up to $15 million in available credit. Borrowings under the revolving credit facility may be either base rate loans or Eurodollar rate loans. There were no outstanding borrowings under this facility at December 31, 2004 and December 31, 2005; however, total available borrowings were reduced by outstanding letters of credit of $1.8 million and $10.7 million at December 31, 2004 and December 31, 2005, respectively, which reduce the amount we may borrow under the revolving credit facility. Base rate loans bear interest at a fluctuating rate per annum equal to the higher of the federal funds rate plus 0.5% or the lender’s prime rate. Eurodollar rate loans bear interest at the Eurodollar  42       rate plus the applicable margin. Our obligations under the revolving credit facility are secured by all of our assets (other than the assets of NeuLevel, Inc., our subsidiary, and the receivables securing our obligations under our receivables facility) and our interest in NeuLevel.        Under the terms of the revolving credit facility, we must comply with certain financial covenants, such as maintaining minimum levels of consolidated net worth, quarterly consolidated EBITDA and liquid assets and not exceeding certain levels of capital expenditures and leverage ratios. Additionally, there are negative covenants that limit our ability to declare or pay dividends, acquire additional indebtedness, incur liens, dispose of significant assets, make acquisitions or significantly change the nature of our business without the permission of the lender. During 2003, 2004 and 2005, we were not in compliance with certain covenants and obtained waivers for such defaults.        We also have a receivables facility under which we borrowed $10.1 million, secured by, and payable from the proceeds of, certain receivables. An independent third party administers the collections of these receivables. As the receivables are collected, the third party pays the bank directly for all secured amounts on a monthly basis, thereby reducing the amounts outstanding under the facility. Minimum payments of $1 million against principal have been due every six months since January 2004, and all amounts outstanding are due February 1, 2007. We have guaranteed a portion of the receivables facility (less than 10% of the outstanding principal balance) but are otherwise not liable for the collection of amounts owed under the secured receivables. The receivables facility bears interest at the reserve adjusted one month LIBOR rate plus 2%.   Effect of Inflation        Inflation generally affects us by increasing our cost of labor and equipment. We do not believe that inflation had any material effect on our results of operations during the years ended December 31, 2003, 2004 and 2005.   Recent Accounting Pronouncements        On December 16, 2004, and as amended on April 14, 2005, the FASB issued Statement No. 123 (revised 2004), Share-Based Payment (SFAS No. 123(R)), which is a revision of FASB Statement No. 123, Accounting for Stock-Based Compensation. SFAS No. 123(R) supersedes APB Opinion No. 25, Accounting for Stock Issued to Employees, and amends FASB Statement No. 95, Statement of Cash Flows. Generally, the approach in SFAS No. 123(R) is similar to the approach described in SFAS No. 123. However, SFAS No. 123(R) requires all share-based payments to employees, including grants of employee stock options, to be recognized in the statement of operations based on their fair values. Pro forma disclosure is no longer an alternative. As permitted by SFAS No. 123, in 2005 and in prior years, we accounted for share-based payments to employees using the intrinsic value method of APB Opinion No. 25 and, as such, generally did not recognize compensation cost for employee stock options.        We will adopt the provisions of SFAS No. 123(R) for the fiscal quarter beginning on January 1, 2006 using the modified prospective transition method and therefore will not restate prior periods. Application of this pronouncement requires us to make significant judgments regarding the variables in an option pricing model in order to determine fair value, including stock price volatility and employee exercise behavior. Most of these variables are either highly dependent on the economic environment at the date of grant or over the expected term of the award. We are currently evaluating the requirements of SFAS No. 123(R) and expect that the adoption of SFAS No. 123(R) will have a material impact on our consolidated results of operations. Had we adopted SFAS No. 123(R) in prior periods, the impact of that standard would have approximated the impact of SFAS No. 123 as described in the disclosure of pro forma net income and earnings per share in Note 2 to our Consolidated Financial Statements. SFAS No. 123(R) also requires the benefits of tax deductions in excess of recognized compensation cost to be reported as a financing cash flow, rather than as an operating cash flow as required under current accounting guidance. This requirement will reduce net operating cash flows and increase net financing cash flows in periods after adoption. While we cannot estimate what those amounts will be in the future (because they depend on, among other things, when employees exercise  43       stock options), the amount of operating cash flows recognized in prior periods for such excess tax deductions was approximately $0, $0 and $17.0 million in 2003, 2004 and 2005, respectively.   Off-Balance Sheet Arrangements        We had no off-balance sheet arrangements as of December 31, 2004 and 2005.             ITEM 7A.  QUANTITATIVE AND QUALITATIVE DISCLOSURES ABOUT MARKET     RISK.         We are subject to market risk associated with changes in foreign currency exchange rates and interest rates. Our exchange rate risk related to foreign currency exchange is due to our number portability contract with Canadian LNP Consortium, Inc. Based on this agreement, we recognize revenue on a per transaction basis as the services are performed and bill for these services using the Canadian dollar at a fixed exchange rate that is updated annually. As a result, we are affected by currency fluctuations in the value of the U.S. dollar as compared to the Canadian dollar. The net impact of foreign exchange rate fluctuations on earnings was not material for the years ended December 31, 2003, 2004 or 2005, respectively.        Interest rate exposure is primarily limited to the approximately $75.9 million of short-term investments owned by us at December 31, 2005. Such investments consist principally of commercial paper, high-grade auction rate securities and U.S. government or corporate debt securities. We do not actively manage the risk of interest rate fluctuations on our short-term investments; however, such risk is mitigated by the relatively short-term nature of these investments. For the year ended December 31, 2005, a one-percentage point adverse change in interest rates would have reduced our interest income for the year ended December 31, 2005 by approximately $650,000. In addition, we do not consider the present rate of inflation to have a material impact on our business.  44                ITEM 8.  FINANCIAL STATEMENTS AND SUPPLEMENTARY DATA.    INDEX TO CONSOLIDATED FINANCIAL STATEMENTS                     Page                  Report of Independent Registered Public     Accounting Firm      46            Consolidated Balance Sheets as of     December 31, 2004 and 2005      47            Consolidated Statements of Operations for     the years ended December 31, 2003, 2004 and 2005      49            Consolidated Statements of     Stockholders’ (Deficit) Equity for the years ended     December 31, 2003, 2004 and 2005      50            Consolidated Statements of Cash Flows for     the years ended December 31, 2003, 2004 and 2005      51            Notes to Consolidated Financial     Statements      52      45           REPORT OF INDEPENDENT REGISTERED PUBLIC ACCOUNTING FIRM   Board of Directors and Stockholders   NeuStar, Inc.        We have audited the accompanying consolidated balance sheets of NeuStar, Inc. as of December 31, 2004 and 2005, and the related consolidated statements of operations, stockholders’ (deficit) equity, and cash flows for each of the three years in the period ended December 31, 2005. Our audits also included the financial statement schedule listed in the Index at Item 15(a)(2). These financial statements and schedule are the responsibility of the Company’s management. Our responsibility is to express an opinion on these financial statements and schedule based on our audits.        We conducted our audits in accordance with the standards of the Public Company Accounting Oversight Board (United States). Those standards require that we plan and perform the audit to obtain reasonable assurance about whether the financial statements are free of material misstatement. We were not engaged to perform an audit of the Company’s internal control over financial reporting. Our audits included consideration of internal control over financial reporting as a basis for designing audit procedures that are appropriate in the circumstances, but not for the purpose of expressing an opinion on the effectiveness of the Company’s internal control over financial reporting. Accordingly, we express no such opinion. An audit includes examining, on a test basis, evidence supporting the amounts and disclosures in the financial statements, assessing the accounting principles used and significant estimates made by management, and evaluating the overall financial statement presentation. We believe that our audits provide a reasonable basis for our opinion.        In our opinion, the financial statements referred to above present fairly, in all material respects, the consolidated financial position of NeuStar, Inc. at December 31, 2004 and 2005, and the consolidated results of its operations and its cash flows for each of the three years in the period ended December 31, 2005, in conformity with U.S. generally accepted accounting principles. Also, in our opinion, the related financial statement schedule, when considered in relation to the basic financial statements taken as a whole, present fairly in all material respects the information set forth therein.                /s/ Ernst & Young LLP    McLean, Virginia   March 10, 2006  46      NEUSTAR, INC.       CONSOLIDATED BALANCE SHEETS   (In thousands, except share and per share data)                               December 31,               2004   2005                ASSETS         Current assets:                            Cash and cash equivalents    $ 19,019     $ 27,529             Restricted cash      4,835       374             Short-term investments      44,910       75,946             Accounts receivable, net of allowance for doubtful accounts of     $468 and $494, respectively      29,171       30,982             Unbilled receivables      980       6,394             Securitized notes receivable      3,325       1,074             Notes receivable      965       —             Prepaid expenses and other current assets      3,747       8,054             Deferred costs      2,359       4,819             Income taxes receivable      —       14,595             Deferred tax asset      10,923       12,216                           Total current assets      120,234       181,983           Restricted cash, long-term      835       —           Property and equipment, net      36,504       39,627           Goodwill      49,453       51,495           Intangibles assets, net      1,250       2,655           Securitized notes receivable, long-term      1,074       —           Deferred costs, long-term      2,012       5,454           Other assets      961       557                           Total assets    $ 212,323     $ 281,771                        See accompanying notes.  47       NEUSTAR, INC.   CONSOLIDATED BALANCE SHEETS   (In thousands, except share and per share data)                               December 31,               2004   2005                LIABILITIES AND STOCKHOLDERS’ (DEFICIT) EQUITY         Current liabilities:                            Accounts payable    $ 2,828     $ 4,119             Accrued expenses      32,630       36,880             Income taxes payable      419       —             Customer credits      15,541       —             Deferred revenue      14,761       20,006             Notes payable      4,636       1,232             Capital lease obligations      4,813       5,540             Accrued restructuring reserve      1,330       536                           Total current liabilities      76,958       68,313           Deferred revenue, long-term      13,892       18,463           Notes payable, long-term      1,358       1,019           Capital lease obligations, long-term      6,606       3,440           Accrued restructuring reserve, long-term      3,719       2,572           Other liabilities      —       500           Deferred tax liability      1,194       1,197                           Total liabilities      103,727       95,504           Minority interest      —       104           Commitments and contingencies      —       —           Series B Voting Convertible Preferred Stock, $0.01 par     value; 4,000,000 shares authorized; 100,000 shares     issued and outstanding at December 31, 2004; liquidation     preference of $66 at December 31, 2004      66       —           Series C Voting Convertible Preferred Stock, $0.01 par     value; 28,600,000 shares authorized; 28,569,692 shares     issued and outstanding at December 31, 2004; liquidation     preference of $85,717 at December 31, 2004      85,717       —           Series D Voting Convertible Preferred Stock, $0.01 par     value; 10,000,000 shares authorized; 9,098,525 shares     issued and outstanding at December 31, 2004; liquidation     preference of $54,817 at December 31, 2004      54,671       —           Stockholders’ (deficit) equity:                            Preferred stock, $0.001 par value; 100,000,000 shares     authorized; No shares issued or outstanding as of     December 31, 2004 and 2005      —       —             Class A common stock, $0.001 par value;     200,000,000 shares authorized; No shares issued or     outstanding as of December 31, 2004; 68,150,690 shares     issued and outstanding as of December 31, 2005      —       68             Class B common stock, $0.001 par value;     100,000,000 shares authorized; 6,159,985 and     199,152 shares issued and outstanding as of     December 31, 2004 and 2005, respectively      6       —             Additional paid-in capital      —       163,741             Deferred stock compensation      (1,733 )     (1,446 )           Treasury stock, 236,366 shares at cost at December 31,     2004      (1,125 )     —             (Accumulated deficit) retained earnings      (29,006 )     23,800                           Total stockholders’ (deficit) equity      (31,858 )     186,163                           Total liabilities and stockholders’ (deficit) equity    $ 212,323     $ 281,771                        See accompanying notes.  48      NEUSTAR, INC.       CONSOLIDATED STATEMENTS OF OPERATIONS   (In thousands, except per share data)                                       Year Ended December 31,               2003   2004   2005                         Revenue:                                    Addressing    $ 42,905     $ 50,792     $ 75,036             Interoperability      16,003       34,228       52,488             Infrastructure and other      52,785       79,981       114,945                                 Total revenue      111,693       165,001       242,469           Operating expense:                                    Cost of revenue (excluding depreciation and amortization shown     separately below)      37,846       49,261       64,891             Sales and marketing      14,381       22,743       29,543             Research and development      6,678       7,377       11,883             General and administrative      11,359       21,144       28,048             Depreciation and amortization      16,051       17,285       16,025             Restructuring recoveries      (1,296 )     (220 )     (389 )                               85,019       117,590       150,001                                 Income from operations      26,674       47,411       92,468           Other (expense) income:                                    Interest expense      (3,119 )     (2,498 )     (2,121 )           Interest income      1,299       1,629       2,406                                 Income before minority interest and income taxes      24,854       46,542       92,753           Minority interest      10       —       (104 )                               Income before income taxes      24,864       46,542       92,649           Provision for income taxes      836       1,166       37,251                                 Net income      24,028       45,376       55,398           Dividends on and accretion of preferred stock      (9,583 )     (9,737 )     (4,313 )                               Net income attributable to common stockholders    $ 14,445     $ 35,639     $ 51,085                                 Net income attributable to common stockholders:                                    Basic    $ 3.09     $ 6.33     $ 1.48                                   Diluted    $ 0.31     $ 0.57     $ 0.72                                 Weighted average common shares outstanding:                                    Basic      4,680       5,632       34,437                                   Diluted      76,520       80,237       77,046                             See accompanying notes.  49       NEUSTAR, INC.       CONSOLIDATED STATEMENT OF STOCKHOLDERS’ (DEFICIT) EQUITY   (In thousands)                                                                                               Class A   Class B                   (Accumulated   Total       Common Stock   Common Stock   Additional   Common Stock   Deferred       Deficit)   Stockholders’               Paid-In   Subscription   Stock   Treasury   Retained   (Deficit)       Shares   Amount   Shares   Amount   Capital   Receivable   Compensation   Stock   Earnings   Equity                                                     Balance at December 31, 2002      —     $ —       4,447     $ 4     $ —     $ (155 )   $ (44 )   $ —     $ (87,105 )   $ (87,300 )           Shares issued for acquisition of NightFire Software, Inc.       —       —       882       1       3,776       —       —       —       —       3,777             Common stock options exercised      —       —       220       —       39       —       —       —       —       39             Repayment of executive promissory notes      —       —       —       —       —       155       —       —       —       155             Compensation expense associated with options issued to     nonemployees      —       —       —       —       287       —       —       —       —       287             Amortization of deferred stock compensation      —       —       —       —       —       —       16       —       —       16             Accretion of preferred stock and related dividends      —       —       —       —       (4,102 )     —       —       —       (5,481 )     (9,583 )           Net income      —       —       —       —       —       —       —       —       24,028       24,028                                                                           Balance at December 31, 2003      —       —       5,549       5       —       —       (28 )     —       (68,558 )     (68,581 )           Common stock options exercised      —       —       611       1       90       —       —       —       —       91             Deferred stock compensation expense associated with issuance of     restricted stock units      —       —       —       —       2,187       —       (2,187 )     —       —       —             Repurchase of common stock      —       —       —       —       —       —       —       (1,012 )     —       (1,012 )           Return of common stock originally issued for acquisition of     NightFire Software, Inc      —       —       —       —       —       —       —       (113 )     —       (113 )           Compensation expense associated with options issued to     nonemployees      —       —       —       —       654       —       —       —       —       654             Compensation expense associated with repurchase of immature     shares      —       —       —       —       982       —       —       —       —       982             Accretion of preferred stock and related dividends      —       —       —       —       (3,913 )     —       —       —       (5,824 )     (9,737 )           Amortization of deferred stock compensation      —       —       —       —       —       —       482       —       —       482             Net income      —       —       —       —       —       —       —       —       45,376       45,376                                                                           Balance at December 31, 2004      —       —       6,160       6       —       —       (1,733 )     (1,125 )     (29,006 )     (31,858 )           Common stock options exercised      —       —       466       1       246       —       —       —       —       247             Compensation expense associated with options issued to     nonemployees      —       —       —       —       2,214       —       —       —       —       2,214             Shares issued for acquisition of fiducianet, Inc.       —       —       36       —       388       —       —       —       —       388             Retirement of treasury stock      —       —       (236 )     —       (1,125 )     —       —       1,125       —       —             Accretion of preferred stock and related dividends      —       —       —       —       (1,721 )     —       —       —       (2,592 )     (4,313 )           Issuance of Class B common stock pursuant to conversion of     convertible preferred stock      —       —       53,435       53       138,452       —       —       —       —       138,505             Conversion of Class B common stock to Class A common     stock      59,662       60       (59,662 )     (60 )     —       —       —       —       —       —             Deferred stock compensation expense associated with issuance of     restricted stock      5       —       —       —       160       —       (160 )     —       —       —             Amortization of deferred stock compensation      —       —       —       —       —       —       447       —       —       447             Common stock options exercised      2,122       2       —       —       7,709       —       —       —       —       7,711             Warrants exercised      6,362       6       —       —       418       —       —       —       —       424             Tax benefit from stock option exercises      —       —       —       —       17,000       —       —       —       —       17,000             Net income      —       —       —       —       —       —       —       —       55,398       55,398                                                                           Balance at December 31, 2005      68,151     $ 68       199     $ —     $ 163,741     $ —     $ (1,446 )   $ —     $ 23,800     $ 186,163                                                                       See accompanying notes.  50      NEUSTAR, INC.       CONSOLIDATED STATEMENTS OF CASH FLOWS   (In thousands)                                       Year Ended December 31,               2003   2004   2005                         Operating activities:                                  Net income    $ 24,028     $ 45,376     $ 55,398           Adjustments to reconcile net income to net cash provided by     operating activities:                                    Depreciation and amortization      16,051       17,285       16,025             Stock compensation      303       2,118       2,661             Amortization of deferred financing costs      533       150       57             Tax benefit from stock option exercises      —       —       17,000             Deferred income taxes      —       (6,419 )     (2,289 )           Noncash restructuring recoveries      (1,295 )     (220 )     (389 )           Provision for doubtful accounts      184       960       551             Minority interest      —       —       104           Changes in operating assets and liabilities, net of acquisitions:                                    Accounts receivable      (10,396 )     (7,697 )     (3,810 )           Unbilled receivables      4,726       139       (5,414 )           Notes receivable      2,753       4,938       4,290             Prepaid expenses and other current assets      (32 )     (1,524 )     (1,570 )           Deferred costs      (2,633 )     (869 )     (5,902 )           Income tax receivable      —       —       (14,595 )           Other assets      (257 )     (102 )     658             Accounts payable and accrued expenses      8,628       11,119       6,396             Income taxes payable      375       44       (419 )           Accrued restructuring reserve      (3,507 )     (386 )     (1,551 )           Customer credits      21,000       (5,459 )     (15,541 )           Deferred revenue      12,426       5,279       9,542                                   Net cash provided by operating activities      72,887       64,732       61,202           Investing activities:                                    Purchases of property and equipment      (8,186 )     (13,271 )     (12,890 )           Sales (purchases) of investments, net      1,845       (41,155 )     (31,036 )           Businesses acquired, net of cash acquired      (8,089 )     —       (2,540 )                                 Net cash used in investing activities      (14,430 )     (54,426 )     (46,466 )         Financing activities:                                    Disbursement (release) of restricted cash      493       (5,112 )     5,296             Proceeds from issuance of notes payable      12,037       2,166       —             Principal repayments on notes payable      (16,104 )     (9,823 )     (5,406 )           Principal repayments on capital lease obligations      (10,342 )     (7,505 )     (5,939 )           Proceeds from exercise of common stock options      39       91       5,661             Proceeds from exercise of warrants      —       —       424             Payment of preferred stock dividends      —       (30,324 )     (6,262 )           Repayment of common stock subscriptions      155       —       —             Repurchase of common stock      —       (1,012 )     —             Payment of deferred financing fees      (250 )     —       —                                   Net cash used in financing activities      (13,972 )     (51,519 )     (6,226 )                               Net increase (decrease) in cash and cash equivalents      44,485       (41,213 )     8,510           Cash and cash equivalents at beginning of year      15,747       60,232       19,019                                 Cash and cash equivalents at end of year    $ 60,232     $ 19,019     $ 27,529                                 Supplemental cash flow information:                                    Cash paid for interest    $ 1,673     $ 1,693     $ 1,377                                   Cash paid for income taxes    $ 836     $ 7,291     $ 37,583                             See accompanying notes.  51       NEUSTAR, INC.       NOTES TO CONSOLIDATED FINANCIAL STATEMENTS         1.  DESCRIPTION OF BUSINESS AND ORGANIZATION         NeuStar, Inc. (the Company) was incorporated as a Delaware corporation in 1998. The Company provides the North American communications industry with essential clearinghouse services. The Company operates the authoritative directories that manage virtually all telephone area codes and numbers, and enable the dynamic routing of calls among thousands of competing communication service providers, or CSPs, in the United States and Canada. The Company also provides clearinghouse services to emerging CSPs, including Internet service providers, cable television operators, and voice over Internet protocol, or VoIP, service providers. In addition, the Company manages the authoritative directories for the .us and .biz Internet domains, as well as for U.S. Common Short Codes, part of the short messaging service, or SMS, relied on by the U.S. wireless industry.        The Company provides its services from its clearinghouse, which includes unique databases and systems for workflow and transaction processing. These services are used by CSPs to solve a range of their technical and operating requirements, including:            •   Addressing. The Company enables CSPs to use critical,     shared addressing resources, such as telephone numbers, several     Internet domain names, and U.S. Common Short Codes.         •   Interoperability. The Company enables CSPs to exchange     and share critical operating data so that communications     originating on one provider’s network can be delivered and     received on the network of another CSP. The Company also     facilitates order management and work flow processing among CSPs.         •   Infrastructure and Other. The Company enables CSPs to     more efficiently manage changes in their own networks by     centrally managing certain critical data they use to route     communications over their own networks.         On June 28, 2005, the Company effected a recapitalization, which involved (i) the payment of $6.3 million for all accrued and unpaid dividends on all of the then-outstanding shares of preferred stock, followed by the conversion of such shares into shares of common stock, (ii) the amendment of the Company’s certificate of incorporation to provide for Class A common stock and Class B common stock, (iii) and the split of each share of common stock into 1.4 shares and the reclassification of the common stock into shares of Class B common stock (collectively, the “Recapitalization”). Each share of Class B common stock is convertible at the option of the holder into one share of Class A common stock.        On June 28, 2005, the Company made an initial public offering of 31,625,000 shares of Class A common stock, which included the underwriters’ over-allotment option exercise of 4,125,000 shares of Class A common stock. All the shares of Class A common stock sold in the initial public offering were sold by selling stockholders and, as such, the Company did not receive any proceeds from that offering. Prior to the Company’s initial public offering, holders of 100,000 shares of Series B Voting Convertible Preferred Stock, 28,569,692 shares of Series C Voting Convertible Preferred Stock, and 9,098,525 shares of Series D Voting Convertible Preferred Stock converted their shares into 500,000, 28,569,692, and 9,098,525 shares of the Company’s common stock, respectively, after which the split by means of a reclassification, as described in clauses (ii) and (iii) of the previous paragraph, was effected.        The accompanying consolidated financial statements give retroactive effect to the amendment of the Company’s certificate of incorporation to provide for Class A common stock and Class B common stock and the split of each share of common stock into 1.4 shares and the reclassification of the common stock into shares of Class B common stock, as though these events occurred at the beginning of the earliest period presented.  52       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)         2.  SUMMARY OF SIGNIFICANT ACCOUNTING POLICIES    Basis of Presentation and Consolidation        The consolidated financial statements include the accounts of the Company and its majority-owned subsidiaries. All material intercompany transactions and accounts have been eliminated in consolidation. The Company consolidates investments where it has a controlling financial interest as defined by Accounting Research Bulletin (ARB) No. 51, Consolidated Financial Statements, as amended by Statement of Financial Accounting Standards (SFAS) No. 94, Consolidation of all Majority-Owned Subsidiaries. The usual condition for controlling financial interest is ownership of a majority of the voting interest and, therefore, as a general rule ownership, directly or indirectly, of more than 50% of the outstanding voting shares is a condition indicating consolidation. Minority interest is recorded in the statement of operations for the share of losses absorbed by minority shareholders to the extent that the minority shareholder’s investment in the subsidiary does not fall below zero. For investments in variable interest entities, as defined by Financial Accounting Standards Board (FASB) Interpretation No. 46, Consolidation of Variable Interest Entities, the Company would consolidate when it is determined to be the primary beneficiary of a variable interest entity. For those investments in entities where the Company has significant influence over operations, but where the Company neither has a controlling financial interest nor is the primary beneficiary of a variable interest entity, the Company follows the equity method of accounting pursuant to Accounting Principles Board (APB) Opinion No. 18, The Equity Method of Accounting for Investments in Common Stock. The Company does not have any variable interest entities or investments accounted for under the equity method of accounting.   Use of Estimates        The preparation of financial statements in conformity with U.S. generally accepted accounting principles requires management to make estimates and assumptions that affect the reported amounts of assets and liabilities, the disclosure of contingent assets and liabilities at the date of the financial statements and the reported amounts of revenue and expense during the reporting periods. Actual results could differ from those estimates.   Reclassifications        Certain amounts in the prior years’ financial statements have been reclassified to conform to the current year presentation.   Fair Value of Financial Instruments        SFAS No. 107, Disclosures about Fair Value of Financial Instruments, requires disclosures of fair value information about financial instruments, whether or not recognized in the balance sheet, for which it is practicable to estimate that value. Due to their short-term nature, the carrying amounts reported in the consolidated financial statements approximate the fair value for cash and cash equivalents, accounts receivable, accounts payable and accrued expenses. As of December 31, 2004 and 2005, the Company believes the carrying value of its long-term notes receivable approximates fair value as the interest rates approximate a market rate. The fair value of the Company’s long-term debt is based upon quoted market prices for the same and similar issuances giving consideration to quality, interest rates, maturity and other characteristics. As of December 31, 2004 and 2005, the Company believes the carrying amount of its long-term debt approximates its fair value since the fixed and variable interest rates of the debt approximate a market rate.  53       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   Cash and Cash Equivalents        The Company considers all highly liquid investments, which are readily convertible into cash and have original maturities of three months or less at the time of purchase, to be cash equivalents. Supplemental non-cash information to the consolidated statements of cash flows is as follows:                                     Year Ended December 31,               2003   2004   2005                       (In thousands)         Fixed assets acquired through capital leases    $ 7,433     $ 8,054     $ 3,470           Fixed assets acquired through notes payable      1,154       1,359       1,002           Accounts payable incurred to purchase fixed assets      1,539       125       79           Business acquired with common shares (see Note 3)      3,777       (113 )     388           Dividends to preferred stockholders      9,334       2,095       —       Restricted Cash        At December 31, 2004 and 2005, approximately $5.7 million and $374,000, respectively, of cash was pledged as collateral on outstanding letters of credit related to 2003 customer credits and lease obligations and was classified as restricted cash on the consolidated balance sheets.   Derivatives and Hedging Activities        The Company recognizes all derivative financial instruments in the consolidated financial statements at fair value regardless of the purpose or intent for holding the instrument, in accordance with SFAS No. 133, Accounting for Derivative Instruments and Hedging Activities, as amended. Changes in the fair value of derivative financial instruments are either recognized periodically in the results of operations or in stockholders’ (deficit) equity as a component of other comprehensive income, depending on whether the derivative financial instrument qualifies for hedge accounting and, if so, whether it qualifies as a fair value hedge or cash flow hedge. Generally, changes in the fair value of the derivatives accounted for as fair value hedges are recorded in the results of operations along with the portions of the changes in the fair values of the hedged items that relate to the hedged risks. Changes in fair value of derivatives accounted for as cash flow hedges, to the extent they are effective as hedges, are recorded in other comprehensive income. Changes in fair values of derivatives not qualifying as hedges are reported in the results of operations.        In October 2003, the Company entered into an interest rate swap agreement to manage our interest rate exposure under our 2003 Receivables Facility (see Note 9). The interest rate swap does not meet the criteria under SFAS No. 133 to qualify for hedge accounting treatment. Accordingly, changes in the fair value of the instrument are recorded in earnings. The fair value of the interest rate swap was not significant at December 31, 2004 and 2005.   Concentrations of Credit Risk        Financial instruments that are potentially subject to a concentration of credit risk consist principally of cash equivalents and accounts receivable. Cash investment policies are in place that restrict placement of these instruments to financial institutions evaluated as highly creditworthy.        With respect to accounts receivable, the Company performs ongoing evaluations of its customers, generally granting uncollateralized credit terms to its customers, and maintains an allowance for doubtful accounts based on historical experience and management’s expectations of future losses. Customers under the Company’s contracts with North American Portability Management LLC are charged a Revenue Recovery  54       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   Collection fee (See Accounts Receivable, Revenue Recovery Collection and Allowance for Doubtful Accounts).   Short-term Investments        Investments in debt and equity securities that have readily determinable fair values are accounted for as available-for-sale securities. Available-for-sale securities are stated at fair value as determined by the most recently traded price of each security at the balance sheet date, with the unrealized gains and losses recorded as a component of other comprehensive income. The specific-identification method is used to compute the realized gains and losses on debt and equity securities. As of December 31, 2004 and 2005, the carrying value of the investments approximated their fair value and there were no unrealized gains or losses. As of December 31, 2004 and 2005, these investments consisted principally of commercial paper, high-grade auction rate securities and U.S. government or corporate debt securities.   Accounts Receivable, Revenue Recovery Collections and Allowance for Doubtful Accounts        Accounts receivable are recorded at the invoiced amount and do not bear interest. In accordance with the Company’s contracts with North American Portability Management LLC, the Company bills a Revenue Recovery Collections (RRC) fee to offset uncollectible receivables from any individual customer. The RRC fee is based on a percentage of monthly billings. From January 1, 2003 through June 30, 2004, the RRC fee was 3%. On July 1, 2004, the RRC fee was reduced to 2%. On July 1, 2005, the RRC fee was reduced to 1%. The RRC fees are recorded as an accrued liability when collected. If the RRC fee is insufficient the amounts can be recovered from the customers. Any accrued RRC fees in excess of uncollectible receivables are paid back to the customers annually on a pro rata basis. RRC fees of $4.3 million and $2.5 million are included in accrued expenses as of December 31, 2004 and 2005, respectively. All other receivables related to services not covered by the RRC fees are evaluated and, if deemed not collectible, are reserved. The Company recorded an allowance for doubtful accounts of $468,000 and $494,000 as of December 31, 2004 and 2005, respectively. Bad debt expense amounted to $184,000, $960,000 and $551,000 for the years ended December 31, 2003, 2004 and 2005, respectively.   Deferred Financing Costs        The Company amortizes deferred financing costs using the effective-interest method and records such amortization as interest expense. Amortization of debt discount and annual commitment fees for unused portions of available borrowings are also recorded as interest expense.   Property and Equipment        Property and equipment, including leasehold improvements and assets acquired through capital leases, are recorded at cost, net of accumulated depreciation and amortization. Depreciation and amortization of property and equipment are determined using the straight-line method over the estimated useful lives of the assets, as follows:                   Computer hardware         3-5 years         Equipment         5 years         Furniture and fixtures         5-7 years         Leasehold improvements         Lesser of related lease term or useful life          Amortization expense of capital leased assets is included in depreciation and amortization expense in the consolidated statements of operations. Replacements and major improvements are capitalized; maintenance and repairs are charged to expense as incurred.  55       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)        The Company capitalizes software development and acquisition costs in accordance with Statement of Position (SOP) No. 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use. SOP No. 98-1 requires the capitalization of costs incurred in connection with developing or obtaining software for internal use. Costs incurred to develop the application are capitalized, while costs incurred for planning the project and for post-implementation training and maintenance are expensed as incurred. The capitalized costs of purchased technology and software development are amortized using the straight-line method over the estimated useful life of three to five years. During the years ended December 31, 2004 and 2005, the Company capitalized costs related to internal use software of $9.1 million and $8.2 million, respectively. Amortization expense related to internal use software for the years ended December 31, 2003, 2004 and 2005 was $5.3 million, $5.5 million and $3.7 million, respectively and is included in depreciation and amortization expense in the consolidated statements of operations.   Goodwill        Goodwill represents the excess of costs over fair value of assets of businesses acquired. Goodwill and intangible assets that are determined to have an indefinite useful life are not amortized, but instead tested for impairment annually in accordance with the provisions of SFAS No. 142, Goodwill and Other Intangible Assets.        The Company performs its annual impairment analysis on October 1 of each year or more often if indicators of impairment arise. The impairment review may require an analysis of future projections and assumptions about the Company’s operating performance. If such a review indicates that the assets are impaired, an expense would be recorded for the amount of the impairment, and the corresponding impaired assets would be reduced in carrying value. The Company performed its annual impairment test with regard to the carrying value of goodwill on October 1, 2004 and 2005 and determined that goodwill was not impaired at those dates.   Identifiable Intangible Assets        Identifiable intangible assets are amortized over their respective estimated useful lives using a method of amortization that reflects the pattern in which the economic benefits of the intangible assets are consumed or otherwise used up and are reviewed for impairment in accordance with SFAS No. 144, Accounting for Impairment or Disposal of Long-Lived Assets.        The Company’s identifiable intangible assets are amortized as follows:                             Years   Method                     Acquired technologies      4       Straight-line           Customer lists      3 to 5       Various            Amortization expense related to acquired technologies and customer lists are included in depreciation and amortization expense in the consolidated statements of operations.   Impairment of Long-Lived Assets        In accordance with SFAS No. 144, Accounting for the Impairment or Disposal of Long-Lived Assets, a review of long-lived assets for impairment is performed when events or changes in circumstances indicate the carrying value of such assets may not be recoverable. If an indication of impairment is present, the Company compares the estimated undiscounted future cash flows to be generated by the asset to its carrying amount. If the undiscounted future cash flows are less than the carrying amount of the asset, the Company records an impairment loss equal to the excess of the asset’s carrying amount over its fair value. The fair value is determined based on valuation techniques such as a comparison to fair values of similar assets or using a  56       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   discounted cash flow analysis. There were no impairment charges recognized during the years ended December 31, 2003, 2004 or 2005.   Revenue Recognition        The Company provides the North American communications industry with essential clearinghouse services that address the industry’s addressing, interoperability, and infrastructure needs. The Company’s revenue recognition policies are in accordance with the Securities and Exchange Commission Staff Accounting Bulletin No. 104, Revenue Recognition.        The Company provides the following services pursuant to various private commercial and government contracts.           Addressing         The Company’s addressing services include telephone number administration, implementing the allocation of pooled blocks of telephone numbers, and directory services for Internet domain names and U.S. Common Short Codes. The Company generates revenue from its telephone number administration services under two government contracts. Under its contract to serve as the North American Numbering Plan Administrator, the Company earns a fixed annual fee and recognizes this fee as revenue on a straight-line basis as services are provided. In the event the Company estimates losses on its fixed fee contract, the Company recognizes these losses in the period in which a loss becomes apparent. Under the Company’s contract to serve as the National Pooling Administrator, the Company is reimbursed for costs incurred plus a fixed fee associated with administration of the pooling system. The Company recognizes revenue for this contract based on costs incurred plus a pro rata amount of the fixed fee.        In addition to the administrative functions associated with its role as the National Pooling Administrator, the Company also generates revenue from implementing the allocation of pooled blocks of telephone numbers under our long-term contracts with North American Portability Management LLC, and the Company recognizes revenue on a per transaction fee basis as the services are performed. For its Internet domain name services, the Company generates revenue for Internet domain registrations, which generally have contract terms between one and ten years. The Company recognizes revenue on a straight-line basis over the lives of the related customer contracts. The Company generates revenue from its Common Short Code services under short-term contracts ranging from three to twelve months, and the Company recognizes revenue on a straight-line basis over the term of the customer contracts.           Interoperability         The Company’s interoperability services consist primarily of wireline and wireless number portability and order management services. The Company generates revenue from number portability under its long-term contracts with North American Portability Management LLC and Canadian LNP Consortium, Inc. The Company recognizes revenue on a per transaction fee basis as the services are performed. The Company provides order management services (OMS), consisting of customer set-up and implementation followed by transaction processing, under contracts with terms ranging from one to three years. Customer set-up and implementation is not considered a separate deliverable; accordingly, the fees are deferred and recognized as revenue on a straight-line basis over the term of the contract. Per-transaction fees are recognized as the transactions are processed.           Infrastructure and Other         The Company’s infrastructure services consist primarily of network management and connection fees. The Company generates revenue from network management services under its long-term contracts with  57       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   North American Portability Management LLC. The Company recognizes revenue on a per transaction fee basis as the services are performed. In addition, the Company generates revenue from connection fees and system enhancements under its contracts with North American Portability Management LLC. The Company recognizes its connection fee revenue as the service is performed. System enhancements are provided under contracts in which the Company is reimbursed for costs incurred plus a fixed fee, and revenue is recognized based on costs incurred plus a pro rata amount of the fee.           Significant Contracts         The Company provides wireline and wireless number portability, implements the allocation of pooled blocks of telephone numbers and provides network management services pursuant to seven contracts with North American Portability Management LLC, an industry group that represents all telecommunications service providers in the United States. The Company recognizes revenue under its contracts with North American Portability Management LLC primarily on a per-transaction basis. The aggregate fees for transactions processed under these contracts are determined by the total number of transactions, and these fees are billed to telecommunications service providers based on their allocable share of the total transaction charges. This allocable share is based on each respective telecommunications service provider’s share of the aggregate end-user services revenues of all U.S. telecommunications service providers as determined by the Federal Communications Commission (FCC). Under the Company’s contracts, the Company also bills an RRC fee of a percentage of monthly billings to its customers, which is available to the Company if any telecommunications service provider fails to pay its allocable share of total transactions charges. In the period in which the RRC fees are billed, the RRC fees are recorded as an accrued expense (see Note 8) on the consolidated balance sheet, with a corresponding increase to accounts receivable. If the RRC fee is insufficient for that purpose, these contracts also provide for the recovery of such differences from the remaining telecommunications service providers. On an annual basis, (i) the Company evaluates the RRC fee reserve by comparing cash collections to billings and the RRC percentage is adjusted, and (ii) any excess RRC fee reserve is returned to the telecommunications service providers in accordance with the terms of these contracts.        The per-transaction pricing under these contracts provides for annual volume credits that are earned on all transactions in excess of the pre-determined annual volume threshold. For 2005, the maximum aggregate volume credit was $7.5 million, which was applied via a reduction in per-transaction pricing once the pre-determined annual volume threshold was surpassed. When the aggregate credit was fully satisfied, the per-transaction pricing was restored to the prevailing contractual rate. In August 2005, the pre-determined annual transaction volume threshold under these contracts was exceeded, which resulted in the issuance of $7.5 million of volume credits for the year ended December 31, 2005.        Conversely, billings in 2003 and 2004 continued at the original contractual rate after the annual volume threshold was surpassed. Billings in excess of the discounted pricing were recorded as customer credits (liability) on the consolidated balance sheet with a corresponding reduction to revenue. In the following year when the credits were applied to invoices rendered, customer credits were reduced with a corresponding credit to accounts receivable. The annual pre-determined volume threshold was surpassed in the fourth quarters of 2003 and 2004 resulting in the reduction of revenue and recognition of customer credits of $6.0 million and $11.9 million, respectively.        In December 2003, these contracts were amended to extend their expiration date from May 2006 to May 2011, and the per-transaction fee charged to the Company’s customers over the term of the contracts was reduced. As part of the amendments, the Company agreed to retroactively apply the new transaction fee to all 2003 transactions processed and granted credits totaling $16.0 million. These credits were applied to customer invoices over a 23-month period beginning in January 2004. Additionally, the Company obtained letters of credit totaling $16.0 million in January 2004 to secure these customer credits. As of December 31, 2004,  58       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   approximately $15.5 million of these customer credits were outstanding. As of December 31, 2005, no customer credits were outstanding. The amount of the Company’s revenue derived under its contracts with North American Portability Management LLC was $84.5 million $130.0 million, and $188.8 million for the years ended December 31, 2003, 2004 and 2005, respectively.           Service Level Standards         Pursuant to certain of the Company’s private commercial contracts, the Company is subject to service level standards and to corresponding penalties for failure to meet those standards. The Company records a provision for these performance-related penalties when it becomes aware that required service levels that would trigger such a penalty have not been met, which results in a corresponding reduction to revenue.   Cost of Revenue and Deferred Costs        Cost of revenue includes all direct materials, direct labor, and those indirect costs related to revenue such as indirect labor, materials and supplies and facilities cost.        Deferred costs represent direct labor related to professional services incurred for the setup and implementation on contracts. These costs are recognized in cost of revenue ratably over the contract term. Deferred costs are classified as such on the consolidated balance sheet for the periods presented.   Research and Development        The Company expenses its research and development costs as incurred. Research and development expense consists primarily of personnel costs, including salaries, stock-based compensation and other personnel-related expense; consulting fees; and the costs of facilities, computer and support services used in service and technology development.   Advertising        The Company expenses advertising as incurred. Advertising expense was approximately $1.2 million, $447,000 and $809,000 for the years ended December 31, 2003, 2004 and 2005, respectively.   Accounting for Stock-Based Compensation        SFAS No. 123, Accounting for Stock-Based Compensation, as amended by SFAS No. 148, Accounting for Stock-Based Compensation — Transition and Disclosure, an amendment of SFAS No. 123 (SFAS No. 123), allows companies to account for stock-based compensation using either the provisions of SFAS No. 123 or the provisions of APB Opinion No. 25, Accounting for Stock Issued to Employees, but requires pro forma disclosure in the notes to the financial statements as if the measurement provisions of SFAS No. 123 had been adopted. The Company accounts for its stock-based employee compensation in accordance with APB No. 25. Stock compensation expense to nonemployees has been determined in accordance with SFAS No. 123 and Emerging Issues Task Force (EITF) Issue No. 96-18, Accounting for Equity Instruments that are Issued to Other than Employees for Acquiring, or in Connection with Selling Goods or Services (EITF 96-18) and represents the fair value of the consideration received or the fair value of the equity instrument issued, whichever may be more reliably measured. For options that have not reached a measurement date under EITF 96-18, the fair value of the options granted to nonemployees is remeasured at each reporting date.  59       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)        The following table illustrates the effect on net income attributable to common stockholders and net income attributable to common stockholders per common share if the Company had applied the fair value recognition provisions of SFAS No. 123 to stock-based compensation (in thousands, except per share data):                                       Year Ended December 31,               2003   2004   2005                         Pro forma basic net income attributable to common stockholders:                                    Basic net income attributable to common stockholders, as reported    $ 14,445     $ 35,639     $ 51,085             Add: stock-based compensation expense included in reported net     income attributable to common stockholders      303       2,065       1,607             Deduct: total stock-based compensation expense determined under     fair value-based method for all awards      (2,794 )     (6,707 )     (6,282 )                               Pro forma basic net income attributable to common stockholders    $ 11,954     $ 30,997     $ 46,410                                 Pro forma diluted net income attributable to common stockholders:                                    Basic net income attributable to common stockholders, as reported    $ 14,445     $ 35,639     $ 51,085             Dividends on and accretion of convertible preferred stock      9,583       9,737       4,313                                   Diluted net income attributable to common stockholders      24,028       45,376       55,398             Add: stock-based compensation expense included in reported net     income attributable to common stockholders      303       2,065       1,607             Deduct: total stock-based compensation expense determined under     fair value-based method for all awards      (2,794 )     (6,707 )     (6,282 )                               Pro forma diluted net income attributable to common stockholders    $ 21,537     $ 40,734     $ 50,723                                 Net income attributable to common stockholders per common share:                                  Basic — as reported    $ 3.09     $ 6.33     $ 1.48                                 Basic — pro forma    $ 2.55     $ 5.50     $ 1.35                                 Diluted — as reported    $ 0.31     $ 0.57     $ 0.72                                 Diluted — pro forma    $ 0.28     $ 0.51     $ 0.66                                  The effect of applying SFAS No. 123 on pro forma net income attributable to common stockholders as stated above is not necessarily representative of the effects on reported net income attributable to common stockholders for future years due to, among other things, the vesting period of the stock options and the fair value of additional options to be granted in the future years.        For the purposes of the disclosure required by SFAS No. 123, the weighted-average fair value of each option granted during the years ended December 2003, 2004 and 2005 was $2.51, $3.92 and $11.19, respectively. The fair value of each option is estimated on the date of grant using the Black-Scholes option-  60       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   pricing model with the following assumptions used for grants issued during the years ended December 31, 2003, 2004, 2005:                                     Year Ended December 31,               2003   2004   2005                         Dividend yield      0.00 %     0.00 %     0.00 %         Expected volatility      71.43 %     67.14 %     61.38 %         Average risk-free interest rate      3.08 %     3.43 %     3.95 %         Expected term      5 years       5 years       5 years       Basic and Diluted Net Income Attributable to Common Stockholders per Common Share        Basic net income attributable to common stockholders per common share excludes dilution for potential common stock issuances and is computed by dividing net income attributable to common stockholders by the weighted-average number of common shares outstanding for the period. Diluted net income attributable to common stockholders per common share reflects the potential dilution that could occur if securities or other contracts to issue common stock were exercised or converted into common stock. The following table provides a reconciliation of the numerators and denominators used in computing basic and diluted net income attributable to common stockholders per common share (in thousands, except per share data):                                         Year Ended December 31,               2003   2004   2005                         Basic net income attributable to common stockholders per common     share:                                    Net income    $ 24,028     $ 45,376     $ 55,398             Dividends on and accretion of convertible preferred stock      (9,583 )     (9,737 )     (4,313 )                               Basic net income attributable to common stockholders    $ 14,445     $ 35,639     $ 51,085                                 Basic net income attributable to common stockholders per common     share    $ 3.09     $ 6.33     $ 1.48                                 Diluted net income attributable to common stockholders per     common share:                                      Basic net income attributable to common stockholders    $ 14,445     $ 35,639     $ 51,085               Dividends on and accretion of convertible preferred stock      9,583       9,737       4,313                                 Diluted net income attributable to common stockholders    $ 24,028     $ 45,376     $ 55,398                                 Diluted net income attributable to common stockholders per     common share    $ 0.31     $ 0.57     $ 0.72                                 Weighted average common shares outstanding — basic      4,680       5,632       34,437           Dilutive effect of:                                    Stock options for the purchase of common stock      6,820       7,515       10,163             Conversion of preferred stock and accrued dividends payable into     common stock      58,755       60,801       26,453             Warrants for the purchase of common stock      6,265       6,289       5,993                                 Weighted average common shares outstanding — diluted      76,520       80,237       77,046                            61      NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   Income Taxes        The Company accounts for income taxes in accordance with SFAS No. 109, Accounting for Income Taxes. Under SFAS No. 109, the liability method is used in accounting for income taxes. Under this method, deferred tax assets and liabilities are determined based on differences between financial reporting and tax bases of assets and liabilities and are measured using the enacted tax rate and laws that will be in effect when the differences are expected to reverse. Deferred tax assets are reduced by a valuation allowance if it is more likely than not that some portion or all of the deferred tax asset will not be realized.   Segment Information        The Company currently operates in one business segment; namely providing critical technology services to the communications industry. The Company is not organized by market and is managed and operated as one business. A single management team reports to the chief operating decision maker who comprehensively manages the entire business. The Company does not operate any material separate lines of business or separate business entities with respect to its services. Accordingly, the Company does not accumulate discrete financial information with respect to separate service lines and does not have separately reportable segments as defined by SFAS No. 131, Disclosure About Segments of an Enterprise and Related Information.        Substantially all of the Company’s material identifiable assets are located in the United States. Revenue derived from international sales was $5.6 million, $5.2 million and $7.0 million for the years ended December 31, 2003, 2004 and 2005.   Comprehensive Income        There were no material differences between net income and comprehensive net income for the years ended December 31, 2003, 2004 and 2005.   Recent Accounting Pronouncements        On December 16, 2004, and as amended on April 14, 2005, the FASB issued Statement No. 123 (revised 2004), Share-Based Payment (SFAS No. 123(R)), which is a revision of FASB Statement No. 123, Accounting for Stock-Based Compensation. SFAS No. 123(R) supersedes APB Opinion No. 25, Accounting for Stock Issued to Employees, and amends FASB Statement No. 95, Statement of Cash Flows. Generally, the approach in SFAS No. 123(R) is similar to the approach described in SFAS No. 123. However, SFAS No. 123(R) requires all share-based payments to employees, including grants of employee stock options, to be recognized in the statement of operations based on their fair values. Pro forma disclosure is no longer an alternative. As permitted by SFAS No. 123, in 2005 and in prior years, the Company accounted for share-based payments to employees using the intrinsic value method of APB Opinion No. 25 and, as such, generally did not recognize compensation cost for employee stock options.        The Company will adopt the provisions of SFAS No. 123(R) for the fiscal quarter beginning on January 1, 2006 using the modified prospective transition method and therefore will not restate prior periods. Application of this pronouncement requires management to make significant judgments regarding the variables in an option pricing model in order to determine fair value, including stock price volatility and employee exercise behavior. Most of these variables are either highly dependent on the economic environment at the date of grant or over the expected term of the award. The Company is currently evaluating the requirements of SFAS No. 123(R) and expects that the adoption of SFAS No. 123(R) will have a material impact on its consolidated results of operations. Had the Company adopted SFAS No. 123(R) in prior periods, the impact of that standard would have approximated the impact of SFAS No. 123 as described in the disclosure of pro forma net income and earnings per share in Note 2 to the Company’s Consolidated Financial Statements. SFAS No. 123(R) also requires the benefits of tax deductions in excess of recognized  62       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   compensation cost to be reported as a financing cash flow, rather than as an operating cash flow as required under current accounting guidance. This requirement will reduce net operating cash flows and increase net financing cash flows in periods after adoption. While the Company cannot estimate what those amounts will be in the future (because they depend on, among other things, when employees exercise stock options), the amount of operating cash flows recognized in prior periods for such excess tax deductions was approximately $0, $0 and $17.0 million in 2003, 2004 and 2005, respectively.         3.  ACQUISITIONS    BizTelOne, Inc.        In January 2003, the Company acquired BizTelOne, Inc. (BTO) for $2.5 million in cash. The acquisition provided technology and market presence needed to facilitate growth of the Company’s order management services. The acquisition was accounted for as a purchase and the results of operations of BTO have been included in the accompanying consolidated statements of operations since the date of the acquisition.        The Company allocated the purchase price principally to acquired technology ($937,000) and goodwill ($2.1 million), and recorded liabilities assumed of $489,000. Acquired technology is included in intangible assets (see Note 7) and is being amortized on a straight-line basis over four years.        In connection with the purchase, the Company was obligated to pay additional consideration over a two-year period to BTO’s former shareholders if certain levels of revenue were achieved by BTO in 2004. The Company accrued $700,000 at December 31, 2004 with a corresponding increase to goodwill for settlement of the earnout, which was paid in March 2005.   NightFire Software, Inc.        In August 2003, the Company acquired certain assets of NightFire Software Inc. (NightFire) for $4.1 million in cash (net of $293,000 cash acquired) and the issuance of 881,435 shares of common stock for total purchase consideration of $7.9 million. NightFire’s products enabled fully automated voice, data, and broadband access services fulfillment for competitive local exchange carriers, integrated communications carriers, incumbent local exchange carriers, inter-exchange carriers, Internet service providers, and other types of service providers. The acquisition of NightFire continued the expansion of the Company’s order management services to telecommunication service providers.        The common stock of the Company was valued at $4.29 per share, which approximated fair market value, on the date of the acquisition. Of the total shares issued, approximately 294,000 shares of common stock were held in escrow for a period of nine months, ending May 2004, pursuant to an indemnification clause in the purchase agreement. The value of these shares has been included in the purchase consideration at the date of acquisition.        The acquisition was accounted for as a purchase and accordingly, the results of operations of the acquired business have been included in the accompanying consolidated statements of operations since the date of the acquisition. The purchase price was allocated to acquired technology ($1.3 million), customer lists ($996,000), and goodwill ($5.7 million) based on their estimated fair values on the acquisition date. Acquired technology and customer lists are included in intangible assets. Acquired technology is being amortized on an accelerated basis over four years, and customer lists are being amortized on a straight-line basis over three years.        In July 2004, 267,446 shares of common stock were released from escrow and the Company recorded a purchase price adjustment of approximately $113,000 for the value of 26,366 shares of common stock that were returned to the Company with an offsetting reduction to goodwill. The shares returned to the Company were held in Treasury as of December 31, 2004 and were retired in May 2005.  63       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   fiducianet, Inc.        In February 2005, the Company acquired fiducianet, Inc. (Fiducianet) for $2.2 million in cash and the issuance of 35,745 shares of common stock for total purchase consideration of $2.6 million. The acquisition of Fiducianet enables the Company to serve as a single point of contact in managing all day-to-day customer obligations involving subpoenas, court orders and law enforcement agency requests under electronic surveillance laws including the Communications Assistance for Law Enforcement, Patriot and Homeland Security Acts. The acquisition was accounted for as a purchase, and the results of Fiducianet have been included in the accompanying consolidated statements of operations since the date of the acquisition.        The Company allocated the purchase price principally to customer lists ($2.6 million) and goodwill ($1.1 million) based on their estimated fair values on the acquisition date. Customer lists are included in intangible assets and are being amortized on a straight-line basis over five years. In accordance with SFAS No. 109, Accounting for Income Taxes, the Company recorded a deferred tax liability of approximately $1.0 million with an offset to goodwill.   Foretec Seminars Inc.        In December 2005, the Company acquired Foretec Seminars, Inc. (Foretec) a provider of secretariat services to the Internet Engineering Task Force (IETF), from the Corporation for National Research Initiatives (CNRI) for $875,000 in cash, of which $500,000 is payable upon the achievement of certain milestones, as well as the payment of approximately $213,000 in legal fees incurred by CNRI to establish a public trust to administer IETF-related intellectual property. In accordance with FASB Statement No. 141, Business Combinations (SFAS No. 141), the $500,000 payable upon the achievement of certain milestones has been included in the purchase consideration since this amount was determinable as of the date of acquisition.        The acquisition was accounted for as a purchase and accordingly, the results of Foretec have been included in the accompanying consolidated statements of operations since the date of the acquisition. The purchase price was allocated to net liabilities assumed of approximately $53,000 and goodwill ($929,000) based on their estimated fair values on the acquisition date.         4.  SECURITIZED NOTES RECEIVABLE         The Company has receivables for functionality upgrades on behalf of its customers under its Statement of Work (SOW) contracts with North American Portability Management LLC. At the option of these customers, payment of these securitized notes receivable is made over 36 months from completion of the contract. The obligations, which are unsecured, accrue interest monthly on the unpaid balance. The interest charges range from 7.3% to 9.6% per annum. Payments are received from each customer for its pro-rata share of the obligation under the SOW contracts.         5.  DEFERRED FINANCING COSTS         During 2003, 2004 and 2005, the Company paid $250,000, $0 and $0, respectively, in loan origination fees that are being amortized using the effective-interest method over the term of the related debt. Total amortization expense was approximately $496,000, $150,000 and $57,000 for the years ended December 31, 2003, 2004 and 2005, respectively, and is reported as interest expense in the consolidated statements of operations. As of December 31, 2004 and 2005, the balance of unamortized deferred financing fees was $65,000 and $7,000, respectively, and is included within other noncurrent assets.  64       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)         6.  PROPERTY AND EQUIPMENT         Property and equipment consists of the following (in thousands):                             December 31,               2004   2005                     Computer hardware    $ 26,245     $ 32,608           Equipment      312       969           Furniture and fixtures      2,176       2,537           Leasehold improvements      11,852       14,781           Construction in-progress      3,002       1,927           Capitalized software      25,099       33,091                           68,686       85,913           Accumulated depreciation and amortization      (32,182 )     (46,286 )                         Property and equipment, net    $ 36,504     $ 39,627                            The Company entered into capital lease obligations of $8.1 million and $3.5 million for the years ended December 31, 2004 and 2005, respectively, primarily for equipment and furniture.        In 2003, the Company revised the estimated useful life related to certain systems as the Company expected to replace the affected systems in 2004. As a result, the Company accelerated depreciation based on the revised useful life for an amount totaling $686,000 in 2003. Depreciation and amortization expense for the years ended December 31, 2003, 2004 and 2005 was $16.1 million, $17.3 million and $16.0 million, respectively.         7.  GOODWILL AND INTANGIBLE ASSETS         Goodwill consists of the following (in thousands):                             December 31,               2004   2005                     Goodwill    $ 49,453     $ 51,495                            Intangible assets consist of the following (in thousands):                                       December 31,   Weighted-Average           Amortization Period       2004   2005   (In Years)                         Intangible assets:                                    Customer lists    $ 996     $ 3,566       4.4             Accumulated amortization      (704 )     (1,441 )                                         Customer lists, net      292       2,125                                           Acquired technology      2,208       2,208       4.0             Accumulated amortization      (1,250 )     (1,678 )                                         Acquired technology, net      958       530                                         Intangible assets, net    $ 1,250     $ 2,655                                          Amortization expense related to other intangible assets for the years ended December 31, 2003, 2004 and 2005 of approximately $629,000, $1.3 million and $1.2 million, respectively, is included in depreciation and  65       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   amortization expense. Amortization expense related to other intangibles for the years ended December 31, 2006, 2007, 2008, 2009 and 2010 is expected to be approximately $858,000, $726,000, $514,000, $514,000 and $43,000, respectively.         8.  ACCRUED EXPENSES         Accrued expenses consist of the following (in thousands):                             December 31,               2004   2005                     Accrued wages    $ 15,656     $ 23,254           RRC reserve      4,289       2,501           Other      12,685       11,125                         $ 32,630     $ 36,880                             9.  NOTES PAYABLE         Notes payable consist of the following (in thousands):                             December 31,               2004   2005                     Promissory note payable to vendor; principal and interest     payable quarterly at 1.73% per annum with a maturity date     of April 1, 2006; secured by the equipment financed    $ 767     $ 155           Promissory note payable to vendor; principal and interest     payable quarterly at 2.88% per annum with a maturity date     of April 1, 2006; secured by the equipment financed      41       10           Promissory note payable to vendor; principal and interest     payable quarterly at 3.87% per annum with a maturity date     of April 1, 2006; secured by the equipment financed      146       30           Promissory note payable to vendor; principal and interest     payable quarterly at 2.08% per annum with a maturity date     of April 1, 2007; secured by the equipment financed      1,443       810           Promissory note payable to vendor; principal and interest     payable quarterly at 0.0% per annum with a maturity date of     March 1, 2008; secured by the equipment financed      —       1,246           2003 Receivables Facility (defined below), bearing interest at     the one-month LIBOR rate plus 2.00% (6.39% at December 31,     2005), with monthly paydown corresponding with the cash     collection of securitized notes receivable (see Note 4),     with a maturity date of February 1, 2007      3,597       —                           5,994       2,251           Less: current portion      (4,636 )     (1,232 )                         Notes payable, long-term    $ 1,358     $ 1,019                       Revolving Credit Facility        In August 2002, the Company entered into a Revolving Credit Facility (Revolving Credit Facility), which provides the Company with up to $15 million in available credit. Borrowings under the Revolving Credit Facility may be either Base Rate loans or Eurodollar rate loans. Base Rate loans bear interest at a fluctuating  66       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   rate per annum equal to the higher of the federal funds rate plus 0.5% or the lender’s prime rate. Eurodollar rate loans bear interest at the Eurodollar rate plus the applicable margin. There were no outstanding borrowings under the Revolving Credit Facility at December 31, 2004 and December 31, 2005; however, total available borrowings were reduced by outstanding letters of credit of $1.8 million and $10.7 million at December 31, 2004 and December 31, 2005, respectively (see Note 10), which reduce the amount the Company may borrow under the revolving credit facility. Accordingly, as of December 31, 2004 and 2005, the available capacity under the Revolving Credit Facility was $13.2 million and $4.3 million, respectively.        The Company’s obligations under the Revolving Credit Facility are secured by all of the Company’s assets (other than the assets of NeuLevel, Inc. and those securing its obligations under the 2003 Receivable Facility, as discussed below). Under the terms of the Revolving Credit Facility, the Company must comply with certain financial covenants such as maintaining minimum levels of consolidated net worth, quarterly consolidated EBITDA, and liquid assets and not exceeding certain levels of capital expenditures and leverage ratios. Additionally, there are negative covenants that limit the Company’s ability to declare or pay dividends, acquire additional indebtedness, incur liens, dispose of significant assets, make acquisitions or significantly change the nature of the business without permission of the lender. During 2003, 2004 and 2005, the Company was not in compliance with certain covenants and obtained waivers for such defaults.   Receivables Facilities        In November 2001, the Company established a Receivables Facility with a bank (2001 Receivables Facility), which provided the Company with up to a total of $37 million, as amended, in available credit. In connection with the 2001 Receivables Facility, the Company drew down net proceeds of approximately $28.0 million, net of financing costs, against $30.2 million in securitized notes receivable (see Note 4) in November 2001. This balance was repaid in full in 2003. In September 2002, the Company amended the 2001 Receivables Facility and drew down additional net proceeds of $6.7 million, net of financing costs, against $7.0 million in securitized notes receivable (see Note 4). In October 2003, the Company used a portion of the proceeds from the 2003 Receivables Facility, as discussed below, to pay off the remaining balance on the 2001 Receivables Facility.        In October 2003, the Company established a Receivables Facility with a bank (2003 Receivables Facility), pursuant to which it borrowed $10.1 million, secured by, and payable from the proceeds of, its securitized notes receivable (see Note 4). An independent third party administers the collection of the securitized notes receivable. As the securitized notes receivable are collected, the third party pays the bank directly for all secured amounts on a monthly basis, thereby reducing the amounts outstanding under the facility. Minimum payments of $1 million have been due every six months since January 2004, and all amounts outstanding are due February 1, 2007. The Company has guaranteed a portion of the 2003 Receivables Facility (less than 10% of the outstanding principal balance) but is otherwise not liable for the collection of amounts owed under the secured securitized notes receivable. The 2003 Receivables Facility bears interest at the reserve adjusted one month LIBOR rate plus 2%. As of December 31, 2005, the rate was 6.39%.  67       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)        As of December 31, 2005, remaining principal payments under promissory notes payable and the 2003 Receivables Facility are as follows (in thousands):                       2006    $ 1,232           2007      880           2008      139                     Total      2,251           Less: current portion      (1,232 )                   Notes payable, long-term    $ 1,019                       10.  COMMITMENTS AND CONTINGENCIES    Capital Leases        The following is a schedule of future minimum lease payments due under capital lease obligations (in thousands):                       2006    $ 6,346           2007      3,207           2008      370                     Total minimum lease payments      9,923           Less: amounts representing interest      (943 )                   Present value of minimum lease payments      8,980           Less: current portion      (5,540 )                   Capital lease obligation, long-term    $ 3,440                      The following assets were capitalized under capital leases at the end of each period presented (in thousands):                             December 31,               2004   2005                     Equipment and hardware    $ 14,922     $ 18,392           Furniture and fixtures      1,918       1,918                           16,840       20,310           Less: accumulated amortization      (4,982 )     (10,838 )                       $ 11,858     $ 9,472                            The Company is obligated under certain capital lease obligations to maintain letters of credit for the value of the underlying assets. The Company has letters of credit with balances totaling $1.8 million and $10.7 million at December 31, 2004 and 2005, respectively.  68       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   Operating Leases        The Company leases office space under noncancelable operating lease agreements. The leases terminate at various dates through 2010 and generally provide for scheduled rent increases. Future minimum lease payments under noncancelable operating leases as of December 31, 2005, are as follows (in thousands):                       2006    $ 4,765           2007      4,283           2008      4,181           2009      4,265           2010      3,054           Thereafter      825                   $ 21,373                      Rent expense was $2.6 million, $3.0 million and $3.6 million for the years ended December 31, 2003, 2004 and 2005, respectively.   Contingencies        Currently, and from time to time, the Company is involved in litigation arising in the normal course of its business. The Company is not a party to any lawsuit or proceeding that, in the opinion of management, is reasonably possible to have a material adverse effect on its financial position, results of operations or cash flows.         11.  RESTRUCTURING CHARGES    Workforce Reduction        The restructuring program during 2005 resulted in workforce reductions of approximately 20 employees which were located in the Company’s Oakland, California office. The Company recorded workforce reduction charges of $317,000 during the year ended December 31, 2005, primarily for severance and fringe benefits.   Closure of Excess Facilities        During 2003, the Company recorded a change in estimate of approximately $1.3 million to reduce a previously established restructuring liability in connection with the cancellation of a lease without penalties, which the Company had previously believed would apply when the applicable property was abandoned in 2002. During 2004, the Company recorded a change in estimate of approximately $220,000 to reduce the restructuring liability as a result of changes in the Company’s assumptions regarding the time period over which this property would remain vacant. During 2005, the Company recorded a change in estimate of approximately $706,000 to reduce the restructuring liability due to a change in the Company’s assumptions regarding the sub-lease rate for this property.        At December 31, 2004 and 2005, the accrued liability associated with the restructuring and other related charges was $5.0 million and $3.1 million, respectively. Amounts related to the lease termination due to the closure of excess facilities will be paid over the respective lease terms, the longest of which extends through 2011. The Company paid approximately $3.3 million, $900,000 and $1.9 million, in the years ended December 31, 2003, 2004 and 2005, respectively, related to restructuring charges.  69      NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)         12.  INCOME TAXES         The provision for income taxes consists of the following components (in thousands):                                       Year Ended December 31,               2003   2004   2005                         Current:                                    Federal    $ 401     $ 5,609     $ 32,381             State      435       1,976       5,905                                 Total current      836       7,585       38,286           Deferred:                                    Federal      —       (5,429 )     (876 )           State      —       (990 )     (159 )                               Total deferred      —       (6,419 )     (1,035 )                               Total provision for income taxes    $ 836     $ 1,166     $ 37,251                                  As of June 30, 2004, the Company had generated operating profits for six consecutive quarters and had fully utilized its federal net operating loss carryforwards. As a result of this earnings trend and projected operating results over future years, the Company reversed approximately $20.2 million of its deferred tax asset valuation allowance, having determined that it was more likely than not that these deferred tax assets will be realized. This reversal resulted in the recognition of an income tax benefit of $16.9 million and a reduction of goodwill of $3.3 million. Of the total income tax benefit recognized, approximately $14.5 million relates to a federal deferred tax benefit with the remainder representing the state deferred tax benefit.  70      NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)        Deferred income taxes reflect the net tax effects of temporary differences between the carrying amount of assets and liabilities for financial reporting purposes and the amounts used for income tax purposes. Significant components of the Company’s net deferred income taxes are as follows (in thousands):                               December 31,               2004   2005                     Deferred tax assets:                            NOL carryforwards    $ —     $ 111             Restructuring accrual      1,964       1,209             Deferred revenue      4,939       6,328             Accrued compensation      5,792       7,535             Start-up costs      1,742       689             Stock-based compensation expense      602       1,119             Other reserves      1,173       1,281             Other      495       777                           Total deferred tax assets      16,707       19,049                           Deferred tax liabilities:                            Unbilled receivables      (482 )     (3,162 )           Depreciation and amortization      (4,883 )     (2,575 )           Identifiable intangibles      (236 )     (816 )           Deferred expenses      (1,362 )     (1,462 )           Other      (15 )     (15 )                         Total deferred tax liabilities      (6,978 )     (8,030 )                         Net deferred tax asset    $ 9,729     $ 11,019                            A reconciliation of the statutory United States income tax rate to the effective income tax rate follows:                                     Year Ended December 31,               2003   2004   2005                         Tax at statutory rate      35.0 %     35.0 %     35.0 %         State taxes      5.7       5.1       4.1           AMT Credit/ Tax      1.6       (1.0 )     1.6           Other      0.1       0.1       (0.5 )         Change in valuation allowance      (39.0 )     (36.7 )     0.0                                 Effective tax rate      3.4 %     2.5 %     40.2 %                                 13.  CONVERTIBLE PREFERRED STOCK         Prior to the Company’s initial public offering on June 28, 2005 (See Note 1), holders of 100,000 shares of Series B Voting Convertible Preferred Stock, 28,569,692 shares of Series C Voting Convertible Preferred Stock, and 9,098,525 shares of Series D Voting Convertible Preferred Stock converted their shares into 500,000, 28,569,692, and 9,098,525 shares of the Company’s common stock, respectively, after which each share of common stock was split by means of a reclassification into 1.4 shares of Class B common stock and subsequently converted, at the election of the holder, into Class A common stock.  71      NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   Series B Preferred Stock        The holders of the Series B were entitled to receive preferential cumulative dividends in cash at the rate per share of 6% of stated value ($0.651) or $0.04 per annum, compounded quarterly. Dividends were declared and paid on the Series B. Each share of Series B was convertible into seven shares of common stock, subject to anti-dilution adjustments, and was entitled to that number of votes. Conversion into common stock was automatic in the event of an underwritten public offering (or a combination of offerings) of common stock with gross proceeds to the Company of not less than $50 million (Qualified IPO). In the event of liquidation, dissolution, or winding up of the Company, the holders of the Series B would have received, on par with the holders of the Series C, a liquidation preference of $0.651 per share plus any accrued and unpaid dividends per share. Dividends on the Series B were approximately $4,800, $4,800 and $2,000 for each of the years ended December 31, 2003, 2004 and 2005. Accrued and unpaid dividends on Series B were $18,000, $1,000 and $0 at December 31, 2003, 2004 and 2005, respectively.        The Series B had a deemed liquidation provision included among the rights given to its holders whereby, upon the sale of the Company or substantially all the Company’s assets, the holders of the Series B were entitled to elect to receive a cash payment equal to the liquidation preference or the amount of consideration that would have been payable had the Series B converted to common stock.   Series C Preferred Stock        The holders of the Series C were entitled to receive cumulative dividends in cash at the rate per share of 6% of stated value ($2.956) or $0.18 per annum, compounded quarterly. Dividends were declared and paid on the Series C in preference in respect to other series of stock determined as subordinate. The Series C were convertible to common shares on a 1.4-for-1 basis, subject to anti-dilution adjustments. Upon a Qualified IPO, the Series C would have automatically converted to common stock at the applicable conversion price. Each share of Series C was entitled to the same number of votes as the shares of common stock into which it was convertible. The Company also had the right to redeem, in whole or in part, the Series C outstanding at the Series C redemption price of $2.956 per share, plus an amount equal to any and all dividends accrued and unpaid, with consent of the holders of a majority of the Series C. In the event of liquidation, dissolution, or winding up of the Company, the holders of the Series C would have received, on par with the holders of the Series B, a liquidation preference of $2.956 per share plus any accrued and unpaid dividends per share. Dividends on the Series C were approximately $5.7 million and $5.8 million and $2.5 million for the years ended December 31, 2003, 2004 and 2005, respectively. Accrued and unpaid dividends on the Series C were approximately $14.0 million, $1.3 million and $0 at December 31, 2003, 2004 and 2005, respectively.        The Series C had a deemed liquidation provision included among the rights given to its holders whereby, upon the sale of the Company or substantially all the Company’s assets, the holders of the Series C were entitled to elect to receive a cash payment equal to the liquidation preference or the amount of consideration that would have been payable had the Series C converted to common stock.   Series D Preferred Stock        Holders of the Series D were entitled to receive cumulative dividends in cash at the rate per share of 6% of stated value ($5.935) or $0.36 per annum, compounded quarterly. Dividends were declared and paid on the Series D, subject in all cases to the rights and preferences of the holders of Series B and C but were in preference with respect to other series of shares determined as subordinate. The Series D were convertible to common shares on a 1.4-for-1 basis, subject to anti-dilution adjustments. Upon a Qualified IPO, the Series D would have automatically converted to common stock at the conversion price applicable at that time. Each share of Series D was entitled to that number of votes as the shares of common stock into which it was convertible.  72       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)        During the period commencing on August 5, 2006 and ending September 5, 2006, the holders of a majority of the then-outstanding shares of Series D and Series E could have required the Company to engage an independent investment banker to seek a third-party purchaser for then-outstanding Series D and E at not less than the applicable liquidation amount or some or all of the Company’s assets or to sell additional securities to fund the redemption of the Series D and Series E, such that the holders of such shares will receive the applicable liquidation amount. If the shares of Series D and Series E were not purchased or redeemed by the Company prior to June 5, 2007, the Company would have been required to redeem such shares on that date. If a majority of the holders of Series D and E did not elect to have their shares redeemed, a certain holder of Series D had a one-month period ending in October 2006 to have required the Company to redeem their shares on June 5, 2009. If the board of directors had determined that funds will not be reasonably available to satisfy the redemption obligation, the Company would not have been required to do so, provided that it increased the dividend rate on shares held by a certain holder of Series D by 0.5% per annum, up to a maximum dividend rate of 15% per annum. Series D was redeemable in amounts equal to the original investment plus accrued and unpaid dividends. The redemption amount of the Series D, $54.0 million plus accrued and unpaid dividends, was accreted to its redemption rate.        In the event of a liquidation, dissolution, or winding up of the Company, the holders of the Series D and E were entitled to a liquidation preference over holders of all other series of preferred and common stock. The holders of the Series B and C were pari passu and had preference over the common stockholders. Dividends on and accretion of the Series D were approximately $3.6 million, $3.7 million and $1.6 million for the years ended December 31, 2003, 2004 and 2005, respectively.        Accrued and unpaid dividends on the Series D were $8.9 million, $817,000 and $0 at December 31, 2003, 2004 and 2005, respectively.         14.  STOCKHOLDERS’ (DEFICIT) EQUITY    Preferred Stock        The Company is authorized to issue up to 100,000,000 shares of preferred stock, $0.001 par value per share, in one or more series, to establish from time to time the number of shares to be included in each series, and to fix the rights, preferences, privileges, qualifications, limitations and restrictions of the shares of each wholly unissued series.   Common Stock        The Company is authorized to issue up to 200,000,000 shares of Class A common stock, $0.001 par value per share and 100,000,000 shares of Class B common stock, $0.001 par value per share. Each holder of Class A and Class B common stock is entitled to one vote for each share of common stock held on all matters submitted to a vote of stockholders. Subject to preferences that may apply to shares of preferred stock outstanding at the time, the holders of Class A and Class B common stock are entitled to receive dividends out of assets legally available at the times and in the amounts as our board of directors may from time to time determine.        On June 28, 2005, the Company made an initial public offering of 31,625,000 shares of Class A common stock, which included the underwriters’ over-allotment option exercise of 4,125,000 shares of Class A common stock. All the shares of Class A common stock sold in the IPO were sold by selling stockholders and, as such, the Company did not receive any proceeds from the offering. In connection with this transaction, the Company incurred offering costs and other IPO-related expenses of approximately $4.9 million.        On December 6, 2005, the Company completed an additional offering (December 2005 offering), of 20,000,000 shares of Class A common stock. All the shares of Class A common stock sold in the December 2005 offering were sold by selling stockholders and, as such, the Company did not receive any proceeds from  73       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   that offering. In connection with this transaction, the Company incurred offering costs of approximately $900,000.        In connection with the formation of NeuLevel, Inc. (NeuLevel), the Company’s 90%-owned subsidiary, the Company granted the minority interest holder of NeuLevel an option to purchase, within 30 days of the completion of the Company’s initial public offering, up to $20.0 million worth of Class B common stock at a purchase price per share equal to the public offering price. This option expired unexercised.        In October 2005, the Company granted 5,000 shares of restricted common stock to an employee under the NeuStar, Inc. 2005 Stock Incentive Plan. The shares vest in annual equal installments over three years from the date of grant.   Warrants        In prior years, the Company issued warrants to purchase 6,361,383 shares of common stock at $0.0667 per share in connection with certain debt financings. On December 12, 2005, the Company issued 6,361,383 shares of Class A common stock upon the exercise these warrants in exchange for cash proceeds of approximately $424,000.         15.  STOCK INCENTIVE PLANS         The Company has two stock incentive plans, the NeuStar, Inc. 1999 Equity Incentive Plan (the 1999 Plan) and the NeuStar, Inc. 2005 Stock Incentive Plan (the 2005 Plan). Under the 1999 Plan, the Company had the ability to grant to its directors, employees and consultants stock or stock-based awards in the form of incentive stock options, nonqualified stock options, stock appreciation rights, performance share units, shares of restricted common stock, phantom stock units and other stock-based awards. In May 2005, the Company’s board of directors adopted the 2005 Plan, which was approved by the Company’s stockholders in June 2005. In connection with the adoption of the 2005 Plan, the Company’s board of directors amended the 1999 Plan to provide that no further awards would be granted under the 1999 Plan as of the date stockholder approval of the 2005 Plan was obtained. All shares available for grant as of that date, plus any other shares under the 1999 Plan that again become available due to forfeiture, expiration, settlement in cash or other termination of awards without issuance, will be available for grant under the 2005 Plan.        Under the 2005 plan, the Company may grant to its directors, employees and consultants awards in the form of incentive stock options, nonqualified stock options, stock appreciation rights, shares of restricted stock, restricted stock units, performance awards and other stock-based awards. The aggregate number of shares of Class A common stock with respect to which all awards may be granted under the 2005 plan is 6,044,715, plus any shares available for issuance under the 1999 Plan. As of December 31, 2005, 6,021,173 shares are available for grant or award under the 2005 Plan.        The terms of all stock options granted may not exceed ten years. The exercise price of options granted, as determined by the Compensation Committee, approximates fair market value of Common Stock at the time of the grant. The exercise price per share for options granted under the Plan is generally not less than 100% of the fair market value of the common stock on the option grant date. The board of directors or Compensation Committee of the board of directors determines the vesting of the options, with a maximum vesting period of ten years. Options issued through 2005 generally vest with respect to 25% of the shares on the first anniversary of the grant date and 2.083% of the shares on the last day of each succeeding calendar month thereafter. The options expire ten years from date of issuance and are forfeitable upon termination of an option holder’s service.  74      NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)        The following table summarizes the Company’s stock option activity:                                   Weighted-Average       Shares   Exercise Price                     Outstanding at December 31, 2002      9,345,910     $ 1.07             Options granted      4,016,446       5.26             Options exercised      (220,060 )     0.18             Options forfeited      (425,703 )     2.11                           Outstanding at December 31, 2003      12,716,593       2.37             Options granted      2,983,173       6.69             Options exercised      (611,118 )     0.15             Options forfeited      (713,006 )     3.91                           Outstanding at December 31, 2004      14,375,642       3.29             Options granted      1,149,844       20.33             Options exercised      (2,588,631 )     3.07             Options forfeited      (315,302 )     6.10                           Outstanding at December 31, 2005      12,621,553       4.81                           Exercisable at December 31, 2005      8,692,844       2.41                           Exercisable at December 31, 2004      8,561,121       1.46                           Exercisable at December 31, 2003      7,466,332       0.92                            The following table summarizes information regarding options outstanding at December 31, 2005:                                                     Options Outstanding       Options Exercisable           Weighted-               Weighted-   Average       Weighted-       Number of   Average   Remaining   Number of   Average       Options   Exercise   Contractual Life   Options   Exercise   Range of Exercise Price   Outstanding   Price   (In Years)   Exercisable   Price                                 $ 0.00 - $ 3.20      5,252,398     $ 0.38       4.51       5,252,398     $ 0.38           $ 3.21 - $ 6.21      2,492,998       4.42       6.90       1,963,415       4.39           $ 6.22 - $ 8.21      3,296,263       6.33       7.93       1,223,778       6.33           $ 8.22 - $11.21      776,644       9.42       8.18       253,253       10.27           $11.22 - $31.95      803,250       24.35       9.51       —       —                                             12,621,553       4.81       6.42       8,692,844       2.41                                              In June 2004, the Company entered into an agreement with an employee which gave the employee the right to put 210,000 shares of common stock to be received upon the exercise of vested stock options back to the Company at $4.82 per share. In July 2004, the employee exercised vested stock options for 210,000 shares of common stock and put the shares back to the Company in August 2004. The Company recognized stock-based compensation expense of $982,000 on the date the put right was granted in accordance with FASB Interpretation No. 44, Accounting for Certain Transactions Involving Stock Compensation, an Interpretation of ABP 25. The shares repurchased were held in treasury as of December 31, 2004 and were retired in May 2005.        In July 2004, the Company granted an employee of the Company the right to receive a total of 350,000 shares of common stock. This right vests on December 18, 2008. The Company recorded $2.2 million  75      NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   in deferred compensation expense during the year ended December 31, 2004 in connection with this stock grant. The deferred compensation is calculated as the fair value of the shares on the grant date and is being amortized over the vesting period of the restricted stock.        In February 2005, the Company granted fully vested options to nonemployees for the purchase of 22,400 shares of common stock at a weighted average exercise price of $10.86 per share. The Company recognized compensation expense of approximately $180,000. The fair value of these awards was calculated on the date of grant using the Black-Scholes option-pricing model with the following weighted average assumptions: expected life of the award equal to the remaining contractual life; volatility 63.11%; risk-free interest rate, 3.38%; and dividend yield of 0.00% during the option term.        In March 2005, an employee of the Company changed status to a consultant and, in accordance with the terms of that employee’s original option agreement, continued to vest in 26,250 options as of March 29, 2005. As a result, the Company re-measured the fair value of the vested options and recognized compensation expense of approximately $331,000. The fair value of this award was calculated on the modification date using the Black-Scholes option-pricing model with the following weighted average assumptions: expected life of the award equal to the remaining contractual life; volatility 63.11%; risk-free interest rate, 3.43%; and dividend yield of 0.00% during the option term.        In March 2005, the Company accelerated the vesting of certain options issued to nonemployees. This acceleration enabled the optionholders to immediately vest in approximately 102,000 options, which otherwise would have vested over the options’ original vesting period, generally 48 months. In connection with this acceleration, the Company recorded approximately $1.6 million as compensation expense based on the fair value of the options on the date of acceleration. The fair value of these awards was remeasured on the acceleration date using the Black-Scholes option-pricing model with the following weighted average assumptions: expected life of the award equal to the remaining contractual life; volatility 63.11%; risk-free interest rate, 3.72%; and dividend yield of 0.00% during the option term. As of March 31, 2005, all options granted to nonemployees had vested. Prior to this acceleration, the Company recognized compensation expense of approximately $249,000 and $644,000 for the years ended December 31, 2003 and 2004.        In October 2005, the Company granted 5,000 shares of restricted common stock to an employee under the 2005 Plan. The shares vest in annual equal installments over three years from the date of grant. The Company recorded approximately $160,000 of deferred stock compensation expense relating to the issuance of the restricted common stock. The deferred stock compensation expense is amortized on a straight-line basis over the three year vesting period.         16.  EMPLOYEE BENEFIT PLANS         The Company has a 401(k) Profit-Sharing Plan for the benefit of all employees who meet certain eligibility requirements. This plan covers substantially all of the Company’s full-time employees. The plan documents provide for the Company to make matching and other discretionary contributions, as determined by the board of directors. The Company recognized contribution expense related to both plans totaling $1.3 million, $1.5 million and $2.0 million for the years ended December 31, 2003, 2004 and 2005, respectively.         17.  RELATED PARTY TRANSACTIONS         During the years ended December 31, 2003, 2004 and 2005, the Company received professional services from a company owned by a family member of the Chairman and CEO of the Company. The services were related to tenant improvements in the Company’s leased office spaces. The amounts paid to the related party during the years ended December 31, 2003, 2004 and 2005 were approximately $38,000, $117,000 and  76       NEUSTAR, INC.   NOTES TO CONSOLIDATED FINANCIAL STATEMENTS — (Continued)   $99,000, respectively. As of December 31, 2004 and 2005, the Company had no outstanding payable to this party.        The Company has an agreement with Melbourne IT Limited (MIT), a holder of a 10% interest in NeuLevel, whereby MIT serves as a registrar for domain names within the .biz top-level domain. During the years ended December 31, 2003, 2004 and 2005, the Company recorded approximately $377,000, $512,000 and $684,000, respectively, in revenue from MIT related to domain name registration services and other nonrecurring revenue from IP claim notification services and pre-registration services.         18.  QUARTERLY FINANCIAL INFORMATION (UNAUDITED)                                                Quarter Ended               Mar. 31,   Jun. 30,   Sep. 30,   Dec. 31,       2004   2004   2004   2004                           (In thousands, except per share data)         Summary consolidated statement of operations:                                            Total revenue    $ 38,714     $ 39,610     $ 45,229     $ 41,448 (1)           Income from operations      14,054       11,586       14,794       6,977             Net income      13,533       18,668       8,964       4,211             Net income attributable to common stockholders      11,056       16,155       6,386       2,042             Net income attributable to common stockholders per common     share — basic    $ 2.06     $ 2.94     $ 1.10     $ 0.35             Net income attributable to common stockholders per common     share — diluted    $ 0.17     $ 0.23     $ 0.11     $ 0.05                                                   Quarter Ended               Mar. 31,   Jun. 30,   Sep. 30,   Dec. 31,       2005   2005   2005   2005                           (In thousands, except per share data)         Summary consolidated statement of operations:                                            Total revenue    $ 57,792     $ 62,296     $ 58,960 (1)   $ 63,421             Income from operations      24,475       23,016       21,692       23,285             Net income      14,631       13,883       13,057       13,827             Net income attributable to common stockholders      12,488       11,713       13,057       13,827             Net income attributable to common stockholders per common     share — basic    $ 2.08     $ 1.45     $ 0.22     $ 0.22             Net income attributable to common stockholders per common     share — diluted    $ 0.19     $ 0.18     $ 0.17     $ 0.18                 (1)       Revenue for the quarters ended December 31, 2004 and     September 30, 2005 reflects contractual pricing discounts     based on pre-established annual aggregate transaction volume     targets under our contracts with North American Portability     Management LLC, which had an impact of $11.9 million and     $7.5 million, respectively.          19.  SUBSEQUENT EVENT         In March 2006, the Company acquired all of the remaining shares of NeuLevel, Inc. from its joint venture partner, Melbourne IT Limited (MIT) for $4.3 million in cash. In accordance SFAS No. 141, the acquisition will be accounted for using purchase accounting. The Company is currently in the process of completing its purchase price allocation.  77                 ITEM 9.  CHANGES IN AND DISAGREEMENTS WITH ACCOUNTANTS ON ACCOUNTING     AND FINANCIAL DISCLOSURE.         None.             ITEM 9A.  CONTROLS AND PROCEDURES.         We maintain disclosure controls and procedures that are designed to ensure that information required to be disclosed in our reports filed or submitted under the Securities Exchange Act of 1934 is recorded, processed, summarized and reported within the time periods specified in the Securities and Exchange Commission’s rules and forms, and that such information is accumulated and communicated to our management, including our Chief Executive Officer and Chief Financial Officer, as appropriate, to allow for timely decisions regarding required disclosure. In designing and evaluating the disclosure controls and procedures, management recognized that any controls and procedures, no matter how well designed and operated, can provide only reasonable assurance of achieving the desired control objectives, and management is required to apply its judgment in evaluating the cost-benefit relationship of possible controls and procedures.        As of December 31, 2005, we carried out an evaluation, under the supervision and with the participation of our management, including our Chief Executive Officer and our Chief Financial Officer, of the effectiveness of the design and operation of our disclosure controls and procedures. Based on the foregoing, our Chief Executive Officer and Chief Financial Officer concluded that our disclosure controls and procedures were effective and were operating at the reasonable assurance level.        In addition, there were no changes in our internal control over financial reporting that occurred in the fourth quarter of 2005 that materially affected, or are reasonably likely to materially affect, our internal control over financial reporting.
None.       PART III             ITEM 10.  DIRECTORS AND EXECUTIVE OFFICERS OF THE REGISTRANT.         Information about our directors and executive officers is incorporated by reference to our definitive proxy statement for our 2006 Annual Meeting of Stockholders, or our 2006 Proxy Statement, which is anticipated to be filed with the Securities and Exchange Commission within 120 days of December 31, 2005, under the headings “Board of Directors” and “Executive Officers and Management.” Information about compliance with Section 16(a) of the Exchange Act is incorporated by reference to our 2006 Proxy Statement under the heading “Section 16(a) Beneficial Ownership Reporting Compliance.” Information about our Audit Committee, including the members of the Audit Committee, and Audit Committee financial experts, is incorporated by reference to our 2006 Proxy Statement under the heading “Governance of the Company — Board and Committee Membership.” Information about the NeuStar policies on business conduct governing our employees, including our Chief Executive Officer, Chief Financial Officer and our controller, is incorporated by reference to our 2006 Proxy Statement under the heading “Governance of the Company — Governance Information.”             ITEM 11.  EXECUTIVE COMPENSATION.         Information about director and executive officer compensation is incorporated by reference to our 2006 Proxy Statement, under the headings “Governance of the Company — Compensation of Non-Employee Directors,” “Executive Compensation,” “Compensation Committee Interlocks and Insider Participation,” and “Termination of Employment and Change in Control Arrangements and Indemnification.”  78                 ITEM 12.  SECURITY OWNERSHIP OF CERTAIN BENEFICIAL OWNERS AND     MANAGEMENT AND RELATED STOCKHOLDER MATTERS.         Information required by Item 12 of this report is incorporated by reference to our 2006 Proxy Statement, under the headings “Beneficial Ownership of Shares of Common Stock” and “Equity Compensation Plan Information.”             ITEM 13.  CERTAIN RELATIONSHIPS AND RELATED TRANSACTIONS.         The information required by Item 13 of this report is incorporated by reference to our 2006 Proxy Statement, under the heading “Certain Relationships and Related Party Transactions.”             ITEM 14.  PRINCIPAL ACCOUNTING FEES AND SERVICES.         Information about the fees for professional services rendered by our independent auditors in 2004 and 2005 is incorporated by reference to the discussion under the heading “Audit and Non-Audit Fees” in our 2006 Proxy Statement. Our audit committee’s policy on pre-approval of audit and permissible non-audit services of our independent auditors is incorporated by reference from the discussion under the heading “Policy on Audit Committee Pre-Approval of Audit and Permissible Non-Audit Services of Independent Registered Public Accounting Firm” in our 2006 Proxy Statement.       PART IV             ITEM 15.  EXHIBITS, FINANCIAL STATEMENT SCHEDULES.         (a) Documents filed as part of this report:                     (1) Financial Statements                        Page                 Report of Independent Registered Public Accounting Firm      46           Financial Statements covered by the Report of Independent     Registered Public Accounting Firm:                    Consolidated Balance Sheets as of December 31, 2004 and 2005      47             Consolidated Statements of Operations for the years ended     December 31, 2003, 2004 and 2005      49             Consolidated Statements of Stockholders’ (Deficit) Equity     for the years ended December 31, 2003, 2004 and 2005      50             Consolidated Statements of Cash Flows for the years ended     December 31, 2003, 2004 and 2005      51             Notes to the Consolidated Financial Statements      52                         (2) Financial Statement Schedules                          Schedule for the three years ended December 31, 2003, 2004     and 2005:                     II — Valuation and Qualifying     Accounts      80                         (3) Exhibits                      A list of exhibits filed or furnished with this report is     provided in the Exhibit Index beginning on page 80 of this     report.   79      NEUSTAR, INC.       SCHEDULE II — VALUATION AND QUALIFYING ACCOUNTS                                       As of December 31,               2003   2004   2005                       (In thousands)     Allowance for Doubtful Accounts                                    Beginning Balance    $ 66     $ 84     $ 468             Additions      184       960       551             Reductions(1)      (166 )     (576 )     (525 )                                 Ending Balance    $ 84     $ 468     $ 494                             Deferred Tax Asset Valuation Allowance                                    Beginning Balance    $ 30,270     $ 20,209     $ —             Additions      —       —       —             Reductions      (10,061 )     (20,209 )     —                                   Ending Balance    $ 20,209     $ —     $ —                                       (1)       Includes accounts written-off, net of collections on accounts     previously written off.   80       EXHIBIT INDEX        Exhibits identified in parentheses below are on file with the SEC and are incorporated herein by reference. All other exhibits are provided as part of this electronic submission.                 Exhibit       Number   Description of Exhibit             (3 .1)        Restated Certificate of Incorporation, incorporated herein by     reference to Exhibit 3.1 to Amendment No. 7 to our     Registration Statement on Form S-1, filed June 28,     2005 (File No. 333-123635).         (3 .2)        Amended and Restated Bylaws, incorporated herein by reference to     Exhibit 3.2 to Amendment No. 7 to our Registration     Statement on Form S-1, filed June 28, 2005 (File     No. 333-123635).         (4 .1)        Specimen Class A Common Stock Certificate, incorporated     herein by reference to Exhibit 4.1 to Amendment No. 7     to our Registration Statement on Form S-1, filed     June 28, 2005 (File No. 333-123635).         (4 .2)        Specimen Class B Common Stock Certificate, incorporated     herein by reference to Exhibit 4.2 to Amendment No. 7     to our Registration Statement on Form S-1, filed     June 28, 2005 (File No. 333-123635).         (9 .1)        Amended and Restated Trust Agreement dated     September 24, 2004, by and among NeuStar, Inc., the     stockholders named therein and the trustees named therein,     incorporated herein by reference to Exhibit 9.1 to     Amendment No. 7 to our Registration Statement on     Form S-1, filed June 28, 2005 (File     No. 333-123635).         (10 .1)        Contractor services agreement entered into the 7th day of     November 1997 by and between NeuStar, Inc. and North American     Portability Management LLC, as amended, incorporated herein by     reference to Exhibit 10.1 to our Quarterly Report on     Form 10-Q, filed August 15, 2005.**         10 .1.1        Amendment, effective May 31, 2003, to the contractor     services agreement by and between NeuStar, Inc. and North     American Portability Management LLC, as amended.         (10 .2)        Contractor services agreement, restated as of June 1, 2003,     by and between Canadian LNP Consortium Inc. and NeuStar, Inc.,     as amended, incorporated herein by reference to     (a) Exhibit 10.2 to Amendment No. 6 to our     Registration Statement on Form S-1, filed June 28,     2005 (File No. 333-123635); and     (b) Exhibit 10.2.1 to our Quarterly Report on     Form 10-Q, filed August 15, 2005.**         10 .2.1        Amendment, entered into as of December 19, 2005, to the     contractor services agreement between Canadian LNP Consortium     Inc. and NeuStar, Inc.**         10 .2.2        Amendment, entered into as of January 20, 2006, to the     contractor services agreement between Canadian LNP Consortium     Inc. and NeuStar, Inc.**         (10 .3)        National Thousands-Block Pooling Administration agreement     awarded to NeuStar, Inc. by the Federal Communications     Commission, effective June 14, 2001, incorporated herein by     reference to (a) Exhibit 10.3 to Amendment No. 6     to our Registration Statement on Form S-1, filed     June 28, 2005 (File No. 333-123635);     (b) Exhibit 10.3.1 to our Quarterly Report on     Form 10-Q, filed August 15, 2005;     (c) Exhibit 10.3.2 to our Current Report on     Form 8-K, filed September 15, 2005; and     (d) Exhibit 10.3.3 to our Quarterly Report on     Form 10-Q, filed November 14, 2005.         (10 .4)        North American Numbering Plan Administrator agreement awarded to     NeuStar, Inc. by the Federal Communications Commission,     effective July 9, 2003, incorporated herein by reference to     (a) Exhibit 10.4 to Amendment No. 7 to our     Registration Statement on Form S-1, filed June 28,     2005 (File No. 333-123635); and     (b) Exhibit 10.4.1 to our Current Report on     Form 8-K, filed September 15, 2005.         10 .4.1        Amendment, effective November 12, 2003, to the North     American Numbering Plan Administrator agreement awarded to     NeuStar, Inc. by the Federal Communications Commission,     effective July 9, 2003.    81                     Exhibit       Number   Description of Exhibit                 (10 .5)        .us Top-Level Domain Registry Management and Coordination     agreement awarded to NeuStar, Inc. by the National Institute of     Standards and Technology on behalf of the Department of Commerce     on October 26, 2001, incorporated herein by reference to     (a) Exhibit 10.5 to Amendment No. 7 to our     Registration Statement on Form S-1, filed June 28,     2005 (File No. 333-123635); (b) Exhibit 10.5.1 to     our Quarterly Report on Form 10-Q, filed November 14,     2005; and (c) Exhibit 10.5.2 to our Quarterly Report     on Form 10-Q, filed November 14, 2005.         (10 .6)        Registry Agreement by and between the Internet Corporation for     Assigned Names and Numbers and NeuLevel, Inc., dated as of     May 11, 2001, incorporated herein by reference to     Exhibit 10.6 to Amendment No. 1 to our Registration     Statement on Form S-1, filed April 8, 2005 (File     No. 333-123635).         (10 .7)        Common Short Code License Agreement made and entered into     October 17, 2003, by and between the Cellular     Telecommunications and Internet Association and NeuStar, Inc.,     incorporated herein by reference to Exhibit 10.7 to     Amendment No. 7 to our Registration Statement on     Form S-1, filed June 28, 2005 (File     No. 333-123635).**         10 .7.1        Amendment, entered into on January 31, 2006, to Common     Short Code License Agreement between the Cellular     Telecommunications and Internet Association and NeuStar, Inc.         (10 .8)        NeuStar, Inc. 1999 Equity Incentive Plan (the “1999     Plan”), incorporated herein by reference to     Exhibit 10.8 to Amendment No. 3 to our Registration     Statement on Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .9)        NeuStar, Inc. 2005 Stock Incentive Plan (the “2005     Plan”), incorporated herein by reference to     Exhibit 10.9 to Amendment No. 3 to our Registration     Statement on Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .10)        Incentive Stock Option Agreement under the 1999 Plan, made as of     April 10, 2000, by and between NeuStar, Inc. and Jeffrey     Ganek, incorporated herein by reference to Exhibit 10.10 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .11)        Incentive Stock Option Agreement under the 1999 Plan, made as of     April 10, 2000, by and between NeuStar, Inc. and Mark     Foster, incorporated herein by reference to Exhibit 10.11     to Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .12)        Incentive Stock Option Agreement under the 1999 Plan, made as of     March 26, 2002, by and between NeuStar, Inc. and Michael     Lach, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.12 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .13)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of March 26, 2002, by and between NeuStar, Inc. and Michael     Lach, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.13 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .14)        Incentive Stock Option Agreement under the 1999 Plan, made as of     June 6, 2002, by and between NeuStar, Inc. and Jeffrey     Ganek, incorporated herein by reference to Exhibit 10.14 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .15)        Incentive Stock Option Agreement under the 1999 Plan, made as of     June 6, 2002, by and between NeuStar, Inc. and Mark Foster,     incorporated herein by reference to Exhibit 10.15 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .16)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of June 6, 2002, by and between NeuStar, Inc. and Jeffrey     Ganek, incorporated herein by reference to Exhibit 10.16 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).†    82                     Exhibit       Number   Description of Exhibit                 (10 .17)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of June 6, 2002, by and between NeuStar, Inc. and Mark     Foster, incorporated herein by reference to Exhibit 10.17     to Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .18)        Incentive Stock Option Agreement under the 1999 Plan, made as of     January 16, 2003, by and between NeuStar, Inc. and John     Malone, as amended as of December 18, 2003 and as of     June 22, 2004, incorporated herein by reference to     Exhibit 10.18 to Amendment No. 1 to our Registration     Statement on Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .19)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of January 16, 2003, by and between NeuStar, Inc. and John     Malone, as amended as of December 18, 2003 and as of     June 22, 2004, incorporated herein by reference to     Exhibit 10.19 to Amendment No. 1 to our Registration     Statement on Form S-1, filed April 8, 2005 (File     No. 333-123635).†         (10 .20)        Incentive Stock Option Agreement under the 1999 Plan, made as of     December 18, 2003, by and between NeuStar, Inc. and Jeffrey     Ganek, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.20 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .21)        Incentive Stock Option Agreement under the 1999 Plan, made as of     December 18, 2003, by and between NeuStar, Inc. and Michael     Lach, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.21 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .22)        Incentive Stock Option Agreement under the 1999 Plan, made as of     December 18, 2003, by and between NeuStar, Inc. and Mark     Foster, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.22 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .23)        Incentive Stock Option Agreement under the 1999 Plan, made as of     December 18, 2003, by and between NeuStar, Inc. and John     Malone, as amended as of June 22, 2004 and May 20,     2005, incorporated herein by reference to Exhibit 10.23 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .24)        Nonqualified Option Agreement under the 1999 Plan, made as of     December 18, 2003, by and between NeuStar, Inc. and Jeffrey     Ganek, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.24 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .25)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of December 18, 2003, by and between NeuStar, Inc. and     Michael Lach, as amended as of June 22, 2004, incorporated     herein by reference to Exhibit 10.25 to Amendment     No. 1 to our Registration Statement on Form S-1, filed     April 8, 2005 (File No. 333-123635).†         (10 .26)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of December 18, 2003, by and between NeuStar, Inc. and Mark     Foster, as amended as of June 22, 2004, incorporated herein     by reference to Exhibit 10.26 to Amendment No. 1 to     our Registration Statement on Form S-1, filed April 8,     2005 (File No. 333-123635).†         (10 .27)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of December 18, 2003, by and between NeuStar, Inc. and John     Malone, as amended as of June 22, 2004 and May 20,     2005, incorporated herein by reference to Exhibit 10.27 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .28)        Incentive Stock Option Agreement under the 1999 Plan, made as of     June 22, 2004, by and between NeuStar, Inc. and Jeffrey     Babka, as amended as of May 20, 2005, incorporated herein     by reference to Exhibit 10.28 to Amendment No. 3 to     our Registration Statement on Form S-1, filed May 27,     2005 (File No. 333-123635).†         (10 .29)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of June 22, 2004, by and between NeuStar, Inc. and Jeffrey     Babka, as amended as of May 20, 2005, incorporated herein     by reference to Exhibit 10.29 to Amendment No. 3 to     our Registration Statement on Form S-1, filed May 27,     2005 (File No. 333-123635).†    83                     Exhibit       Number   Description of Exhibit                 (10 .30)        Phantom Stock Unit Agreement under the 1999 Plan, made as of     July 19, 2004, by and between NeuStar, Inc. and Michael R.     Lach, incorporated herein by reference to Exhibit 10.30 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .31)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of April 10, 2000, by and between NeuStar, Inc. and Henry     Geller, incorporated herein by reference to Exhibit 10.31     to Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .32)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of April 10, 2000, by and between NeuStar, Inc. and Henry     Kressel, incorporated herein by reference to Exhibit 10.32     to Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .33)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of April 10, 2000, by and between NeuStar, Inc. and Joe     Landy, incorporated herein by reference to Exhibit 10.33 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .34)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of April 10, 2000, by and between NeuStar, Inc. and Ken     Pickar, incorporated herein by reference to Exhibit 10.34     to Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .35)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of February 14, 2005, by and between NeuStar, Inc. and Jim     Cullen, incorporated herein by reference to Exhibit 10.35     to Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .36)        Nonqualified Stock Option Agreement under the 1999 Plan, made as     of February 14, 2005, by and between NeuStar, Inc. and     Frank Schiff, incorporated herein by reference to     Exhibit 10.36 to Amendment No. 1 to our Registration     Statement on Form S-1, filed April 8, 2005     (File No. 333-123635).†         (10 .37)        Loudoun Tech Center Office Lease by and between Merritt-LT1,     LLC, Landlord, and NeuStar, Inc., Tenant, incorporated herein by     reference to Exhibit 10.37 to Amendment No. 2 to our     Registration Statement on Form S-1, filed May 11, 2005     (File No. 333-123635).         (10 .38)        Credit Agreement, dated as of August 14, 2002, among     NeuStar, Inc., Bank of America, N.A., and other lenders,     incorporated herein by reference to(a) Exhibit 10.38     to Amendment No. 2 to our Registration Statement on     Form S-1, filed May 11, 2005 (File     No. 333-123635); and(b) Exhibit 10.38.1 to our     Quarterly Report on Form 10-Q, filed August 15, 2005.         10 .38.1        Amendment, dated February 15, 2005, to the Credit     Agreement, dated as of August 14, 2002, among NeuStar,     Inc., Bank of America, N.A., and other lenders.         10 .38.2        Amendment, dated February 10, 2006, to the Credit     Agreement, dated August 14, 2002, among NeuStar, Inc., Bank     of America, N.A., and other lenders.         (10 .39)        NeuStar, Inc. Annual Performance Incentive Plan, incorporated     herein by reference to Exhibit 10.40 to Amendment     No. 3 to our Registration Statement on Form S-1, filed     May 27, 2005 (File No. 333-123635).†         (10 .40)        NeuStar, Inc. 2005 Key Employee Severance Pay Plan, incorporated     herein by reference to Exhibit 10.41 to Amendment     No. 3 to our Registration Statement on Form S-1, filed     May 27, 2005 (File No. 333-123635).†         (10 .41)        Executive Relocation Policy, incorporated herein by reference to     Exhibit 10.42 to Amendment No. 3 to our Registration     Statement on Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .42)        Employment Continuation Agreement, made as of April 8,     2004, by and between NeuStar, Inc. and Jeffrey Ganek,     incorporated herein by reference to Exhibit 10.43 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†    84                     Exhibit       Number   Description of Exhibit                 (10 .43)        Employment Continuation Agreement, made as of April 8,     2004, by and between NeuStar, Inc. and Mark Foster, incorporated     herein by reference to Exhibit 10.44 to Amendment     No. 3 to our Registration Statement on Form S-1, filed     May 27, 2005 (File No. 333-123635).†         (10 .44)        Form of Restricted Stock Agreement under the 2005 Plan,     incorporated herein by reference to Exhibit 10.45 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .45)        Form of Nonqualified Stock Option Agreement under the 2005 Plan,     incorporated herein by reference to Exhibit 10.46 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .46)        Form of Incentive Stock Option Agreement under the 2005 Plan,     incorporated herein by reference to Exhibit 10.47 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .47)        Summary of relocation arrangement with Jeffrey A. Babka,     incorporated herein by reference to Exhibit 10.48 to     Amendment No. 3 to our Registration Statement on     Form S-1, filed May 27, 2005 (File     No. 333-123635).†         (10 .48)        Form of Indemnification Agreement, incorporated herein by     reference to Exhibit 10.49 to Amendment No. 5 to our     Registration Statement on Form S-1, filed June 10,     2005 (File No. 333-123635).†         (10 .49)        Stockholders Agreement, dated June 28, 2005, by and among     NeuStar, Inc. and the stockholders named therein, incorporated     herein by reference to Exhibit 4.3 to our Quarterly Report     on Form 10-Q, filed August 15, 2005.         (10 .50)        Registration Rights Agreement, dated as of June 5, 2001, by     and among NeuStar, Inc. and the stockholders named therein,     incorporated herein by reference to Exhibit 4.4 to     Amendment No. 1 to our Registration Statement on     Form S-1, filed April 8, 2005 (File     No. 333-123635).         21 .1        Subsidiaries of NeuStar, Inc.         23 .1        Consent of Ernst & Young LLP.         24 .1        Power of Attorney (included on the signature page herewith).         31 .1        Chief Executive Officer Certification pursuant to     Section 302 of the Sarbanes-Oxley Act of 2002.         31 .2        Chief Financial Officer Certification pursuant to     Section 302 of the Sarbanes-Oxley Act of 2002.         32 .1        Certification pursuant to 18 U.S.C. Section 1350, as     adopted pursuant to Section 906 of the Sarbanes-Oxley Act     of 2002.         99 .1        Update to the Functional Requirements Specification, which is     attached as Exhibit B to the contractor services agreement     by and between NeuStar, Inc. and North American Portability     Management, LLC, filed with the Securities and Exchange     Commission as Exhibit 10.1 and Exhibit 10.1.1 to this     annual report on Form 10-K.         99 .2        Update to the Interoperable Interface Specification, which is     attached as Exhibit C to the contractor services agreement     by and between NeuStar, Inc. and North American Portability     Management, LLC, filed with the Securities and Exchange     Commission Exhibit 10.1 and Exhibit 10.1.1 to this     annual report on Form 10-K.               †       Compensation arrangement.          **       Confidential treatment has been requested or granted for     portions of this document. The omitted portions of this document     have been filed with the Securities and Exchange Commission.   85          SIGNATURES        Pursuant to the requirements of Section 13 or 15(d) of the Securities Exchange Act of 1934, the registrant has duly caused this report to be signed on its behalf by the undersigned, thereunto duly authorized on March 29, 2006.                NEUSTAR, INC.             By:       /s/ Jeffrey E. Ganek                       Jeffrey E. Ganek      Chairman of the Board of Directors      and Chief Executive Officer         We, the undersigned directors and officers of NeuStar, Inc., hereby severally constitute Jeffrey E. Ganek and Martin K. Lowen, and each of them singly, our true and lawful attorneys with full power to them and each of them to sign for us, in our names in the capacities indicated below, any and all amendments to this Annual Report on Form 10-K filed with the Securities and Exchange Commission.        Pursuant to the requirements of the Securities Act of 1934, this report has been signed below by the following persons on behalf of the registrant and in the capacities indicated on March 29, 2006.                 Signature   Title                    /s/ Jeffrey E. Ganek Jeffrey E. Ganek        Chairman of the Board of Directors and Chief Executive Officer     (Principal Executive Officer)            /s/ Jeffrey A. Babka Jeffrey A. Babka        Senior Vice President and Chief Financial Officer (Principal     Financial Officer and     Principal Accounting Officer)            /s/ James G. Cullen James G. Cullen        Director            /s/ Henry Geller Henry Geller        Director            /s/ Joseph P. Landy Joseph P. Landy        Director            /s/ Dr. Kenneth A. Pickar Dr. Kenneth A. Pickar        Director            /s/ Frank L. Schiff Frank L. Schiff        Director    86      EX-10.1.1 2 w17665exv10w1w1.htm EX-10.1.1    exv10w1w1       Exhibit 10.1.1  Amendment No. 38 5/28/03 SOW: oYes þNo  [Graphic Omitted: NeuStar Logo]  AMENDMENT OF SLR-27  UNDER  AGREEMENT FOR NUMBERING ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM   Page 1       Amendment No. 38 5/28/03 SOW: oYes þNo  AMENDMENT OF SLR-27  UNDER  AGREEMENT FOR NUMBERING ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM     1.   PARTIES.    This amendment (this “Amendment”) is entered into pursuant to Article 30 of, and upon execution shall be a part of, the Agreement for Number Portability Administration Center/Service Management System (the “Master Agreement”) by and between NeuStar, Inc., a Delaware corporation (“Contractor”) and the North American Portability Management LLC, a Delaware limited liability company (the “Customer” or “NAPM”), as the successor in interest to and on behalf of the respective limited liability companies listed below for the separate Service Areas (referred to individually as a “Subscribing Customer” and collectively as the “Subscribing Customers”):       •   LNP, LLC (Midwest)        •   Mid-Atlantic Carrier Acquisition Company, LLC        •   Northeast Carrier Acquisition Company, LLC        •   Southeast Number Portability Administration Company, LLC        •   Southwest Region Portability Company, LLC        •   West Coast Portability Services, LLC        •   Western Region Telephone Number Portability, LLC       2.   EFFECTIVNESS.    This Amendment shall be effective as of [the 31st day of May, 2003] (the “Amendment Effective Date”) only upon execution of separate amendments by Contractor and Customer. The number in the upper left-hand corner refers to this Amendment. Capitalized terms used herein without definition shall have the meanings as defined in the Master Agreement.     3.   SCOPE.    The parties desire to amend SLR-27 to reflect the incorporation of electronic media into Contractor’s delivery processes. Therefore, SLR-27 is hereby amended by replacing the word “Mail” with “Provide” under the Service Commitment Level column.  Upon execution of this Amendment, Contractor will provide the amended definition of SLR-27 to its Gateway Evaluation Process (“GEP”) auditor.     4.   COMPLETION AND ACCEPTANCE CRITERIA.     Page 2          Amendment No. 38 5/28/03 SOW: oYes þNo  The following internal documents are applicable under this Amendment:                         N/A    Functional Requirements Specifications                     N/A    Requirements Traceability Matrix                     N/A    External Design                     N/A    System Design                     N/A    Detailed Design                     N/A    Integration Test Plan                     N/A    System Test Plan                     N/A    Software Quality Assurance Program Report                     Ö    User Documentation                     N/A    Software Configuration Management Plan                     Ö    Standards and Metrics                     5.   IMPACTS ON MASTER AGREEMENT    The following Master Agreement documents are impacted by this Amendment:                         None    Master Agreement                     None    Exhibit B Functional Requirements Specification                     None    Exhibit C Interoperable Interface Specification                     None    Exhibit E Pricing Schedules                     None    Exhibit F Project Plan and Test Schedule                     Ö    Exhibit G Service Level Requirements                     None    Exhibit H Reporting and Monitoring Requirements                     None    Exhibit J User Agreement Form                     None    Exhibit K External Design                     None    Exhibit L Infrastructure/Hardware                     None    Exhibit N System Performance Plan for NPAC/SMS Services                     6.   PRICING.    There are no pricing impacts under this Amendment.     7.   CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT.    Except as specifically modified and amended hereby (including by the SOW Specifications where applicable), all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms. From and after the date hereof, any reference in either the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit as modified and amended by this SOW. From and after the   Page 3       Amendment No. 38 5/28/03 SOW: oYes þNo  effectiveness of this SOW, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.     8.   MISCELLANEOUS.         8.1   Counterparts.    This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document. All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.       8.2   Entire Agreement.    This SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supercedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  [THIS SPACE INTENTIONALLY LEFT BLANK]   Page 4       Amendment No. 38 5/28/03 SOW: oYes þNo  IN WITNESS WHEREOF, the undersigned have executed this Amendment:                    CONTRACTOR: NeuStar, Inc.    By:    /s/ C Walker                    Its:    VP Customer Ops                    Date:    6-9-03                                CUSTOMER: North American Portability Management, LLC    By:    /s/ Richard Theiss                    Its:    Co-Chair                    Date:    11 June, 2003                                CUSTOMER: North American Portability Management, LLC    By:    /s/ Pamela H. Connell                    Its:    Co-Chair                    Date:    June 16, 2003                       Page 5       EX-10.2.1 3 w17665exv10w2w1.htm EX-10.2.1    exv10w2w1       Exhibit 10.2.1  Pursuant to 17 CFR 240.24b-2, confidential information has been omitted in places marked [* * *]and has been filed separately with the Securities and Exchange Commission pursuant to a Confidential Treatment Application filed with the Commission.  CANADIAN NPAC/SMS CONTRACTOR SERVICES AGREEMENT AMENDING AGREEMENT  THIS AMENDING AGREEMENT is made and entered into with effect as of the day of October, 2005.  BETWEEN:  CANADIAN LNP CONSORTIUM, INC., a corporation incorporated under the laws of Canada (“Customer”),  - and -  NEUSTAR, INC., a corporation incorporated under the laws of Delaware (“Contractor”)  WHEREAS pursuant to a Contractor Services Agreement made and entered into as of May 19, 1998 by and between Customer and Lockheed Martin IMS Corporation (as amended and assigned on November 30, 1999 by Lockheed Martin IMS Corporation to Contractor) (the “Contractor Services Agreement”), Contractor has provided the NPAC/SMS Services to Users pursuant to User Agreements (as those terms are defined in the Contractor Services Agreement);  AND WHEREAS by amending agreement dated March 31, 2003, the Contractor Services Agreement was amended, inter alia, to extend the term thereof to May 31, 2007;  AND WHEREAS pursuant to a letter agreement dated September 12, 2005 between Customer and Contractor (the “Letter Agreement”), Customer and Contractor renewed the Contractor Services Agreement to December 31, 2011 (the “Renewal Term”), all upon and subject to the terms and conditions contained in the Letter Agreement;  AND WHEREAS the Letter Agreement contemplates the execution and delivery of this Canadian NPAC/SMS Contractor Services Agreement Amending Agreement (the “Amending Agreement”), on the terms and conditions described in the Letter Agreement, in order to fully implement the Letter Agreement;  NOW, THEREFORE, THIS AGREEMENT WITNESSETH that in consideration of the covenants and agreements hereinafter contained, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged by each of the parties hereto, the parties hereto covenant and agree as follows:   Page 1          1.   Effective Date    The Effective Date of the Contractor Services Agreement is amended by deleting “June 1, 2003” and substituting “September 12, 2005” therefor.     2.   Business Day    Section 1.7 of the Contractor Services Agreement is amended by deleting “Easter” and substituting “Good Friday” therefor.     3.   Term    Article 3 of the Contractor Services Agreement is amended by deleting “May 31, 2007” and substituting “December 31, 2011” therefor.     4.   Pricing and Adjustment    Article 6 of the Contractor Services Agreement is hereby amended by renumbering “Section 6.1 General” as “Section 6.1(a)”, and adding the following:  (b) One Time Credit. Contractor shall on or before December 31, 2005 pay, by way of credit, the amount of $[* * *] (the “One Time Credit”) for the benefit of, and for distribution among, the Users who are shareholders of the Customer (the “Canadian Users”). The One Time Credit shall be payable by Contractor in the manner stipulated in writing by the Customer in a direction delivered to Contractor, which direction shall be delivered to Contractor no later than November 30, 2005. For greater certainty, the Parties expressly acknowledge and agree that the One Time Credit may, in the sole discretion of the Customer expressed in the direction described in the immediately preceding sentence, be payable by Contactor: (i) by way of credit against future Canadian User payment obligations to Contractor (as directed by the Customer); or (ii) by way of payment to the Customer of the One Time Credit (or a combination of (i) and (ii)), within thirty (30) days of receipt by Contractor of the direction described in this Section 6.1(b). For greater certainty, if the amount of any such credit allocated to any Canadian User, as described in (i) in the immediately preceding sentence, exceeds any such Canadian User’s payment obligations to Contractor in the month in which such credit is allocated by Contractor (as described in the immediately preceding sentence), the net amount of such credit in respect of any such Canadian User shall be applied in the next following month, and so on, until such credit is exhausted, unless otherwise directed by the Customer.  (c) Fixed Annual Credit. Subject to the requirements set forth below in this Section 6.1(c), Contractor shall, in each calendar year during the Initial Term beginning in 2006, pay an annual credit in the amount of $[* * * ] for the benefit of, and for distribution among, the Canadian Users (each a “Fixed Annual Credit”). The Fixed Annual Credit shall be payable by Contractor in the manner stipulated in writing by the Customer in a   Page 2       direction delivered to Contractor, which direction shall be delivered to Contractor for each applicable calendar year no later than November 30 of that calendar year during the Initial Term beginning in 2006 . For greater certainty, the Parties expressly acknowledge and agree that the Fixed Annual Credit may, in the sole discretion of the Customer expressed in the direction described in the immediately preceding sentence, be payable by Contractor: (i) by way of credit against future Canadian User payment obligations to Contactor (as directed by the Customer); or (ii) by way of payment to the Customer of the Fixed Annual Credit (or a combination of (i) and (ii)), within thirty (30) days after both (A) Contractor receives the direction described in this Section 6.1(c), and (B) the annual, aggregate volume of executed Ported TN Events exceeds the applicable thresholds set forth below. For greater certainty, if the amount of any such credit allocated to any Canadian User, as described in (i) in the immediately preceding sentence, exceeds any such Canadian User’s payment obligations to the Contractor in the month in which such credit is applied by Contractor (as described in the immediately preceding sentence), the net amount of such credit in respect of any such Canadian User shall be applied in the next following month, and so on, until such credit is exhausted, unless otherwise directed by Customer. The Fixed Annual Credit shall only be payable by Contractor for each calendar year if Canadian Users, in the aggregate for each applicable calendar year, execute: (i) in the calendar year 2006, more than [* * * ] TN Porting Events; (ii) in the calendar year 2007, more than [* * * ]TN Porting Events; (iii) in the calendar year 2008, more than [* * *] TN Porting Events; (iv) in the calendar year 2009, more than [* * *] TN Porting Events; (v) in the calendar year 2010, more than [* * * ]TN Porting Events; and (vi) in the calendar year 2011, more than [* * * ] TN Porting Events. Notwithstanding anything in this Section 6.1(c) to the contrary, if the number of TN Porting Events in any calendar year does not exceed the volume thresholds set forth in the immediately preceding sentence, then that calendar year’s Fixed Annual Credit forever expires, and in no event shall such Fixed Annual Credit be available or otherwise be used in a subsequent calendar year, provided that neither Party will be prejudiced by any error or mistake in calculating the aggregate number of TN Porting Events described in the immediately preceding sentence. Upon the discovery of any such error the Parties will promptly, and in good faith correct such error, including any adjustment as may be required under this Section.  (d) No Withholding or Deduction. All applicable credits and amounts payable described in Section 6.1(b) and Section 6.1(c) shall be applied and paid, as described herein, without withholding or any deduction whatsoever.     5.   Amendment to License    Section 9.2 of the Contractor Services Agreement is amended by adding, as the penultimate sentence:  “The license described in the immediately preceding sentence shall also contain the right of the Contractor, following any Extension Period (as defined in Section 24.3), to review and examine records of the Customer and Users, under reasonable terms and conditions, for the sole purpose of assessing compliance   Page 3       with the obligations of the Customer and the Users in the last paragraph of Section 24.3(a)(ii) and Section 24.3(b)(ii).”     6.   Transition at Expiration or Termination of the Agreement    Section 24.3 and Section 24.4 of the Contractor Services Agreement are deleted in their entirety, and the following substituted therefor:  24.3 Termination Plan.  The Contractor and Customer will, within ninety (90) Business Days of the execution and delivery by the Contractor and Customer of a renewal of this Agreement for a period ending December 31, 2011, agree upon a termination plan (the “Termination Plan”), which shall incorporate the following agreements and understandings between the Parties (and including, for greater certainty, the agreements and understandings contained in Article 24.2 and Article 24.4):  (a) Contractor’s Obligation to Assist with Transition — Contractor Termination Event or Contractor Non-Renewal. Upon either: (i) termination of this Agreement by Customer under Section 23.1 (a “Contractor Termination Event”); or (ii) expiration of this Agreement as a result of an election by Contractor not to renew this Agreement under Article 3 in respect of the Term (“Contractor Non-Renewal”), Contractor shall assist Customer in the orderly transition of the Canadian NPAC/SMS and Canadian NPAC/SMS Services from Contractor to a Successor Contractor, in accordance with the following requirements.  Contractor shall, upon thirty (30) Business Days prior written notice from Customer, at the direction and in the sole and exclusive discretion of Customer:       (i)   extend the provision of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services as directed by the Customer for that period (the “Extension Period”) ending on the earlier of:         1.   that date upon which Customer and Users complete transition to a Successor Contractor for the provision and administration of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services; and        2.   eight (8) months following: (A) the delivery of the notice of termination in respect of a Contractor Termination Event, in the case of a Contractor Termination Event; and (B) the effective date of the Contractor Non-Renewal, in the case of a Contractor Non-Renewal; and         (ii)   license to Customer the Canadian NPAC/SMS Software as directed by the Customer in accordance with Article 9 of this Agreement and subject to Exhibit L.     Page 4          For greater certainty, the license to the Canadian NPAC/SMS Software shall include any Maintenance Modifications created by Contractor during the Extension Period, Enhancements that are subject to a continuing payment obligation under a Statement of Work, Enhancements that are not subject to continuing obligations under a Statement of Work that contain modifications or revisions to the NPAC/SMS Software to correct defects or are necessary for the day to day functionality of the NPAC/SMS (when such modifications or revisions were not otherwise made available to the Customer in a Maintenance Modification or other Enhancement), and Enhancements for which the payments have been completed. To the extent that the Canadian NPAC/SMS Software that is subject to the license contains functionality not purchased by Customer, subject to the foregoing provisions contained in this paragraph, neither Customer, Successor Contractor, nor any User shall be entitled to use or receive such functionality as part of the license.  During any Extension Period contemplated in Section 24.3(a)(i), the Canadian NPAC/SMS Services shall meet or exceed the Service Levels and otherwise be provided in accordance with the applicable provisions of this Agreement, including, but not limited to, the Service Levels in effect on the date of such termination or expiration of the Agreement, as applicable. Without restricting the generality of the foregoing, Contractor shall also provide the Transition Services contemplated in Section 24.4 requested by Customer; provided that Contractor shall have no obligation to perform any such Transition Services after the end of the Extension Period. Notwithstanding the foregoing obligations of Contractor, Contractor’s obligation to perform the Canadian NPAC/SMS Services during any Extension Period described in this Section 24.3(a) shall be subject to Customer using reasonable and diligent efforts to transition to a Successor Contractor beginning no later than: (i) in the case of a Contractor Termination Event, the date of delivery of the notice of termination related to the Contractor Termination Event, or (ii) in the case of Contractor Non-Renewal, the date Contractor delivers the notice of the Contractor Non-Renewal.  (b) Contractor’s Obligation to Assist With Transition — Customer Non-Renewal. Upon expiration of this Agreement as a result of any election by the Customer not to renew this Agreement under Article 3 in respect of the Term, (“Customer Non-Renewal”), Contractor shall assist the Customer in the orderly transition of the Canadian NPAC/SMS and Canadian NPAC/SMS Services from Contractor to a Successor Contractor in accordance with the following requirements.  Contractor shall, upon thirty (30) Business Days prior written notice from the Customer, at the direction and in the sole and exclusive discretion of the Customer:       (i)   extend the provision of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services as directed by the Customer for that period of time (also, the “Extension Period”) ending on the earlier of:     Page 5               1.   that date upon which Customer and Users complete transition to a Successor Contractor for the provision and administration of the Canadian NPAC/SMS and the Canadian NPAC/SMS Services; and        2.   eight (8) months following the effective date of the Customer Non-Renewal; and         (ii)   license to Customer the Canadian NPAC/SMS Software, as directed by the Customer, in accordance with Article 9 of this Agreement and subject to Exhibit L.    For greater certainty, the license to the Canadian NPAC/SMS Software shall include any Maintenance Modifications created by Contractor during the Extension Period, Enhancements that are subject to a continuing payment obligation under a Statement of Work, Enhancements that are not subject to continuing obligations under a Statement of Work that contain modifications or revisions to the NPAC/SMS Software to correct defects or are necessary for the day to day functionality of the NPAC/SMS (when such modifications or revisions were not otherwise made available to the Customer in a Maintenance Modification or other Enhancement), and Enhancements for which the payments have been completed. To the extent that the Canadian NPAC/SMS Software that is subject to the license contains functionality not purchased by Customer, subject to the foregoing provisions contained in this paragraph, neither Customer, Successor Contractor, nor any User shall be entitled to use or receive such functionality as part of the license.  During any Extension Period contemplated in Section 24.3(b)(i) the Canadian NPAC/SMS Services shall meet or exceed the Service Levels and otherwise be provided in accordance with the applicable provisions of this Agreement, including, but not limited to, the Service Levels in effect on the date of such termination or expiration of the Agreement, as applicable. Without restricting the generality of the foregoing, Contractor shall also provide the Transition Services contemplated in Section 24.4 requested by the Customer; provided that Contractor shall have no obligation to perform any such Transition Services after the end of the Extension Period. Notwithstanding the foregoing obligations of Contractor, Contractor’s obligation to perform the Canadian NPAC/SMS Services during any Extension Period described in this Section 24.3(b) is subject to the Customer using reasonable and diligent efforts to transition to a Successor Contractor beginning no later than the date of delivery, by the Customer, of the notice of Customer Non-Renewal.  (c) Incorporation into Agreement. The Termination Plan when completed shall be incorporated into this Agreement as Exhibit P.  24.4 Transition Services.   Page 6       Without limiting the obligations of Contractor in Section 24.2, Section 24.3(a) and Section 24.3(b), Contractor shall assist and cooperate with Customer in effecting the orderly transition of the Canadian NPAC/SMS and Canadian NPAC/SMS Services to a Successor Contractor by performing the obligations set forth below (collectively, the “Transition Services”) where requested by Customer. The Transition Services shall be provided through any Extension Period under Section 24.2, Section 24.34(a) or Section 24.3(b), as the case may be, or, if the Agreement is not being extended pursuant to such Sections, a period not to exceed eight (8) months after the expiration or termination of the Agreement. Customer shall submit its request for Transition Services in writing to Contractor on or forthwith following the delivery of the applicable notice of non-renewal or termination, as the case may be, described in Section 24.2 or Section 24.3. Contractor and Customer shall, within ten (10) days after Customer’s request for Transition Services, each appoint a representative (the “Transition Team”) who shall, jointly, deliver a preliminary transition plan within twenty (20) days following the appointment of the Transition Team, and shall produce a final plan within twenty (20) days following the joint submission of the preliminary plan, which plans shall set forth the methods and procedures for Customer and Contractor to manage the Transition Services (collectively, the “Transition Plan”). In the event of a failure of agreement, in good faith, on the Transition Plan, the Transition Plan shall be the plan as reasonably directed by Customer. The Transition Team shall meet no less frequently than monthly, acting reasonably, and shall take all steps reasonably necessary to facilitate implementation of the Transition Plan, including meeting by electronic means (including by telephone or other convenient means of communication) no less than daily for the purpose of reporting on matters related to the transition described in this Article, including all issues related thereto. Subject to the foregoing, Contractor agrees to promptly provide the following Transition Services in accordance with this Section 24.4:  (a) provide Customer with a description, in level of detail determined by Customer in its discretion acting reasonably, of all hardware, software, and communications inventories and documentation of operational and procedural practices required for the orderly transition to a Successor Contractor for the Canadian NPAC/SMS and Canadian NPAC/SMS Services, in no event in any less detail than that required of the Contractor under Section 1.1 of Exhibit M (Software Escrow Agreement);  (b) provide Customer and/or its designees (including the Successor Contractor) all information, in a level of detail determined by Customer in its discretion acting reasonably, necessary to enable Customer and/or its designees (including the Successor Contractor) to provide the Canadian NPAC/SMS Services;  (c) with respect to any Third Party Software used to provide the Canadian NPAC/SMS Services, Contractor shall provide commercially reasonable assistance to Customer in obtaining, at Customer’s cost, all licenses (and applicable consents, if any) from all applicable vendors necessary for Customer or Successor Contractor to provide the NPAC/SMS Services, as may be reasonably directed by Customer;   Page 7       (d) with respect to any other third party agreements related to or used by Contractor in the delivery of the Services, Contractor shall transfer or assign such agreements (and applicable consents, if any) to Customer or the Successor Contractor, as reasonably directed by Customer, to the extent allowed under those third party agreements;  (e) Contractor shall return to Customer (without retaining copies): (1) all software, documentation, procedures, and other information and materials (including without limitation all tapes, disks, and printed matter) provided by Customer and Users, and (2) the contents of the Canadian NPAC/SMS database, including without limitation all User Data;  (f) Customer’s representatives shall have access at all reasonable times, and in a manner so as not to interfere with the normal business operations of the Contractor, to all Contractor employees, contractors, and other representatives necessary to facilitate the transition of the Canadian NPAC/SMS to a Successor Contractor for the provision of the Services. The Contractor shall permit the co-location of Customer’s representatives with Contractor’s representatives who possess the requisite knowledge in relation to the Services; provided that such Customer’s representatives shall not include a former Contractor employee. The Contractor shall provide Customer’s representatives with access and entry to premises with privileges and on terms and conditions customarily available to consultants of the Contractor, including access to the locations, hardware, information systems, and data located at the premises of the Contractor relevant to the Canadian NPAC/SMS and necessary to manage the Transition Services under the Transition Plan; provided, however, that such representatives execute a commercially reasonable confidentiality agreement with Contractor, and comply with any reasonable Contractor provided workplace rules. Customer shall allow Contractor to use, at no charge, those Customer facilities necessary to perform the Transition Services for as long as Contractor is providing the Transition Services;  (g) Contractor shall make available copies of any policies, procedures and methods of the Contractor that have been implemented by the Contractor in relation to the provision of Canadian NPAC/SMS Services; provided that Contractor shall not be required to divulge any of its financial or other proprietary or Confidential Information, including when such information is contained in its books and records, or any other information relating to the Contractor’s management of its business. To the extent any such policies, procedures and methods are not in writing, the Contractor shall use its reasonable best efforts to impart such policies, procedures and methods verbally during the Extension Period;  (h) In addition to the discharge of the obligations contained herein, the Contractor shall cooperate in good faith with the Successor Contractor in relation to the Transition Services. Contractor hereby acknowledges and agrees that the performance of the Transition Services will transition the Canadian NPAC/SMS, and the provision of Canadian NPAC/SMS Services, to a Successor Contractor. Notwithstanding the foregoing, Contractor shall not be obligated to disclose any information, whether Confidential Information or otherwise, or provide access to Contractor’s facilities,   Page 8       locations, information systems, data, or personnel to a Successor Contractor beyond that specified herein as part of the Transition Services; and  (i) Contractor shall be compensated for the performance of the Transition Services on a time and materials basis as described herein. Contractor will invoice Customer: (i) its time, in accordance with its published standard labor rates, which shall, for the purposes hereof, be offered to the Customer at commercially reasonable rates premised on a base rate of $[* * *] US Dollars [* * *]; and (ii) materials, at Contractor’s cost, without administrative or other markups, provided that: (iii) in the case of a Contractor Termination Event, Contractor’s labor rates will be subject to a discount of [* * *] percent ([* * *]%); and (iv) in the case of a Contractor Non-Renewal, Contractor’s labor rates will be subject to a discount of [* * *] percent ([* * *]%). Contractor shall provide Customer with reasonable estimates of time and materials charges prior to providing Transition Services to Customer.”     7.   TN PORTING EVENT CHARGES    Schedule 1, Section 2 of Exhibit E of the Contractor Services Agreement is amended by deleting the entries in the third, fourth and fifth columns of the “TN Porting Event” row, and substituting the information set forth in the table below, entitled “TN Porting Event Charges”, therefor.  TN PORTING EVENT CHARGES                                          Price in USD                   (for each TN                   Porting Event                   within   Tiers   Tier Start*   Tier End*   TN Porting Events   applicable Tier)     Tier 1    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 2    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 3    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 4    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 5    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 6    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 7    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 8    [* * *]    [* * *]    [* * *]    $[* * *]   Tier 9    [* * *]    [* * *]    [* * *]    $[* * *]         *   The above tier volumes represent cumulative TN Porting Events measured from [* * *]. The price described above for each TN Porting Event is the price for each TN Porting Event within each Tier set forth above.  Exhibit E of the Contractor Services Agreement is further amended by adding the following paragraph immediately following the table appearing as Schedule 1 (as amended hereby), preceding Note 1:   Page 9       The TN Porting Event charges described in the TN Porting Event row in the foregoing table (the “Amended Rates”) shall be effective as of, and based on, volumes of TN Porting Events executed beginning on [* * *]. Notwithstanding the Amended Rates, if, in any calendar year, including 2005, Users who are shareholders of the Customer (“Canadian Users”), in the aggregate, execute more than [* * *] TN Porting Events, the TN Porting Event charge shall, for the balance of such calendar year in which such number of aggregate TN Porting Events shall have been executed, equal US$[* * * ]. For greater certainty, subject to the immediately preceding sentence, all TN Porting Events executed by Canadian Users in excess of [* * *] TN Porting Events in any calendar year shall be included in the TN Porting Events used to derive applicable TN Porting Event charges in the years following the year in which Canadian Users executed more than [* * * ] TN Porting Events.     8.   Royalty Calculation     The following is added as Article 32 to the Contractor Services Agreement:  “ARTICLE 32 – REVISION TO ROYALTY CALCULATION  On or before December 15, 2005 the Contractor Services Agreement shall be amended to reflect the following agreements between the Contractor and Customer, recognizing that the same are broadly drafted and that the expression of these terms, conditions and covenants in the Contractor Services Agreement will require further specific and detailed provisions:  (a) the license contained in Exhibit L to the Master Agreement and royalty calculation set forth in Paragraphs (m) through (o) in Exhibit L (Additional Terms and Conditions of Software License) of the Master Agreement shall be amended to reflect the following:       (i)   subject to paragraph (ii) immediately below, the license rights to the Canadian NPAC/SMS Software shall not include the use of functionality not purchased under a Statement of Work with Contractor. After the conclusion of any Extension Period, (as defined in Article 24 of the Contractor Services Agreement) Contractor shall have the right to audit Users for compliance with the foregoing;        (ii)   the license to the Canadian NPAC/SMS Software under Article 9 of the Contractor Services Agreement shall, for greater certainty, include: (A) any Maintenance Modifications created by Contractor during an Extension Period; (B) any Enhancements that are subject to continuing obligations under a Statement of Work; (C) any Enhancements not subject to a continuing obligation under a Statement of Work that contain modifications or revisions to the NPAC/SMS Software to correct defects or are necessary for the day to day functionality of the NPAC/SMS, when such modifications or revisions were not otherwise made available to the Customer in a Maintenance Modification or other Enhancement; and (D) Enhancements for which the payments have been completed;     Page 10               (iii)   the royalty calculation set forth in Paragraphs (m) through (o) in Exhibit L shall be rewritten to simplify its terms and conditions; and    (iv) the terms “Centralized NPAC LLCs” and “Centralized NPAC Agreements” shall be deleted and/or modified together with such other modification as may be necessary in order to clarify and ensure that the royalty calculation set forth in Paragraphs (m) through (o) in Exhibit L relates only functionality acquired by Users, to the exclusion of the United States users and any others. The parties agree, and Contractor represents and warrants, that if the Licence were to be in effect as of the execution date of this letter, the royalty payment under the existing provisions of Exhibit L would be $[* * *] dollars.”     9.   Conversion Factor    Unless otherwise specified, pricing in this Amending Agreement is set forth in US Dollars (USD). Any such pricing is subject to the requirements of SOW46, as revised, for converting US Dollars to Canadian Dollars.     10.   Consideration     Except as amended by this Amending Agreement, the Contractor Services Agreement (including, without restriction, the obligations of the Contractor related to the Canadian NPAC/SMS) is ratified by the parties hereto. The modifications and amendments made in this Amending Agreement were negotiated together, are interrelated with, and each is made in consideration of all of the other terms and conditions herein, (including, without restriction, the obligations of the Contractor related to the Canadian NPAC/SMS in this Amending Agreement).     11.   Amended and Restated Agreement     Promptly after the execution of this Amending Agreement, the parties shall, for administrative and information proposes only, prepare a restate the Contractor Services Agreement, including Exhibits thereof, reflecting the amendments contained herein. For greater certainty, the rights of the Parties shall be defined in the Contractor Services Agreement dated May 19, 1998, as amended by the Canadian NPAC/SMS Contractor Services Amending Agreement dated March 31, 2003 and this Amending Agreement.     12.   Miscellaneous       12.1   Order of Precedence. In the event of any conflict or inconsistency among or between the terms of this Amending Agreement or the Contractor Services Agreement, this Amending Agreement shall prevail.      12.2   Amendments. This Amending Agreement may be amended or supplemented only in writing and signed on behalf of the Parties by authorized signatories.     Page 11             12.3   Waiver. No failure or delay of any party in exercising any right or remedy under this Amending Agreement (and no course of dealing between or among the parties) shall operate as a waiver of any such right or remedy.      12.4   Relationship of Parties. There is no relationship of agency, partnership, joint venture, employment between the parties. Neither Party has the authority to bind the other or to incur any obligation or liability on the other’s behalf.      12.5   Third Party Beneficiaries. Except as otherwise expressly set forth herein, the provisions of this Amending Agreement are solely for the benefit of the Parties. No other person, including invitees, members of the general public and other third parties are intended to have nor shall have any rights whatsoever under this Amending Agreement, whether for injury, loss or damage to persons or property, or for economic loss, damage or injury.      12.6   Equitable Relief. Either Party may seek injunctive or other equitable relief to remedy any actual or threatened dispute.      12.7   Entire Agreement. This Amending Agreement, including any supplements hereto, represents the entire agreement between the Parties relating to the subject matter of this Amending Agreement and supersedes any prior representations, discussions, negotiations and agreements, whether written or oral.      12.8   Independent Counsel. This Amending Agreement has been negotiated at arms length and jointly prepared by the parties and their respective counsel of choice.      12.9   Assignment. Neither Party shall assign any of its rights or obligations hereunder without the prior written consent of the other.      12.10   Compliance with Law. The Parties will, at their own expense, operate in full compliance with all laws, rules and regulations applicable to, and maintain in force all licenses and permits required for, their performance under this Amending Agreement.      12.11   Confidentiality. The confidentiality provisions contained in Article 15 of the Contractor Services Agreement shall apply, mutatis mutandis, to this Amending Agreement.      12.12   Definitions. Capitalized terms, and terms having initial capital letters shall, unless otherwise defined herein, have the meanings ascribed thereto in the Contractor Services Agreement.    [THE NEXT PAGE IS THE SIGNING PAGE]   Page 12            IN WITNESS WHEREOF, each of the parties hereto has executed and delivered this Amending Agreement by its duly authorized representative, effective on the date and year first written above.                        CANADIAN LNP CONSORTIUM       INC./CONSORTIUM CANADIEN POUR LA       TNL INC.                    Per:    /s/ J. Sarrazin                     Name:    Jacques Sarrazin                     Title:    President                                NEUSTAR, INC.                    Per:    /s/ Joseph F. Franlin                     Name:    Joseph Franlin                     Title:    SC VP Customer relations                     Date:    December 19, 2005      Page 13       EX-10.2.2 4 w17665exv10w2w2.htm EX-10.2.2    exv10w2w2       Exhibit 10.2.2                    Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         Pursuant to 17 CFR 240.24b-2, confidential information has been omitted in places marked [* * *] and has been filed separately with the Securities and Exchange Commission pursuant to a Confidential Treatment Application filed with the Commission.  [Graphic Omitted: NeuStar Logo]  REVISION 1 TO STATEMENT OF WORK  FOR  CANADIAN VIRTUAL POINT OF PRESENCE  UNDER  AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM   Page 1                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         REVISION 1 TO STATEMENT OF WORK NO. 37(CA)  UNDER  AGREEMENT FOR NUMBER PORTABILITY ADMINISTRATION CENTER / SERVICE MANAGEMENT SYSTEM  Canadian Virtual Point of Presence     1.   PARTIES    This Revision No. 1 (the “Revision”) to Statement of Work No. 37(CA) (the “Statement of Work” or “SOW”) is entered into pursuant to Article 13 of, and upon execution shall be a part of, the Contractor Services Agreement for Number Portability Administration Center/Service Management System (the “Master Agreement”) by and between NeuStar, Inc., a Delaware corporation (“Contractor”) and the Canadian LNP Consortium, Inc., a corporation incorporated under the laws of Canada (the “Customer”).     2.   EFFECTIVENESS    This Amendment shall be effective as of the 20th day of February, 2005 (the “Effective Date”) only upon execution of this SOW by Contractor and Customer. The number in the upper left-hand corner refers to this Amendment. Undefined capitalized terms used herein shall have the meanings ascribed by the Master Agreement.     3.   ADDITIONAL SERVICES         3.1   SOW37 Additional Services    SOW37 provided for the establishment of a virtual point of presence (“VPOP”) in a central location in Mississauga, Canada through which Canadian Users are be able to connect from time to time to Contractor’s Disaster Recovery Data Center, currently located in [* * *] (the “Disaster Recovery Center”).       3.2   Scope of Revision    Customer has requested that Contractor replace the vendor for the VPOP service from Lockheed Martin to [* * *]. On February 20, 2005, Contractor replaced the VPOP vendor in accordance with the foregoing, and began providing VPOP services on such basis on that date. The replacement of the vendor for VPOP services is considered a termination of SOW37 for purposes of Section 8.6 (Termination Charges) under SOW37. The provision of the VPOP by Contractor pursuant to this SOW shall comprise Additional Services. The Additional Services set forth in this SOW are not an Enhancement to the NPAC/SMS Software as defined under the Master Agreement.   Page 2                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes              3.3   Revision Additional Services    Contractor shall procure, obtain, and deploy all necessary facilities, hardware, and software, as well as all required licenses, permits, consents, and other rights (the “Underlying Rights”) to establish the VPOP in Mississauga, Ontario, Canada to enable all Users requiring circuit connectivity to the Disaster Recovery Center to connect to such center through the VPOP. Contractor shall be solely and fully responsible for all aspects of the provision of the VPOP including, without limitation, space, equipment, management, Underlying Rights, and the responsibility for the delivery of User traffic between the VPOP and the Disaster Recovery Center.  In order to access the VPOP, Users will be required to bring their fractional T1 or higher circuit(s) to the VPOP, as further described below. The VPOP shall have a capacity equal to eight T1’s. All Users connecting to the VPOP must meet the requirements set forth in the Minimum Connectivity Requirements document issued by Contractor and approved by Customer. The point of demarcation between Users’ and Contractor’s networks shall be the Users’ connection to the VPOP third party service provider’s patch panel (the “Patch Panel”). Users are responsible for their circuit up to such connection. Contractor shall be responsible for connecting its circuit to the VPOP. For the avoidance of doubt, SLR-7 (SOA/LSMS Interface Availability (User)) as set forth in Exhibit G to the Master Agreement, applies from the User’s connection point to the Patch Panel up to and including the Disaster Recovery Data Center.       3.4   Limitations    The provision of the Additional Services set forth in this SOW does not convey any form or type of title or ownership in any real or personal property, including, but not limited to, any networks or any transmission or other facilities and equipment related to the VPOP.       3.5   Non-Interference    Subject to and conditional upon Contractor’s provision of the Additional Services in accordance with this SOW and otherwise in accordance with the Master Agreement, Customer and Users agree that Users’ use of and connection to the VPOP shall at all times be in accordance with the terms and conditions of this SOW and the Master Agreement, and that Users’ use of the VPOP otherwise than in accordance with this SOW and the Master Agreement shall not cause any material negative interference with, or material negative impairment of, delivery of the Services by the Contractor to other Users.     4.   OUT OF SCOPE SERVICES    This SOW contains the agreed upon terms and conditions that shall govern Contractor’s performance of the Additional Services described herein. The Additional Services provided for in this SOW, and for which Contractor shall be compensated in accordance with Article 8 and Section 7.2, shall not be interpreted, implied, or assumed to include   Page 3                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         any other service(s) (hereinafter “Out of Scope Services”), which Out of Scope Services shall be provided in accordance with the Master Agreement and, specifically, Article 13, Additional Services.     5.   PROJECT SCHEDULE    Contractor shall establish the VPOP by February 20, 2005, and provide the services contemplated under this SOW until the earlier of December 31, 2011 and termination of the Master Agreement.     6.   COMPLETION AND ACCEPTANCE CRITERIA    The following internal documents are applicable to the Additional Services contemplated under this SOW:                         N/A    Functional Requirements Specifications                     N/A    Requirements Traceability Matrix                     N/A    External Design                     N/A    System Design                     N/A    Detailed Design                     N/A    Integration Test Plan                     N/A    System Test Plan                     N/A    Software Quality Assurance Program Report                     Ö    User Documentation                     N/A    Software Configuration Management Plan                     N/A    Standards and Metrics                     7.   IMPACTS ON MASTER AGREEMENT         7.1   Applicable    The following portions of the Master Agreement are impacted by this SOW:                         None    Master Agreement                     None    Exhibit B Functional Requirements Specification                     None    Exhibit C Interoperable Interface Specification                     Ö    Exhibit E Pricing Schedules                     None    Exhibit F Project Plan and Test Schedule                     None    Exhibit G Service Level Requirements                     None    Exhibit H Reporting and Monitoring Requirements                     None    Exhibit I Key Personnel                     None    Exhibit J User Agreement Form                     None    Exhibit K External Design                     None    Exhibit L Infrastructure/Hardware                     None    Exhibit M Software Escrow Agreement                     None    Exhibit N System Performance Plan for NPAC/SMS Services                   Page 4                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes                                None    Exhibit O Statement of Work Cost Principles                       7.2   Pricing Schedule    Effective on the Amendment Effective Date, Schedule 1 (Service Element Fees/Unit Pricing) of Exhibit E (Pricing Schedules) of the Master Agreement shall be amended by inserting the following item under Category 2 (Per User/Per Request Charges) as follows:                        VPOP access to Disaster Recovery Data Center    Per month in accordance with SOW No. 37, Revision 1    CDN$[* * *]        8.   PRICING         8.1   Obligation    Upon execution of this SOW, Contractor shall be entitled to be compensated for the Additional Services described herein in the amount and on the terms and conditions described below. Such compensation shall be the obligation of each applicable User, as directed by the Customer. For the purposes of and in accordance with Section 23.3 of the Master Agreement (“Users’ Liability for Payments”), Additional Services, to the extent actually performed, shall be considered to be services performed prior to any such effective date of termination. Accordingly and notwithstanding any other provisions to the contrary in the Master Agreement or any exhibit attached thereto, but subject to Section 23.3 of the Master Agreement, in the event any amounts owed pursuant to this SOW remain outstanding upon any termination or expiration of the Master Agreement or this SOW, such amounts shall be immediately due and payable by the applicable User(s) as provided for herein.       8.2   Compensation    The Parties acknowledge and agree that the pricing for the Additional Services has been derived and calculated in material compliance with Exhibit O of the Master Agreement, which acknowledgment shall not be interpreted as an admission, by either Party, that Exhibit O is or is not a requirement for this SOW. The Contractor further expressly acknowledges and agrees, with respect to the pricing under this SOW, that such pricing shall not in any way be construed, directly or indirectly, as an agreement of, or waiver by, Customer of its rights to enforce the obligations of Contractor under Exhibit O in respect of any Statement of Work entered into by the Parties following the date of this SOW.  The pricing for the Additional Services performed by Contractor shall be equal to a non-recurring fee (“Non-Recurring Fee”) of [* * *] Canadian Dollars [* * *] Cents (CDN$[* * *]), billed in the month following the month in which this Revision is executed and delivered, and a monthly recurring charge (“Monthly Recurring Charge”) of [* * *] Canadian Dollars [* * *] Cents (CDN$[* * *]) to be paid each month during   Page 5                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         which the VPOP is available, beginning the first full month (on a pro-rated basis) after the VPOP is first made available to Users (i.e., the Effective Date).1  Contractor and Customer acknowledge that because Contractor has billed Users since the Effective Date of this Revision in accordance with the billing requirements of SOW 37 up to and including the month in which this Revision is executed and delivered, Contractor will, where appropriate, apply an adjustment as directed by the Customer to User’s invoices in the month following the month in which this SOW is executed and delivered for the preceding period commencing with Effective Date of this Revision, which adjustment may include a credit against future invoice for the VPOP services provided as Additional Services under this Revision, until exhausted.  Neither the Non-Recurring Fee nor the Monthly Recurring Charge include costs and charges related to bringing User’s circuit to the point of demarcation described in Section 3.2 of this SOW, which costs and charges are the sole responsibility of the User. Both the Non-Recurring Fee and the Monthly Recurring Charge shall be allocated and invoiced among Users in accordance with the Allocation Model delivered by the Customer to the Contractor. Notwithstanding the foregoing, Customer shall have the right to direct Contractor to deviate from the Allocation Model upon thirty (30) days prior written notice.       8.3   Payment    Contractor shall prepare invoices in accordance with the Master Agreement invoicing, which may include invoicing for charges under other Statements of Work agreed to pursuant to Article 13 of the Master Agreement, on the last day of a calendar month and shall send such invoice to each User for the amount of its User charges. Contractor shall also prepare and deliver to Customer a report (the “Monthly Summary of Charges”) setting forth the billing calculation above. All invoices shall be due and payable within thirty (30) days of the date of the invoice. Late payments will be subject to a one and one-quarter percent (1.25%) interest charge per month, or, if lower, the maximum rate permitted by law.       8.4   Disputes    Any billing disputes shall be promptly presented to Contractor in reasonable detail, in writing. Any requests for adjustment shall not be cause for delay in payment of the undisputed balance due. User may withhold payment of any amounts which are subject to a bona fide dispute; provided it shall pay all undisputed amounts owing to Contractor that have been separately invoiced to User. If re-invoice occurs following the thirty (30) day payment schedule, then such invoice for the undisputed amount shall be paid within ten             1   The Non-Recurring Fee and the Monthly Recurring Charge are not subject to the annual conversion rate adjustment required under the Amending Agreement, effective March 31, 2003 of the Master Agreement, as implemented in SOW46 (Annual Update to Conversion Factor) because the amounts set forth for each are billed by the provider in Canadian Dollars.    Page 6                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         (10) business days of receipt by User. User and Contractor shall seek to resolve any such disputes expeditiously, but in any event within less than thirty (30) days after receipt of notice thereof. All disputed amounts ultimately paid or awarded to Contractor shall bear interest from the thirtieth (30th) day following the original invoice date.       8.5   Taxes    Each User is to remit to or reimburse Contractor for any taxes that it is obligated to pay by law, rule or regulation or under this SOW, the Master Agreement or its respective NPAC/SMS User Agreement.       8.6   Termination Costs under Revision 1    Customer shall be entitled to terminate this SOW37 Revision 1 at any time during the term of provision of the Additional Services under this Revision by Contractor, provided that, in the event of any such termination, Users shall be entitled to re-terminate their circuits in the same fashion, and under the same terms and conditions, as was the case prior to implementation of the VPOP, and the Customer shall pay to Contractor termination charges as a Non-Recurring Fee. With respect to the VPOP vendor under this Revision to SOW37, i.e., [* * *], the following sets forth the method for calculating such termination charges:       (i)   If the termination occurs prior to the first anniversary of the installation of the VPOP services, then the termination charge shall equal the product of (a) the Monthly Recurring Charge and (b) the number of months remaining in the first year of VPOP services between Contractor and the underlying provider.        (ii)   If the termination occurs after the first anniversary of the installation of the VPOP services, then the termination charge shall equal the product of (a) one half (1/2) of the Monthly Recurring Charge and (b) the number of months remaining in the applicable VPOP service term between Contractor and the underlying provider.    Contractor’s agreement with [* * *], as the underlying provider of VPOP services, provides for an initial term of thirty six (36) months commencing on the Effective Date. Contractor shall notify the Customer in writing, at least 10 Business Days prior to the effective date, of any extension, renewal or other modification of the foregoing terms with [* * *], and any other service terms with any other underlying provider with whom Contractor may enter into an agreement in substitution for the agreement with [* * *], regarding the VPOP services under this SOW.  Notwithstanding the foregoing, Contractor represents and warrants that the termination charges are the exact charges (without mark up or margin) payable by Contractor to its VPOP supplier in the event of termination by Contractor pursuant to its agreements with   Page 7                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         its supplier. Contractor agrees that if Contractor becomes entitled to any discount, rebate or other reduction from such termination charges, any such other discount, rebate or reduction shall be applied in favor of the Customer as a dollar for dollar reduction from the termination charges which may otherwise be, or have been, payable by Customer hereunder.       8.7   Termination Costs under SOW37    The Parties acknowledge that the original vendor (Lockheed Martin) for VPOP services under SOW 37 has yet to invoice NeuStar the termination charges referenced in Section 8.6 of SOW 37, and as a result, Contractor cannot ascertain if the underlying vendor is providing any discounts, rebates or other reductions from such termination charges. Contractor and Customer agree that Contractor shall use commercially reasonable efforts to ascertain the termination charges under Section 8.6 of SOW37. The Parties hereby agree that for purposes of calculating the termination charges under Section 8.6 of SOW37, the VPOP services was terminated after 19 months of services (i.e., from July 16, 2003 to February 20, 2005). Upon Contractor ascertaining the termination charges referred to in the immediately preceding sentence, Contractor shall prepare and deliver to the Customer an invoice in respect thereof, which Customer shall pay within forty-five (45) days of receipt.     9.   CONTINUATION OF MASTER AGREEMENT AND USER AGREEMENT    Except as specifically modified and amended hereby, all the provisions of the Master Agreement and the User Agreements entered into with respect thereto, and all exhibits and schedules thereto, shall remain unaltered and in full force and effect in accordance with their terms. From and after the date hereof, any reference in either the Master Agreement to itself and any Article, Section or subsections thereof or to any Exhibit thereto, or in any User Agreement to itself or to the Master Agreement and applicable to any time from and after the date hereof, shall be deemed to be a reference to such agreement, Article, Section, subsection or Exhibit as modified and amended by this SOW. From and after the Amendment Effective Date, this SOW shall be a part of the Master Agreement and, as such, shall be subject to the terms and conditions therein.     10.   MISCELLANEOUS         10.1   Counterparts    This SOW may be executed in two or more counterparts and by different parties hereto in separate counterparts, with the same effect as if all parties had signed the same document. All such counterparts shall be deemed an original, shall be construed together and shall constitute one and the same instrument.   Page 8                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes              10.2   Entire Agreement    This SOW sets forth the entire understanding between the Parties with regard to the subject matter hereof and supersedes any prior or contemporaneous agreement, discussions, negotiations or representations between the Parties, whether written or oral, with respect thereto.  [THIS SPACE INTENTIONALLY LEFT BLANK]   Page 9                         Amendment No. 37(CA) Revision 1   Date: February 20, 2005   SOW:    oNo            þYes         IN WITNESS WHEREOF, the undersigned have executed and delivered this SOW:                    CONTRACTOR: NeuStar, Inc.    By:    /s/Joseph F. Franlin                    Its:    Joseph F. Franlin                    Date:    1/17/06                   CUSTOMER: Canadian LNP Consortium, Inc.    By:    /s/ J. Sarrazin                    Its:    Jacques Sarrazin                    Date:    1/20/06          Page 10       EX-10.4.1 5 w17665exv10w4w1.htm EX-10.4.1    exv10w4w1       Exhibit 10.4.1                                                AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT        1.     CONTRACT ID CODE      Page 1 of 2                                                                             2.    AMENDMENT/MODIFICATION NO. 0001        3.     EFFECTIVE DATE 11/12/2003        4.     REQUISITION/PURCHASE REQ. NO.        5.     PROJECT NO. (If applicable)                                                                       6.    ISSUED BY CODE       00001   7.     ADMINISTERED BY (If other than Item 6) CODE                                                                              FCC/Contracts and Purchasing Center                                                            445 12th St., SW,                                                            Washington, DC 20554                                                                        8.   NAME AND ADDRESS OF CONTRACTOR (No., street, county, State and Zip Code)           9A. AMENDMENT OF SOLICITATION NO.                           Neustar, Inc.               9B. DATED (SEE ITEM 11)                           46000 Center Oak PlazaSterling, VA 20166         (X)     10A. MODIFICATION OF CONTRACT/ORDER NO. CON03000016                                     (X)     10B. DATED (SEE ITEM 13)                       CODE*        FACILITY CODE                                                        11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS                           o    The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offers o is extended, o is not extended.                Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods:                (a) By completing Items 8 and 15, and returning ___copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.                               12.    ACCOUNTING AND APPROPRIATION DATA (If required)        No Funding Information                                13. THIS ITEM ONLY APPLIES TO MODIFICATION OF CONTRACTS/ORDERS.            IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.                               CHECK ONE               o      A.    THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE CONTRACT ORDER NO. IN ITEM 10A.             o      B.    THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.1 03(b).             o      C.    THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:             o      D.    OTHER (Specify type of modification and authority)              FAR 1.6, Authority of Contracting Officers”             E. IMPORTANT: Contractor o is not, þ is required to sign this document and return 2 copies to the issuing office.             14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)                 The above numbered contract is hereby modified to incorporate the attached security language..                 Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.                                           15A.   NAME AND TITLE OF SIGNER (Type or print)   16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)                      Mark Oakey                               15B.    CONTRACTOR/OFFEROR    15C. DATE SIGNED    16B.  United States of America    16C. DATE SIGNED        /s/ J. F. Franlin                                                            11/13/03     BY                                           (Signature of person authorized to sign)              (Signature of Contracting Officer)                        NSN 7540-01-152-8070 PREVIOUS EDITION UNUSABLE    STANDARD FORM 30 (REV. 10-83) Prescribed by GSA FAR (48 CFR) 53.243                                                       Line Item      Document Number      Title      Page   Summary      CON03000016/0001      NANP Administrator      2 of 2                           No Funding Information                                        Line Item        Delivery Date        Unit of           Number    Description    (Start date to End date)    Quantity    Issue    Unit Price    Total Cost                No Changed Line Item Fields  Previous Total: Modification Total: Grand Total:               SECURITY AND SUITABILITY ASSESSMENT  1. General  (a) All contract personnel are subjected to background investigations for the purpose of suitability determinations. Based on their proposed duties, some contract personnel may also be required to have security clearance determinations. No contract personnel may be assigned to work on the contract without a favorable initial review of the OF 306, Declaration for Federal Employment (http://www.opm.gov/forms/pdf fill/of0306.pdf) or a written waiver from the FCC Security Operations Center (SOC). (For more detail, see Appendix No. 2)  (b) Suitability, waiver, and security clearance determination investigations are currently conducted through the FCC Security Operations Center (202- 418-7884). The individual contract employee will be provided with a review process before a final adverse determination is made. The FCC requires that any contract personnel found not suitable, or who has a waiver cancelled, or is denied a security clearance, be removed by the contractor during the same business day that the determination is made.  (c) If the contract personnel is re-assigned and the new position is determined to require a higher level of risk suitability than the contract personnel currently holds, the individual may be assigned to such position while the determination is reached by the SOC. A new A-200 may be necessary for the new position.  (d) Contract personnel working as temporary hires (for ninety (90) days or less) must complete and receive a favorable initial review of the OF 306 and complete the contract personnel section of the FCC Form A-600, “FCC Contractor Record Form.” If during the term of their employment they will have access to any FCC network application, they must also complete and sign the FCC Form A-200, “FCC Computer System Application Access Form.”  2. At Time of Contract Award  (a) The FCC Security Operations Center must receive the completed, signed OF 306 for all proposed contractor employees at the time of contract award. Resumes for all personnel proposed for assignment on the contract should be provided to the Security Office prior to the time of in-take processing (see below, 2.3.2). The FCC Security Operations Center requires up to five (5) working days (from the date they are received) to process the OF 306 before any employee is allowed to begin work on the contract. A written waiver from the SOC may be obtained in special circumstances.  All contract personnel, regardless of task description, must complete this form. Without an approved, completed OF 306 on file at the SOC, no contractor employee may begin work. An approved OF 306 is one that has passed initial review by the SOC. During the course of the SOC review of the OF 306, the contract personnel may be interviewed by SOC staff regarding information on their OF 306.          (b) In addition, the Contractor is responsible for submission of completed, signed computer security forms for each employee prior to that person beginning work on the contract (See Appendix No. 3, FCC Instruction 1479.1, FCC Computer Security Program Directive and sample forms.) These forms should be submitted to the FCC Computer Security Office.  (c) The COTR shall begin processing their section of the FCC Contract Personnel Record (FCC Form A-600) at this time. This form, with the COTR and CO portions completed, will be distributed at the time of contract award and must be submitted to the SOC within ten (10) working days.  (d) The Office of Personnel Management (OPM) will issue a Certificate of Investigation (CIN) for each favorably reviewed OF 306. The SOC will issue a memorandum to the CO and COTR listing those contract personnel who have been granted a CIN. This memorandum should be retained for the duration of the contract.  3. Registration and Checkout Requirements  3.1. Locator and Information Services Tracking (LIST) Registration  The Security Operations Center maintains a Locator and Information Services Tracking (LIST) database, containing contact information for all Commission and contract employee personnel, regardless of work location.  The contract employee’s FCC Form A-600, “FCC Contractor Record Form” captures the information for data entry into the LIST system.  3.2 Intake Processing  (a) Following the processing of the OF 306 and an initial favorable suitability determination, (unless otherwise waived) the contract personnel may report to the FCC for work.  (b) On the first day of work, all contract personnel must report to the Security Operations Center to complete the Fingerprint Card Form, FD 258, the Fair Credit Report Act form, and to be photographed and issued a security badge.  (c) At this time the contract employee will be given one of the following forms, based on the security risk designation for the proposed support classification/position, to complete and return to the SOC within seven (7) business days:       (i)   Low Risk Positions - SF 85, Questionnaire for Non-Sensitive Positions        (ii)   Moderate Risk Positions - SF 85-P, Questionnaire for Public Trust Positions        (iii)   High Risk Positions/Secret or Top Secret Security Clearances —Standard Form (SF) 86, Questionnaire for Sensitive Positions               (d) For any contract employee whose name is provided to the Commission for security investigation at (ii) or (iii) level, who subsequently leaves the subject contract, due to Contractor or contract employee decision, within the first year, the Contractor shall reimburse the Commission for the cost of the investigation. If the contract or task order is scheduled for completion in under one year and the contract employee for whom a security investigation has been done leaves prior to the work being done, the Contractor and SOC shall agree on a pro-rated amount for reimbursement. The cost may vary from approximately $400.00 (moderate risk) to $3,000.00 (high risk). The Contractor will be provided a copy of the investigation invoice with the reimbursement request.  3.3 Monthly Personnel Reports  Monthly report: The Contractor’s Program Manager shall submit to the SOC a monthly contract personnel list. This report is currently provided in MS Excel format. The Contractor shall annotate this report and correct and update the information monthly. This report shall highlight or list in some way those individuals who are no longer employed by the Contractor or no longer working on the subject contract. Any additional contract personnel that have been successfully processed for work on the contract since the previous report shall also be noted. The annotated monthly contract personnel list report shall be submitted to the following, via email, by the 10th calendar day of each month:  FCC Security Operations Center Contracting Officer Contracting Officer’s Technical Representative (COTR)   3.4 Checkout Processing:  (a) All contract employees no longer employed on the subject contract, or at the termination of the contract, are required to report to the SOC and complete the sign-out portion of the FCC A-600, Contract Personnel Record.  (b) This process verifies the ID badge and keys (if any) have been returned to the SOC by the contract personnel.  (c) If the checkout processing is not completed by the contract employee, the Contractor shall take action to ensure its accomplishment no later than 30 days after the employee’s departure from the FCC.  (d) The Contractor shall be liable to the FCC for an administrative processing charge of $150.00 (One Hundred Fifty Dollars), for each of their contractor employees who leaves their duty assignment at the Commission and fails to complete the checkout processing within 30 (thirty) calendar days of departure. Mellon Bank, N.A., handles collection and processing of all Commission administrative charges and should payment become necessary, the Contractor will be provided the appropriate directions for an EFT.          (e) The Contractor shall be liable for any actual damages arising from a failure to ensure that the checkout processing occurs within the 30 (thirty) calendar days of the contract employee’s departure from the FCC.  4. Computer Security  4.1. FCC Computer Security Program Directive Specifications  Contractors shall ensure that:       a. any contractor employee assigned to this contract who is required, by their duties to be issued a FCC computer network id., obtain, read, understand and comply with the policy and procedures of Directive, 1479.1, Computer Security Program (Appendix No. 3) which outlines safeguards to be followed for the protection of agency sensitive and mission critical data;       b. appropriate forms are completed and submitted to FCC OMD-ITC for processing required to gain, modify and server computer systems access. Forms include FCC Computer System Office Application and/or System Access Form, Form A-200 (used to identify the user requesting access to FCC computer resources), FCC Computer System Access Acknowledgement, Form A-201, (used to verify user’s obligations to secure the Commission’s computer system and data), FCC Computer System Personally-Owned Software Installation Certification, Form A-202 (used to identify properly licensed personal software to install on a particular PC), and FCC Computer System Separation Clearance, Form A-203 (used to announce the user’s intention to relinquish computer system access rights);       c. access to FCC computer systems is requested and limited only on an “as needed basis” to perform official FCC business; and       d. contractor promotes the security of FCC information systems and data when being accessed by the contractor. I n addition, contractor shall ensure that computer systems, related hardware and authorizations are not modified by the contractor without express written consent from the Government.          EX-10.7.1 6 w17665exv10w7w1.htm EX-10.7.1    exv10w7w1       Exhibit 10.7.1  SECOND AMENDMENT TO COMMON SHORT CODE LICENSE AGREEMENT Implementation of 6-Digit CSCs       This Second Amendment to the Common Short Code License Agreement, Statement: Statement of Work dated as of the ___ day of January, 2006 between NeuStar, Inc., a Delaware corporation, with offices located at 46000 Center Oak Plaza, Building X, Sterling, VA 20166 (“NeuStar”) and the Cellular Telecommunications and Internet Association (“CTIA”), a District of Columbia non-profit corporation, located at 1400 16th Street, NW, Suite 600, Washington, DC 20036.       WHEREAS, NeuStar entered into a Common Short Code License Agreement with the CTIA (“License Agreement”) dated October 17, 2003 to develop and maintain a database of common short codes, to process common short code applications and assign common short codes to applicants and to engage in other Registry Services on behalf of members of the wireless industry;       WHEREAS, NeuStar and CTIA now desire to amend certain terms of the License Agreement pursuant to Article 9 of the License Agreement to (i) allow for the registration of six (6) digit CSCs (each a “6-digit CSC”), (ii) upgrade the Registry Database and associated Registry Services, and (iii) to revise the Assignment Guidelines to reflect modified specifications from the Common Short Code Working Group.       NOW, THEREFORE, in consideration of the mutual covenants contained herein and other good and valuable consideration, receipt of which is hereby acknowledged, the parties agree as follows:  I. Terms used in this Second Amendment and not otherwise defined shall have the same meaning set forth in the License Agreement.  II. Six-Digit Common Short Codes.       A.   Lease of 6 Digit CSCs. Commencing no later than ninety (90) days after the execution of this Second Amendment, Registry shall be entitled to lease six (6) digit CSCs in accordance with Article 6 of the License Agreement and with the Assignment Guidelines as modified in this Second Amendment.        B.   Grandfathered CSCs. No later than fifteen days prior to the launch of such 6-digit CSCs (“6-digit Launch Date”), Carriers may request 6-digit CSCs to be reserved from the CSC pool, rendering them unavailable for general registration on the 6-digit Launch Date as a CSC (“6-Digit Grandfathered CSC”). Carriers may return 6-digit Grandfathered CSCs to the available pool of CSCs at any time.        C.   Types of 6-Digit CSCs. There shall be Random, Selected and Carrier Reserved 6-Digit CSCs leased in accordance with sections 6.3.3, 6.3.4 and 6.3.5 of the License Agreement.    Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 1 of 35                D.   6-digit CSCs are CSCs. Except as set forth in Section II.A above, 6-Digit CSCs shall be treated the same as CSCs for all other purposes set forth in the License Agreement.    III. CSC Version 2.0.      A.   NeuStar shall, either itself, or in conjunction with other third parties, implement CSC version 2.0, which shall include the additional functionality set forth in Attachment 1, attached hereto (“CSC 2.0”)        B.   For purposes of the License Agreement, the functionalities listed under New Registry Database Functionality in Attachment Number 1 shall be considered an “Enhancement” as defined in Section 1.21 of the License Agreement. Therefore, the New Registry Database Functionality shall be considered “Registry IP” and owned exclusively by the Registry pursuant to Section 7.3 of the License Agreement.        C.   For purposes of the License Agreement , the enhancements listed under New CSC Website Enhancements as well as any CSC Data associated or related to CSC 2.0 shall be considered “CSC Enhancements” as defined in Section 1.16 of the License Agreement. Therefore, the New CSC Website Functionality and any related CSC Data generated by such Functionality shall be considered CSC Registry Rights and owned exclusively by CTIA, on behalf of all Participating Carriers, pursuant to Section 7.1 of the License Agreement.        D.   The Parties hereby agree that all transition requirements applicable to 5-Digit CSCs shall also be applicable to 6-Digit CSCs under the terms and conditions set forth in Article 17 of the License Agreement.    IV. 6-Digit Fees. CTIA agrees to pay Registry the fees set forth in Exhibit C-2 of the License Agreement for each 6-digit CSC.  V. Assignment Guidelines v. 1.1. The Parties hereby agree to delete Exhibit E to the License Agreement and replace such Exhibit with the new Exhibit E, attached hereto as Attachment 2.  VI. Except as specifically modified by this Second Amendment, the terms and conditions of the License Agreement shall remain in full force and effect.       IN WITNESS WHEREOF, the parties have caused this Amendment to be duly executed as of the date first written above.                        NEUSTAR, INC        CTIA     By: /s/ Steven Boyce   By: /s/ R. Mesirow        Name: Steven Boyce        Name: R. Mesirow        Title: VP + Controller        Title: VP Operations        Date: 01/20/06        Date: 1/31/06     Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 2 of 35           ATTACHMENT NUMBER 1 TO THE SECOND AMENDMENT TO COMMON SHORT CODE LICENSE AGREEMENT  CSC 2.0 FUNCTIONALITY  The following represents the material additional functionality that will be added to the CSC Registry Database and Website, which shall comprise CSC 2.0.     I.   New Registry Database Functionality       1.   Registry shall allow for the registration of Random and Selected 6-Digit CSCs by members of the public.       2.   Registry shall update the Registry Database to allow CSC Registrants to pay for their CSC leases via Visa, MasterCard and American Express credit cards.       3.   Registry shall ensure that all renewal terms for CSCs shall correspond to the expiration of the previous term, rather than the date of payment for such renewal.       4.   Registry shall provide CSC applicants with the ability to add a basic content rating (i.e., Over/Under 18 years of age).       5.   Registrants shall have the ability to copy information about a particular CSC from one application or registration into an application for an additional CSC.       6.   In the CSC Application, Registrants will have the ability to select a particular Content Aggregator from a drop-down list.       7.   Registry shall ensure that Carriers are provided with notices of deactivation in the event that CSCs are not renewed and paid within 30 days after expiration of the CSC.       8.   Registry shall update the CSC application fields to allow for the use of Internationalized characters.       9.   Registry shall allow CSC Registrants to add additional billing contacts for each CSC.       10.   Registry shall provide e-mail reminder notices to Applicants for CSCs which have been registered or renewed, but are unpaid.       11.   Carriers shall have the ability to opt-in or Opt-out of all types of Registry notices.       12.   Registry shall incorporate a tool for end users to provide comments / suggestions to the Registry and CTIA on the US CSC program and the CSC Website.       II.   New CSC Website Enhancements       1.   The CSC Website shall be redesigned to minimize the number of steps to register a CSC.       2.   Registry shall include actual examples of existing CSC programs (i.e., ESPN, ClearChannel, etc.) on the CSC Website. In addition, the CSC Website shall contain “case studies” and “model” CSC programs. Such content shall be supplied by CTIA to Registry to include on the Website. CTIA shall procure the intellectual property rights and associated licenses from third parties (if any are required) to display such content on the Website. Content may also be supplied directly by third party content providers that license such content directly to the CTIA and Registry to use on the CSC Website.    Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 3 of 35              3.   Registry shall revise the “Step by step process” for leasing CSCs currently located at: http://www.usshortcodes.com/content/csc_obtain.html      4.   Registry shall compile Website user statistics which shall be provided to CTIA in periodic reports, which shall be no more than once per month.      5.   Registry shall replace certain graphics on the Website.      6.   Registry shall include on the Website home page a section entitled “What’s New” to contain dynamic content supplied by CTIA and Registry. Registry’s website support team shall provide the support for updating this section.      7.   Registry shall also include on the home page of the Website a section entitled “Calendar/Events” which shall supply the end user with information related to events, trade shows and conferences that are related to the United Stated CSC program. Registry’s website support team shall provide the support for updating this section.      8.   The CSC Website shall contain a page dedicated to CSC advertising and promotions as agreed to by the Parties.      9.   The Registry shall, with the assistance of the CTIA, develop a Webpage on the CSC Website that describes how an end user sends an SMS message using a CSC.      10.   The Parties shall work together to develop a CSC User Guide to place on the CSC Website that shall provide end users with the rules related to the deployment of CSC programs.    Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 4 of 35           ATTACHMENT NUMBER 2 TO THE SECOND AMENDMENT TO COMMON SHORT CODE LICENSE AGREEMENT  AMENDED AND RESTATED EXHIBIT E TO THE COMMON SHORT CODE ADMINISTRATION AGREEMENT Assignment Guidelines  COMMON SHORT CODE ADMINISTRATION GUIDELINES  Version 1.1 January 20, 2006  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 5 of 35           Table of Contents       1.   Common Short Code Service Overview        2.   Common Short Code Namespace        3.   Common Short Code Users        4.   Common Short Code Application Process        5.   Common Short Code Address Database        6.   Common Shot Code Customer Service    Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 6 of 35              1.   Common Short Code Service Overview    Short codes are a string of numeric digits used to address wireless messages. Wireless carriers administer their own list of short codes. Common short codes (CSC) are short codes that are administered by a single CSC Administrator for a group of wireless carriers.  1.1 Wireless Messaging and Short Codes Wireless messaging allows mobile subscribers to send and receive messages with other subscribers or with applications. A telephone number will be used when sending a message to another subscriber. Messages sent to other subscribers are like email, and include text such as “I’ll be there in 10 minutes”.  Some examples of applications used in wireless messaging are; TV voting/polling, information requests, direct response marketing promotions and wireless advertising. Rather than use telephone numbers to address applications carriers use short codes. For example, if a wireless user wants to request football scores by using a short code they could create a message with the text “Football scores” and address it to a short code such as 29876. The application provider would then send football scores to the subscriber’s mobile.  1.2 Functional Roles Involved in Short Codes There are a number of roles involved in enabling and using short code related applications:       •   End users — persons or entities that will utilize short codes for communication with applications        •   Carriers — provide the network infrastructure for delivery of messages between the end user and connection aggregators or application providers. A Carrier may also act as a connection aggregator, application provider, or applicant for CSCs. In such an event that Carrier will be bound by the same rules and obligations as any other connection aggregator, application provider or applicant.        •   Connection aggregator — may provide connectivity between carrier networks and application providers        •   Application providers — provide the technology platform for a short code service application        •   Content provider — the entity that owns or has the right to content and licenses such content to the application provider for delivery to the end user    It’s possible for the application provider to also be the content provider. For example an application provider could provide ring tones as content. It’s also possible for the same company to be both a connection aggregator and an application provider. Therefore it’s possible for the connection aggregator, the application provider and the content provider to be the same company.  Attachment 4 provides a diagram of the roles involved in short code service delivery.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 7 of 35           1.3 Common Short Codes  Short codes are currently offered on a carrier-by-carrier basis with no coordination of codes for identical applications. This limits applications to specific carriers and requires end users to recognize the specific short codes used by their carrier. This type of approach fragments the marketing message and limits content provider participation.  CSCs are a specific type of short code that will enable the same short code across multiple carriers thus increasing traffic and reducing user confusion. This document addresses CSCs that will be administered by a single CSC Administrator for a group of US wireless carriers.  A CSC Registry provides the operational aspects of the Administrator’s functions. The Registry will maintain a single database of available, reserved, and registered CSCs. Some of the Registry’s responsibilities include; providing the day to day operations, administering the resource, implementing and maintaining the CSC administration platform, developing and implementing guidelines, and facilitating the manual and automated implementation of CSCs across multiple carriers.  In addition to the roles identified in Section 1.2, CSCs require two additional roles:            CSC Administrator — is the entity providing the administration of the CSCs. CTIA is the US Common Short Code Administrator.            CSC Registry — provides the operational aspects of the Administrator’s functions. NeuStar is the US Common Short Code Registry.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 8 of 35              2.   Common Short Codes Namespace    The industry will introduce the CSC service in 4Q03 using CSCs in the format of five (5) and six (6) digit short codes. The digits 0 and 1 will not be used as the first digit of a CSC to avoid potential conflicts with existing dialing plans. The potential CSCs at introduction will be within the ranges:                      Five Digit CSCs:  20000-99999 = 80,000 potential CSCs                     Six Digit CSCs:   222222-999999 = 777,778 potential CSCs   Some short codes within the range of potential CSCs will be reserved and therefore will not be available for assignment as a CSC. The remaining short codes within the defined range are eligible for use as CSCs. Each carrier retains the right to support traffic, or not support traffic for a leased CSC. However a carrier cannot use a leased CSC for a purpose other than that which it has been leased during its term.  CSCs are only to be used between mobile devices and applications. A CSC registrant cannot lease, sublicense or otherwise transfer a CSC nor the rights to an application within that CSC to a third party, in accordance with the Registrant Sublicense Agreement.  2.1 Reserved Short Codes  Reserved Short Codes are short codes within the range of potential CSCs that are reserved for other purposes and therefore are not available to be used as CSCs. There are no code-specific charges associated with reserved codes. There are two categories of reserved codes;       •   Grandfathered — those currently used by carriers to provide short code related services        •   Carrier-specific — those reserved after introduction of the CSC service by an individual carrier    2.1.1 Grandfathered Codes  Individual carriers and groups of carriers have introduced short code related services using short codes that fall within the range of the 5 or 6 digit CSCs. It is necessary for the Registry to identify these short codes and reserve them so that they are not included in the pool of available CSCs.  Prior to the introduction of the CSC service each carrier will provide the Registry a list of short codes it is currently using within the defined 5 or 6 digit range. The Registry will register these codes as unavailable; they will be grandfathered for the carrier. They will not be able to be registered as a random CSC, selected CSC, or carrier-specific code.  The Registry will register; 1) the code and 2) the carrier. The effective date for all grandfathered codes will be 15 days prior to introduction of the CSC service. (The date of CSC service introduction will be determined by a written agreement between the CSC Administrator and the CSC Registry.) The Registry will only disclose that the code is not available for registration as a CSC. It will not disclose the carrier that registered the code.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 9 of 35           If a Carrier decides that it is no longer necessary to reserve the grandfathered code they may contribute the code to the pool of CSCs. This process is depicted in Attachment 2. The carrier’s primary point of contact with the Registry will send an email to the Registry identifying the code(s) contributed and the date of contribution. The Registry will store a copy of the correspondence in its records.  It is possible that more than one carrier will have claimed the code as a grandfathered code. If no other carrier still has the code reserved as a grandfathered code it will be placed in the pool of CSCs and will start a 90-day aging period where it cannot be assigned as a CSC. Carriers will be notified, via email, each time a grandfathered code enters the 90-day aging period. They will not be told which carrier contributed it. Any carrier can reserve the code as a carrier-specific code during the 90-day aging period.  2.1.2 Carrier-specific Codes  After implementation of the CSC service carriers will still have the ability to reserve short codes within the range of CSCs for its own purposes as long as the code is not already registered. If the code is already registered as a CSC the carrier’s reservation request will be denied. The lessee has the right to renew that same code when its term is expiring, assuming it has abided by the terms of the registrant sub-license agreement. Once a carrier reserves a carrier-specific code it is removed from the pool of available CSCs.  The Registry will register; 1) the code, 2) the carrier, and 3) the date it was reserved. The Registry will only disclose that the code is not available for registration as a CSC. It will not disclose the carrier that registered the code.  If a Carrier decides that it is no longer necessary to reserve the carrier-specific code they can contribute it to the pool of CSCs following the process defined in Section 2.1.1.  2.2 Common Short Codes  Common Short Codes (CSCs) are those short codes within the defined range available for registration as a CSC. CSCs are subject to registrations fees from the Registry. There are two types of CSCs;       •   Random CSCs — the applicant registers a CSC randomly selected by the Registry        •   Selected CSCs — the applicant selects the CSC that it wants to register    2.2.1 Random CSCs  Applicants can choose to have a CSC randomly assigned to their application by the Registry. In the event that the applicant chooses a random CSC the CSC will not be assigned to the application until the Registry approves the application. A CSC will be assigned using an algorithm that searches the list of available CSCs.  2.2.2 Selected CSCs  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 10 of 35           Applicants can select a specific CSC for their application. Selected CSCs will be assigned on a first-come first-served basis. Prior to submitting the application the applicant can perform a CSC query to determine the availability of the desired CSC. If the applicant requests a CSC that is reserved or already registered the application will automatically be rejected. The applicant will have the opportunity to select a different CSC. If the CSC is available the Registry will review the application. Once the Registry receives the application it will be timestamped with the date and time in the event that there is a conflict between two applicants requesting the same CSC. The requested code will be placed in reserved status until the application is rejected or accepted.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 11 of 35              3.   Common Short Code Users    The Registry website will be available to the public for the purposes of finding general information regarding CSCs. There are three entities that will have secure access to the Registry system and be able to view specific information about specific CSCs. Those are:       •   Applicants — those that have submitted an application CSC, but have not yet had it approved by the Registry        •   Registrants — those that have applied for and been assigned a CSC        •   Carriers — telecommunications service providers that will be notified of the CSC assignment and may decide to implement the CSC in their network    3.1 Applicant Account Set-up  An entity that decides to submit an application for a CSC will first be required to set up an account with the Registry. If the applicant has already set up an account the applicant can go directly to the Existing User Login page and login with their user name and password.  If the applicant does not have an account it must first set one up by filling out the appropriate information (see Applicant Information section of application form in Attachment 1 of this document) at the Account Set-up page. Once the potential applicant has an account they can then log on to the Registry system and fill out a CSC application (see Attachment 1). The application is sent to the Registry for review. Once they submit an application they can review the status of that application through their secure access to the Registry system.  Applicants have the following permissions:       •   Modify account information        •   Receive alerts related to applications        •   View status with regard to pending applications (e.g., approved or rejected with comments)    3.2 Registrants  Once the Registry approves the application the selected or random CSC is assigned to the application. At this point the applicant’s status changes to that of a registrant because they are no longer awaiting assignment of the CSC.  Registrants have the following permissions:       •   Modify account information        •   Receive alerts related to registered CSCs        •   View all of their existing registration records        •   View assigned CSC status information such as carrier expiration date        •   Submit modification request of certain CSC information (excluding the name of the Content Provider) and view status        •   Submit renewal request for CSC and view status    Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 12 of 35           3.3 Carriers  The Registry will work directly with representatives from the Carriers to identify a primary point of contact (POC). The Registry will set up an account for the POC, with a User Name and Password provided by the POC. The POC can modify the Password once they log-on to the Registry system.  The POC will have the following permissions:       •   Modify account information        •   Receive all carrier alerts generated by the Registry        •   View applications (excluding payment information such as credit card numbers)        •   Submit carrier status information related to specific CSCs (e.g., opt-in, opt-out)        •   Add other carrier contacts for the purposes of receiving alerts, viewing applications, or submitting status information    If there is a need to change the POC the Registry will work directly with the current POC.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 13 of 35              4.   Common Short Code Application Process    Registry users with an active account can submit an application for a CSC. The processes defined in this section are depicted in Attachment 2.  4.1 Application Submission  Applicants can submit an application by logging on to the Registry system using their User name and Password. If they plan on applying for a Selected CSC they should first perform a CSC query to determine if the desired CSC is available for assignment. If the desired CSC is designated as unavailable the applicant should not request it, the application will automatically be rejected.  To fill out an application the applicant would go to the CSC Application page on the secure website. The applicant can request up to twenty CSCs on one application form. Since the applicant has already set up an account with the Registry the applicant information portion of the application will already be filled out with their specific information. The applicant will then fill out the rest of the application. A CSC can be reserved for three, six, and twelve month terms.  Once the application is complete the applicant will hit the Submit button on the application. The Registry will receive an alert (all alerts associated with the Registry are via email) that an application was submitted and the application will be placed in the Registry’s work item list. (A work item list is the first page a user views after they logon to the Registry system. Attachment 3 provides examples of the work item lists provided by the Registry for each of the users.) If the application is properly submitted the applicant will receive an alert from the Registry that the application was received and will be reviewed.  4.2 Registry Review  The Registry will review the application for completeness and whether information on the application is erroneous on its face. If the application is not complete or found to be in error it will be rejected with an explanation. The applicant will receive an alert from the Registry that the application was rejected. They can then log-on to the Registry system and review the Registry’s explanation as to why it was rejected. The rejected application will be on the applicant’s work item list. If the applicant had selected a specific CSC that CSC will be reserved for the next fourteen (14) calendar days so the applicant has an opportunity to modify and resubmit their application.  Once the Registry approves an application a CSC will be assigned. If they requested a random CSC the Registry system will use a random selection algorithm to assign a CSC to the application. If they chose a Selected CSC that CSC will be assigned to the application. Upon approval the applicant/registrant and the carriers will receive an alert from the Registry that the application was approved. They can then log-on to the Registry system and view the approved application.  The information included in the application will then become part of a CSC registration record. This will serve as the form that will be viewed by the registrant, Registry and Carriers on an ongoing basis.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 14 of 35           All of the Carriers will receive an alert that a CSC has been assigned and a registration record is available to be reviewed.  The carriers can log-on to the Registry system to review the registration records. These registration records will appear in their work item list. If the carrier has any questions about the registration they can contact either the Registry or the registrant by phone or email.  4.3 CSC Addressing File  The CSC addressing file is generated from the registration records in the Registry’s master CSC address database. It is an ASCII text file containing the mapping information for CSCs and their respective Application Providers. The Registry updates the file every Friday and makes it available for download from the secure website. Carrier’s can use the file to create or verify its own CSC addressing tables.  Each line in the CSC addressing file constitutes one CSC to Application Provider mapping record whose fields are delimited by a comma (“,”). The format of the record is defined as follows:  <CSC>,<Application Provider>,<Expiration Date>,<Program Start Date>, <Program End Date>  where <CSC> is a common short code, <Application Provider> is the identity string of the Application Provider whose application is addressed by the CSC, <Expiration Date> is the expiration date of the CSC, <Program Start Date> is the date when the content program of the CSC starts, and <Program End Date> is the date when the content program of the CSC terminates.  The date format is “MM/DD/YYYY”, where MM is the two digits for a month, DD is the two digits for a date, and “YYYY” is the four digits for the year. They are separated by the forward slash (“/”). This format applies to the three date fields in a record. For single digit month or date, the left digit is default to zero (“0”).  4.4 Carrier Implementation Status  Each participating Carrier will be able to register their status with regard to whether they plan to opt-in or opt-out of the program associated with the specific CSC. The default condition will be no reply. This status information will not be disclosed, in any way, to other carriers or applicants.  4.5 CSC Expiration  Before a CSC’s term expires, the registrant and the Carriers will receive alerts notifying them of the expiration date. The alerts will be sent 30 days, 15 days, 5 days and 1 day prior to the expiration date. When the term expires the registrants and Carriers will receive an alert notifying them that the CSC has expired and it is no longer assigned to the registrant.  Once a CSC expires it is given a ninety-day aging period where it will not be available for assignment. The aging period also serves as a grace period where the past registrant can renew the registration. Once the aging period expires the CSC will be placed in the pool of available CSCs.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 15 of 35           4.6 Modify Existing Registrations  Registrant’s must notify the Registry when any information in its registration record changes. The Registrants will access the Registry’s system to modify the existing registration record. Once it is modified it will be submitted to the Registry for approval and will follow the same process defined in Section 4.2 for a new application.  4.7 Opt-in / Spam Protection  To avoid costly customer complaints due to unsolicited messages, every application must be offered on an “opt-in” basis. This requires the customer to initially participate by sending a MO message to the application or registering on a web page for the service. Customer opt-ins will be on a per campaign basis, i.e. opting in to a particular campaign does not extend to other campaigns that might be offered by the same application or content provider. A registrant may use the opt-in database created by one campaign for future campaigns, but first must obtain approval on a carrier-by-carrier basis for each new campaign.  At the time of the sign-up or opt-in, the customer needs to be clearly identified by their MSISDN and the time of the subscription shall be recorded. Users who register via a web page must be verified as the actual owner of the registered number. For example, pass codes can be sent to a registered number and registration will remain incomplete until the pass code is entered.  Furthermore, all application providers must be capable of tracing and shutting down potential Spam sources and provide customers an easy and intuitive way to opt-out of CSC applications. A universal keyword may be used to opt customers out of CSC applications. Customers would be able to opt-out of any CSC application by sending the same keyword (e.g. cancel) to the application short code.  It shall be the role of the carrier to determine whether a specific program used in connection with the CSC is not adhering to these Opt-in / Spam Protection requirements. In such an event, the carrier will discontinue service to that CSC or to entities associated with providing services for that CSC.  4.8 Monitoring Applicant and Registrant Behavior  It’s possible that some Applicants and Registrants could attempt to abuse the CSC administrative process. One example of abuse is registering a CSC for the purposes of stopping another entity from registering it or for the purposes of reselling it. The Registry will monitor the behavior of Applicants and Registrants in order to identify any potential abusive behavior. If the Registry identifies any potentially abusive behavior it will contact the Applicant or Registrant and attempt to understand and if necessary correct the behavior. It may ultimately be necessary for the Registry to take corrective action such as closing the Applicant account.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 16 of 35              5.   Common Short Code Customer Care    5.1 Registry User Customer Care Customer care will be able to address any issues related to the Registry function such as status of applications, questions about how to fill out an application and issues concerning user profiles. Users can communicate with customer service via phone calls, email or fax. Standard hours of operation are 9AM to 8PM Eastern Time, Monday through Friday, excluding holidays. There will also be customer care support beyond standard hours via pager. Of course they will restrict access to information in the same manner that the Registry system does. For example one registrant cannot find out information about another registrant’s CSC.  5.2 Public Website  The Registry public website is a place where interested parties can go to obtain general information about CSCs. There will be FAQs, general descriptions of CSC related applications and services, general descriptions of Registry functions and processes, and other general informational documentation.  In addition to general information the public will be able to perform a query on a specific CSC to see whether it is available for assignment. The only information provided to the public will be whether the code is available or not available.  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 17 of 35           ATTACHMENT 1 TO GUIDELINES [SEE EXHIBIT E-1 BELOW]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 18 of 35           ATTACHMENT 2 TO THE ASSIGNMENT GUIDELINES [PAGE LEFT INTENTIONALLY BLANK]       [Graphic Omitted: Account Creation]  [Graphic Omitted: Account Log in]  [Graphic Omitted: Account Expiration]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 19 of 35           ATTACHMENT 3 TO THE ASSIGNMENT GUIDELINES: WORK ITEM LISTS  CSCA Home Page:  [Graphic Omitted: CSCA Home Page]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 20 of 35           Account Creation:  [Graphic Omitted: Account Creation]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 21 of 35           Account Creation — continued:  [Graphic Omitted: Account Creation — continued]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 22 of 35           Check CSC Availability:  [Graphic Omitted: Check CSC Availability]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 23 of 35           Possible results of availability check:  [Graphic Omitted: Possible results of availability check]  [Graphic Omitted: Public Search Page]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 24 of 35           Registrant / Applicant Specific Forms:  Applicant work list:  [Graphic Omitted: Applicant work list]  Update Registrant Account information:  [Graphic Omitted: Registrant Account Information]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 25 of 35           Search for CSC codes from Registrant Home Page:  [Graphic Omitted: Search for CSC codes from Registrant Home Page]  Application for new CSC code(s): See Schedule 1 to Exhibit E of the Common Short Code Administration License Agreement  Confirmation Page:  [Graphic Omitted: Confirmation Page]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 26 of 35           Carrier Specific Forms:  Carrier work list:  [Graphic Omitted: Carrier work list]  Review Application / Opt-in or Opt-out:  [Graphic Omitted: Opt-in or Opt-out]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 27 of 35           After selection to Opt-in for a CSC:  [Graphic Omitted: After selection to Opt-in for a CSC]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 28 of 35           Search for Specific CSC Registration:  [Graphic Omitted: Search for Specific CSC Registration]  View Reserved Short Code List:  [Graphic Removed: View Reserved Short Code List]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 29 of 35           Pending Payment Applications:  [Graphic Omitted: Pending Payment Applications]  Update Account Information:  [Graphic Omitted: Update Account Information]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 30 of 35           ATTACHMENT 4 TO THE ASSIGNMENT GUIDELINES [SEE NEXT PAGE, THIS PAGE INTENTIONALLY BLANK]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 31 of 35           [Graphic Omitted: CSC Functional Roles]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 32 of 35           SCHEDULE 1 TO EXHIBIT E OF THE COMMON SHORT CODE ADMINISTRATION AGREEMENT Application Form  Application for new CSC code(s):  [Graphic Omitted: Application for new CSC code(s)]  Application for new CSC code(s) — continued:  [Graphic Omitted: Application for new CSC code(s) — continued]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 33 of 35           Application for new CSC code(s) — continued:  [Graphic Omitted: Application for new CSC code(s) — continued]  Application for new CSC code(s) — continued:  [Graphic Omitted: Application for new CSC code(s) — continued]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 34 of 35           Application for new CSC code(s) — continued:  [Graphic Omitted: Application for new CSC code(s) — continued]  Second Amendment to Common Short Code License Agreement v. 1 January 5, 2006 Page 35 of 35           EX-10.38.1 7 w17665exv10w38w1.htm EX-10.38.1    exv10w38w1       Exhibit 10.38.1  AMENDMENT NO. 3 TO CREDIT AGREEMENT AND WAIVER       This Amendment No. 3 and Waiver to Credit Agreement (this “Agreement”) dated as of February 15, 2005 is made by and between NEUSTAR, INC., a Delaware corporation having its principal place of business in Sterling, Virginia (the “Borrower”), and BANK OF AMERICA, N.A., a national banking association organized and existing under the laws of the United States (“Bank of America”), in its capacity as administrative agent for the Lenders (as defined in the Credit Agreement (as defined below)) (in such capacity, the “Administrative Agent”), and each of the Lenders signatory hereto, and each of the Guarantors (as defined in the Credit Agreement) signatory hereto.  WITNESSETH:       WHEREAS, the Borrower, the Administrative Agent and the Lenders have entered into that certain Credit Agreement dated as of August 14, 2002, as amended by Amendment No, 1 to Credit Agreement dated as of October 1, 2003 and Amendment No. 2 to Credit Agreement dated as of August 30, 2004 (and as hereby amended and as from time to time hereafter further amended, modified, supplemented, restated, or amended and restated, the “Credit Agreement”; capitalized terms used in this Agreement not otherwise defined herein shall have the respective meanings given thereto in the Credit Agreement), pursuant to which the Lenders have made available to the Borrower a revolving credit facility, including a letter of credit facility; and       WHEREAS, in respect of Amendment No. 2, the parties intended and agreed that the Maturity Date under the Credit Agreement would be extended for 180 days; and       WHEREAS, Amendment No. 2 contained an scrivener’s error and incorrectly stated that the Maturity Date was amended to be “January 8, 2005” rather than “February 15, 2005”; and       WHEREAS, the Borrower desires to extend the Maturity Date until August 15, 2005, and       WHEREAS, the Borrower has requested that the Credit Agreement he amended to reflect such extension in the Maturity Date;       WHEREAS, on February 1, 2005, the Borrower acquired Fiducianet, Inc., a Delaware corporation for a purchase price of 52,200,000 in cash and 25,533 share of common stock of the Borrower (the “Fiducianet Acquisition”) ; and       WHEREAS, the Borrower has requested that the Lenders waive the requirements of the Pledge Agreement and Section 7.12 of the Credit Agreement with respect to the Fiducianet Acquisition;               NOW, THEREFORE, in consideration of the premises and further valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties hereto agree as follows:       1. Amendments to Credit Agreement. Subject to the terms and conditions set forth herein, the Credit Agreement is hereby amended as follows:       A. Section 1.11 is amended to restate the definition of “Maturity Date” in its entirety to read as follows:       “Maturity Date” means August 15, 2005.       B. Section 8.03 is amended to restate clause (g) thereof in its entirety to read as follows:       (g) unsecured Indebtedness in an aggregate principal amount not to exceed (i) 51,500,000 at any time outstanding during the period from the Closing Date through and including December 31, 2002 and (ii) $2,500,000 at any time outstanding after December 31, 2002 (but excluding from such amount up to $3,000,000 of Indebtedness owing to Bank of America, N.A., and incurred by the Borrower by an assumption of debt on behalf of NeuStar Funding, which Indebtedness was originally incurred by NeuStar Funding pursuant to a Credit Agreement dated as of October 1, 2003);       2. Waiver of Joinder and Other Requirements with Respect to Fiducianet Acquisition. Subject to the terms and conditions set forth herein, the Lenders hereby waive (i) any Default arising under the Credit Agreement solely as a result of the Fiducianet Acquisition and (ii) the requirements of Section 7..12 of the Credit Agreement with respect to Fiducianet, Inc. In addition, all requirements of the Pledge Agreement with respect to the Subsidiary Securities of Fiducianet, Inc. are hereby waived.       3. Effectiveness: Conditions Precedent. The effectiveness of this Agreement and the amendments to the Credit Agreement herein provided are subject to the satisfaction of the following conditions precedent:       (a) the Administrative Agent shall have received each of the following documents or instruments in form and substance reasonably acceptable to the Administrative Agent:       (i)   four (4) original counterparts of this Agreement, duly executed by the Borrower, the Administrative Agent, each Guarantor and the Required Lenders; and        (ii)   such other documents, instruments, opinions, certifications, undertakings, further assurances and other matters as the Administrative Agent shall reasonably request; and    2            (b) all fees and expenses payable to the Administrative Agent and the Lenders (including the reasonable fees and expenses of counsel to the Administrative Agent estimated to date) shall have been paid in full (without prejudice to final settling of accounts for such fees and expenses).       4. Consent of the Guarantors. Each Guarantor hereby consents, acknowledges and agrees to the amendments set forth herein and hereby confirms and ratifies in all respects the Guaranty to which such Guarantor is a party (including without limitation the continuation of such Guarantor’s payment and performance when due of the obligations thereunder upon and after the effectiveness of this Agreement and the amendments contemplated hereby) and the enforceability of such Guaranty against such Guarantor in accordance with its terms.       5. Representations and Warranties. In order to induce the Administrative Agent and the Lenders to enter into this Agreement, the Borrower represents and warrants to the Administrative Agent and the Lenders as follows:       (a) The representations and warranties made by the Borrower in Article VI of the Credit Agreement and in each of the other Loan Documents to which it is a party are true and correct on and as of the date hereof, except to the extent that such representations and warranties expressly relate to an earlier date;       (b) Since the date of the most recent financial reports of the Borrower delivered pursuant to Section 7.01 of the Credit Agreement, no act, event, condition or circumstance has occurred or arisen which, singly or in the aggregate with one or more other acts, events, occurrences or conditions (whenever occurring or arising), has had or could reasonably he expected to have a Material Adverse Effect;       (c) The Persons appearing as Guarantors on the signature pages to this Agreement constitute all Persons who are required to be Guarantors pursuant to the terms of the Credit Agreement and the other Loan Documents, including without limitation all Persons who became Subsidiaries or were otherwise required to become Guarantors after the Closing Date, and each of such Persons has become and remains a party to a Guaranty as a Guarantor;       (d) This Agreement has been duly authorized, executed and delivered by the Borrower and the Guarantors and constitutes a legal, valid and binding obligation of such parties, except as may be limited by genera’ principles of equity or by the effect of any applicable bankruptcy, insolvency, reorganization, moratorium or similar law affecting creditors’ rights generally; and       (e) No Default or Event of Default has occurred and is continuing.       6. Entire Agreement. This Agreement, together with all the Loan Documents (collectively, the “Relevant Documents”), sets forth the entire understanding and agreement of the parties hereto in relation to the subject matter hereof and supersedes any prior negotiations and agreements among the parties relating to such subject matter. No promise, condition, representation or warranty, express or implied, not set forth in the Relevant Documents shall bind any party hereto, and no such party has relied on any such promise, condition,  3       representation or warranty, Each of the parties hereto acknowledges that, except as otherwise expressly stated in the Relevant Documents, no representations, warranties or commitments, express or implied, have been made by any party to the other. None of the terms or conditions of this Agreement may be changed, modified, waived or canceled orally or otherwise, except in writing and in accordance with Section 11.01 of the Credit Agreement,       7. Full Force and Effect of Agreement. Except as hereby specifically amended, modified or supplemented, the Credit Agreement and all other Loan Documents are hereby confirmed and ratified in all respects and shall be and remain in full force and effect according to their respective terms.       8. Counterparts. This Agreement may be executed in any number of counterparts, each of which shall be deemed an original as against any party ‘.hose signature appears thereon, and all of which shall together constitute one and the same instrument.       9. Governing Law. This Agreement shall in all respects be governed by, and construed in accordance with, the laws of the State of New York applicable to contracts executed and to be performed entirely within such State, and shall be further subject to the provisions of Section 11.16 of the Credit Agreement.       10. Enforceability. Should any one or more of the provisions of this Agreement be determined to be illegal or unenforceable as to one or more of the parties hereto, all other provisions nevertheless shall remain effective and binding on the parties hereto.       11. References. All references in any of the Loan Documents to the “Credit Agreement” shall mean the Credit Agreement, as amended hereby.       12. Successors and Assigns. This Agreement shall be binding upon and inure to the benefit of the Borrower, the Administrative Agent and each of the Guarantors and the Lenders, and their respective successors, lea] representatives, and assignees to the extent such assignees arc permitted assignees as provided in Section 11.07 of the Credit Agreement.  [Signatures on following page.]  4            IN WITNESS WHEREOF, the parties hereto have caused this Amendment No. 3 to Credit Agreement and Waiver to be made, executed and delivered by their duly authorized officers as of the day and year first above written.  BORROWER:  NEUSTAR, INC.  By: /s/ Jeffrey E. Ganek                     Name: Jeffrey E. Ganek Title: Chairman   GUARANTORS:  BIZTELONE, INC.  By: /s/ Jeffrey E. Ganek                     Name: Jeffrey E. Ganek Title: CEO   NIGHTFIRE ACQUISITION CORPORATION  By: /s/ Jeffrey E. Ganek                     Name: Jeffrey E. Ganek Title: CEO           ADMINISTRATIVE AGENT:  BANK OF AMERICA, N.A., as Administrative Agent  By: /s/ Barbara P. Levy                     Name: Barbara P. Levy Title: Senior Vice President  LENDERS:  BANK OF AMERICA, N.A.,  By: /s/ Barbara P. Levy                     Name: Barbara P. Levy Title: Senior Vice President           EX-10.38.2 8 w17665exv10w38w2.htm EX-10.38.2    exv10w38w2       Exhibit 10.38.2  AMENDMENT NO. 5 TO CREDIT AGREEMENT       This Amendment No. 5 to Credit Agreement (this “Agreement”) dated as of February 10, 2006 is made by and between NEUSTAR, INC., a Delaware corporation having its principal place of business in Sterling, Virginia (the “Borrower”), and BANK OF AMERICA, N.A., a national banking association organized and existing under the laws of the United States (“Bank of America”), in its capacity as administrative agent for the Lenders (as defined in the Credit Agreement (as defined below)) (in such capacity, the “Administrative Agent”), and each of the Lenders signatory hereto, and each of the Guarantors (as defined in the Credit Agreement) signatory hereto.  WITNESSETH:       WHEREAS, the Borrower, the Administrative Agent and the Lenders have entered into that certain Credit Agreement dated as of August 14, 2002, as amended by Amendment No. 1 to Credit Agreement dated as of October 1, 2003, Amendment No. 2 to Credit Agreement dated as of August 30, 2004, Amendment No. 3 to Credit Agreement and Waiver dated as of February 15, 2005 and Amendment No. 4 to Credit Agreement dated as of August 12, 2005 (and as hereby amended and as from time to time hereafter further amended, modified, supplemented, restated, or amended and restated the “Credit Agreement”; capitalized terms used in this Agreement not otherwise defined herein shall have the respective meanings given thereto in the Credit Agreement), pursuant to which the Lenders have made available to the Borrower a revolving credit facility, including a letter of credit facility; and       WHEREAS, the Maturity Date of such revolving credit facility is February 10, 2006; and       WHEREAS, the Borrower has requested that the Credit Agreement be amended to extend the Maturity Date to August 10, 2006;       NOW, THEREFORE, in consideration of the premises and further valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties hereto agree as follows:       1. Amendment to Credit Agreement. Subject to the terms and conditions set forth herein. Section 1.01 of the Credit Agreement is amended to restate the definitions of “Maturity Date” in its entirety to read as follows:            “Maturity Date” means August 10, 2006.       2. Effectiveness: Conditions Precedent. The effectiveness of this Agreement and the amendments to the Credit Agreement herein provided are subject to the satisfaction of the following conditions precedent:       (a) the Administrative Agent shall have received each of the following documents or instruments in form and substance reasonably acceptable to the Administrative Agent:               (i)   four (4) original counterparts of this Agreement, duly executed by the Borrower, the Administrative Agent, each Guarantor and the Required Lenders; and        (ii)   such other documents, instruments, opinions, certifications, undertakings, further assurances and other matters as the Administrative Agent shall reasonably request: and         (b) all fees and expenses payable to the Administrative Agent and the Lenders (including the reasonable fees and expenses of counsel to the Administrative Agent estimated to date) shall have been paid in full (without prejudice to final settling of accounts for such fees and expenses).       3. Consent of the Guarantors. Each Guarantor hereby consents, acknowledges and agrees to the amendments set forth herein and hereby confirms and ratifies in all respects the Guaranty to which such Guarantor is a party (including without limitation the continuation of such Guarantor’s payment and performance when due of the obligations thereunder upon and after the effectiveness of this Agreement and the amendments contemplated hereby) and the enforceability of such Guaranty against such Guarantor in accordance with its terms.       4. Representations and Warranties. In order to induce the Administrative Agent and the Lenders to enter into this Agreement, the Borrower represents and warrants to the Administrative Agent arid the Lenders as follows:       (a) The representations and warranties made by the Borrower in Article VI of the Credit Agreement and in each of the other Loan Documents to which it is a party are true and correct on and as of the date hereof, except to the extent that such representations and warranties expressly relate to an earlier date;       (b) Since the date of the most recent financial reports of the Borrower delivered pursuant to Section 7.01 of the Credit Agreement, no act, event, condition or circumstance has occurred or arisen which, singly or in the aggregate with one or more other acts, events, occurrences or conditions (whenever occurring or arising), has had or could reasonably be expected to have a Material Adverse Effect;       (c) The Persons appearing as Guarantors on the signature pages to this Agreement constitute all Persons who are required to be Guarantors pursuant to the terms of the Credit Agreement and the other Loan Documents, (except as may have been waived in writing by the Required Lenders) including without limitation all Persons who became Subsidiaries or were otherwise required to become Guarantors after the Closing Date, and each of such Persons has become and remains a party to a Guaranty as a Guarantor;       (d) This Agreement has been duly authorized, executed and delivered by the Borrower and the Guarantors and constitutes a legal, valid and binding obligation of such parties, except as may be limited by general principles of equity or by the effect of any applicable bankruptcy, insolvency, reorganization, moratorium or similar law affecting creditors’ rights generally; and  2            (e) No Default or Event of Default has occurred and is continuing.       5. Entire Agreement. This Agreement, together with all the Loan Documents (collectively, the “Relevant Documents”), sets forth the entire understanding and agreement of the parties hereto in relation to the subject matter hereof and supersedes any prior negotiations and agreements among the parties relating to such subject matter. No promise, condition, representation or warranty, express or implied, not set forth in the Relevant Documents shall bind any party hereto, and no such party has relied on any such promise, condition, representation or warranty. Each of the parties hereto acknowledges that, except as otherwise expressly stated in the Relevant Documents, no representations, warranties or commitments, express or implied, have been made by any party to the other. None of the terms or conditions of this Agreement may he changed, modified, waived or canceled orally or otherwise, except in writing and in accordance with Section 11.01 of the Credit Agreement.       6. Full Force and Effect of Agreement. Except as hereby specifically amended, modified or supplemented, the Credit Agreement and all other Loan Documents are hereby confirmed and ratified in all respects and shall he and remain in full force and effect according to their respective terms.       7. Counterparts. This Agreement may be executed in any number of counterparts, each of which shall be deemed an original as against any party whose signature appears thereon, and all of which shall together constitute one and the same instrument.       8. Governing Law. This Agreement shall in all respects be governed by, and construed in accordance with, the laws of the State of New York applicable to contracts executed and to be performed entirely within such State, and shall be further subject to the provisions of Section 11.16 of the Credit Agreement.       9. Enforceability. Should any one or more of the provisions of this Agreement be determined to be illegal or unenforceable as to one or more of the parties hereto, all other provisions nevertheless shall remain effective and binding on the panics hereto.       10. References. All references in any of the Loan Documents to the “Credit Agreement” shall mean the Credit Agreement, as amended hereby.       11. Successors and Assigns. This Agreement shall be binding upon and inure to the benefit of the Borrower, the Administrative Agent and each of the Guarantors and the Lenders, and their respective successors, legal representatives, and assignees to the extent such assignees are permitted assignees as provided in Section 11.07 of the Credit Agreement.  3            IN WITNESS WHEREOF, the parties hereto have caused this Amendment No. 5 to Credit Agreement to be made, executed and delivered by their duly authorized officers as of the day and year first above written.  BORROWER:  NEUSTAR, INC.  By: /s/ Jeffrey Babka                     Name: Jeffrey Babka Title: CFO   GUARANTORS:  BIZTELONE, INC.  By: /s/ Jeffrey Babka                     Name: Jeffrey Babka Title: CFO   NIGHTFIRE ACQUISITION CORPORATION  By: /s/ Jeffrey Babka                     Name: Jeffrey Babka Title: CFO           ADMINISTRATIVE AGENT:  BANK OF AMERICA, N.A. as Administrative Agent  By: /s/ Barbara P. Levy                     Name: Barbara P. Levy Title: Senior Vice President           LENDERS:  BANK OF AMERICA, N.A.  By: /s/ Barbara P. Levy                     Name: Barbara P. Levy Title: Senior Vice President           EX-21.1 9 w17665exv21w1.htm EX-21.1    exv21w1       Exhibit 21.1  Subsidiaries of the Registrant              Company Name   Jurisdiction of Organization     BizTelOne, Inc.    Delaware   Foretec Seminars, Inc.    Delaware   NeuLevel, Inc.    Delaware   NeuStar Funding, LLC    Delaware   NeuStar International, Inc.    Delaware   NeuStar International Services, Inc.    Delaware   NeuStar Secretariat Services, LLC    Delaware   NeuStar Subsidiary Corporation    Delaware             EX-23.1 10 w17665exv23w1.htm EX-23.1    exv23w1       Exhibit 23.1  CONSENT OF INDEPENDENT REGISTERED PUBLIC ACCOUNTING FIRM       We consent to the incorporation by reference in the Registration Statement (Form S-8 No. 333-128418) pertaining to the 1999 Equity Incentive Plan and the 2005 Stock Incentive Plan of NeuStar, Inc. of our report dated March 10, 2006, with respect to the consolidated financial statements and schedule of NeuStar, Inc., included in the Annual Report (Form 10-K) for the year ended December 31, 2005.  /s/ Ernst & Young LLP  McLean, Virginia March 24, 2006              EX-31.1 11 w17665exv31w1.htm EX-31.1    exv31w1          Exhibit 31.1  CERTIFICATION OF CHIEF EXECUTIVE OFFICER  I, Jeffrey E. Ganek, certify that:     1.   I have reviewed this annual report on Form 10-K of NeuStar, Inc.;      2.   Based on my knowledge, this report does not contain any untrue statement of a material fact or omit to state a material fact necessary to make the statements made, in light of the circumstances under which such statements were made, not misleading with respect to the period covered by this report;      3.   Based on my knowledge, the financial statements, and other financial information included in this report, fairly present in all material respects the financial condition, results of operations and cash flows of the registrant as of, and for, the periods presented in this report;      4.   The registrant’s other certifying officer(s) and I are responsible for establishing and maintaining disclosure controls and procedures (as defined in Exchange Act Rules 13a-15(e) and 15d-15(e)) for the registrant and have:         a)   Designed such disclosure controls and procedures, or caused such disclosure controls and procedures to be designed under our supervision, to ensure that material information relating to the registrant, including its consolidated subsidiaries, is made known to us by others within those entities, particularly during the period in which this report is being prepared;        b)   Evaluated the effectiveness of the registrant’s disclosure controls and procedures and presented in this report our conclusions about the effectiveness of the disclosure controls and procedures, as of the end of the period covered by this report based on such evaluation; and        c)   Disclosed in this report any change in the registrant’s internal control over financial reporting that occurred during the registrant’s most recent fiscal quarter (the registrant’s fourth fiscal quarter in the case of an annual report) that has materially affected, or is reasonably likely to materially affect, the registrant’s internal control over financial reporting; and       5.   The registrant’s other certifying officer(s) and I have disclosed, based on our most recent evaluation of internal control over financial reporting, to the registrant’s auditors and the audit committee of the registrant’s board of directors (or persons performing the equivalent functions):         a)   All significant deficiencies and material weaknesses in the design or operation of internal control over financial reporting which are reasonably likely to adversely affect the registrant’s ability to record, process, summarize and report financial information; and        b)   Any fraud, whether or not material, that involves management or other employees who have a significant role in the registrant’s internal control over financial reporting.                      March 29, 2006    /s/ Jeffrey E. Ganek              Jeffrey E. Ganek             Chairman and Chief Executive Officer            (Principal Executive Officer)                 EX-31.2 12 w17665exv31w2.htm EX-31.2    exv31w2       Exhibit 31.2  CERTIFICATION OF CHIEF FINANCIAL OFFICER  I, Jeffrey A. Babka, certify that:     1.   I have reviewed this annual report on Form 10-K of NeuStar, Inc.;      2.   Based on my knowledge, this report does not contain any untrue statement of a material fact or omit to state a material fact necessary to make the statements made, in light of the circumstances under which such statements were made, not misleading with respect to the period covered by this report;      3.   Based on my knowledge, the financial statements, and other financial information included in this report, fairly present in all material respects the financial condition, results of operations and cash flows of the registrant as of, and for, the periods presented in this report;      4.   The registrant’s other certifying officer(s) and I are responsible for establishing and maintaining disclosure controls and procedures (as defined in Exchange Act Rules 13a-15(e) and 15d-15(e)) for the registrant and have:         a)   Designed such disclosure controls and procedures, or caused such disclosure controls and procedures to be designed under our supervision, to ensure that material information relating to the registrant, including its consolidated subsidiaries, is made known to us by others within those entities, particularly during the period in which this report is being prepared;        b)   Evaluated the effectiveness of the registrant’s disclosure controls and procedures and presented in this report our conclusions about the effectiveness of the disclosure controls and procedures, as of the end of the period covered by this report based on such evaluation; and        c)   Disclosed in this report any change in the registrant’s internal control over financial reporting that occurred during the registrant’s most recent fiscal quarter (the registrant’s fourth fiscal quarter in the case of an annual report) that has materially affected, or is reasonably likely to materially affect, the registrant’s internal control over financial reporting; and       5.   The registrant’s other certifying officer(s) and I have disclosed, based on our most recent evaluation of internal control over financial reporting, to the registrant’s auditors and the audit committee of the registrant’s board of directors (or persons performing the equivalent functions):         a)   All significant deficiencies and material weaknesses in the design or operation of internal control over financial reporting which are reasonably likely to adversely affect the registrant’s ability to record, process, summarize and report financial information; and        b)   Any fraud, whether or not material, that involves management or other employees who have a significant role in the registrant’s internal control over financial reporting.                      March 29, 2006    /s/ Jeffrey A. Babka              Jeffrey A. Babka             Senior Vice President and Chief Financial Officer            (Principal Financial Officer)                 EX-32.1 13 w17665exv32w1.htm EX-32.1    exv32w1       Exhibit 32.1  CERTIFICATION PURSUANT TO 18 U.S.C. 1350  Pursuant to 18 U.S.C. 1350, each of the undersigned certifies in his capacity as an officer of NeuStar, Inc. that, to the best of his knowledge:     1.   The annual report on Form 10-K of NeuStar, Inc. for the year ended December 31, 2005 fully complies with the requirements of Section 13(a) or 15(d) of the Securities Exchange Act of 1934; and       2.   Information contained in such annual report on Form 10-K fairly presents, in all material respects, the financial condition and results of operation of NeuStar, Inc.                          March 29, 2006    By:    /s/ Jeffrey E. Ganek                  Jeffrey E. Ganek                 Chief Executive Officer                       March 29, 2006    By:    /s/ Jeffrey A. Babka                  Jeffrey A. Babka                 Chief Financial Officer         This written statement is being furnished to the Securities and Exchange Commission as an exhibit to such Form 10-K. A signed original of this statement has been provided to NeuStar, Inc. and will be retained by NeuStar, Inc. and furnished to the Securities and Exchange Commission or its staff upon request.          EX-99.1 14 w17665exv99w1.htm EX-99.1    exv99w1       Exhibit 99.1  North American Numbering Council (NANC)  Functional Requirements Specification  Number Portability Administration Center (NPAC)  Service Management System (SMS)  Release 3.3.2a  March 9, 2006              Related Publications  NPAC SMS Interoperable Interface Specification (IIS), Version 3.3.2a March 9, 2006.  Illinois Commerce Commission Number Portability Administration Center and Service Management System Request for Proposal (ICC NPAC/SMS RFP), February 6, 1996.  Generic Requirements for SCP Application and GTT Function for Number Portability, ICC LNP Workshop SCP Generic Requirements Subcommittee.  Generic Switching and Signaling Requirements for Number Portability, version 1.03, ICC LNP Workshop Switch Generic Requirements Subcommittee, September 4, 1996.  Report on Local Number Portability, Industry Numbering Committee (INC).  FCC 96-286 First Report And Order, CC Docket No. 95-116, July 2, 1996.  CTIA Report on Wireless Portability Version 2, July 7, 1998    Release 3.3: © COPYRIGHT 1997 — 2006 NeuStar, Inc.  The Work may be freely redistributed subject to the terms of the GNU General Public License (the “GPL”), a copy of which may be found at ftp://prep.ai.mit.edu/pub/gnu/GPL , or requested by writing to FSF, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Any use of this Work is subject to the terms of the GPL. The “Work” covered by the GPL by operation of this notice and license is this document and any and all modifications to or derivatives of this document. Where the words “Program,” “software,” “source code,” “code,” or “files” are used in the GPL, users understand and agree that the “Work” as defined here is substituted for purposes of this notice and license.  The purpose of the NeuStar, Inc. copyright and GNU General Public License on this Work is to ensure that this Work and any subsequent derivations thereof remain non-proprietary.             Table of Contents    Table of Contents                    0.      PREFACE     0-0                 0.1      Document Structure     0-0                 0.2      Document Numbering Strategy     0-1                 0.3      Document Version History     0-2     0.3.1      Release 1.0     0-2     0.3.2      Release 2.0     0-2     0.3.3      Release 3.0     0-3     0.3.4      Release 3.1     0-3     0.3.5      Release 3.2     0-3     0.3.6      Release 3.3     0-3                 0.4      Abbreviations and Notations     0-4                 0.5      Document Language     0-6                 1.      INTRODUCTION     1-1                 1.1      NPAC SMS Platform Overview     1-1                 1.2      NPAC SMS Functional Overview     1-1     1.2.1      Provisioning Service Functionality     1-1     1.2.2      Disconnect Service Functionality     1-2     1.2.3      Repair Service Functionality     1-2     1.2.4      Conflict Resolution Functionality     1-2     1.2.5      Disaster Recovery and Backup Functionality     1-2     1.2.6      Order Cancellation Functionality     1-3     1.2.7      Audit Request Functionality     1-3     1.2.8      Report Request Functionality     1-3     1.2.9      Data Management Functionality     1-3     1.2.9.1     NPAC Network Data     1-3     1.2.9.2     Service Provider Data     1-4     1.2.9.3     Subscription Version Data     1-4     1.2.10     NPA-NXX Split Processing     1-4     1.2.11     Business Days/Hours     1-5     1.2.12     Timer Types     1-6     1.2.13     Recovery Functionality     1-6     1.2.13.1     Network Data Recovery     1-7     1.2.13.2     Subscription Data Recovery     1-7     1.2.13.3     Notification Recovery     1-8     1.2.13.4     Service Provider Data Recovery     1-8     1.2.14     Number Pooling Overview     1-9     1.2.15     Time References in the NPAC SMS     1-12     1.2.16     SV Type and Alternative SPID in the NPAC SMS     1-14                      Release 3.3:  © 1997 — 2006 NeuStar, Inc.    i  North American Numbering Council (NANC)          Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      1.3      Background     1-14                 1.4      Objective     1-17                 1.5      Assumptions     1-17                 1.6      Constraints     1-19                 2.      BUSINESS PROCESS FLOWS     2-1                 2.1      Provision Service Process     2-1     2.1.1      Service provider-to-service provider activities     2-1     2.1.2      Subscription version creation process     2-1     2.1.2.1     Create Subscription Version     2-2     2.1.2.2     Request missing/late notification     2-2     2.1.2.3     Final Concurrence Notification to Old Service Provider     2-2     2.1.3      Service providers perform physical changes     2-2     2.1.4      NPAC SMS “activate and data download” process     2-2     2.1.4.1     New Service Provider sends activation to NPAC SMS     2-2     2.1.4.2     NPAC SMS broadcasts network data to appropriate Service Providers     2-3     2.1.4.3     Failure — notify NPAC     2-3     2.1.4.4     Initiate repair procedures     2-3     2.1.5      Service providers perform network updates     2-3                 2.2      Disconnect Process     2-3     2.2.1      Customer notification, Service Provider initial disconnect service order activities     2-3     2.2.2      NPAC waits for effective release date     2-4     2.2.3      NPAC donor notification     2-4     2.2.4      NPAC performs broadcast download of disconnect data     2-4                 2.3      Repair Service Process     2-4     2.3.2      Service provider analyzes the problem     2-5     2.3.3      Service provider performs repairs     2-5     2.3.4      Request broadcast of subscription data     2-5     2.3.5      Broadcast repaired subscription data     2-6                 2.4      Conflict Process     2-6     2.4.1      Subscription version in conflict     2-6     2.4.1.1     Cancel-Pending Acknowledgment missing from new Service Provider     2-6     2.4.1.2     Old Service Provider requests conflict status     2-6     2.4.1.3     Change of status upon problem notification     2-6     2.4.1.4     Change of status upon Old Service Provider non-concurrence     2-6     2.4.1.5     Change of status upon New Service Provider non-concurrence     2-7     2.4.2      New Service Provider coordinates conflict resolution activities     2-7     2.4.2.1     Cancel pending notification     2-7     2.4.3      Subscription version cancellation     2-8     2.4.4      Conflict resolved     2-8                 2.5      Disaster Recovery and Backup Process     2-8     2.5.1      NPAC personnel determine downtime requirement     2-8     2.5.2      NPAC notifies Service Providers of switch to backup NPAC and start of cutover quiet period     2-8     2.5.3      Service providers connect to backup NPAC     2-8     2.5.4      Backup NPAC notifies Service Providers of application availability and end of cutover quiet period     2-9                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    ii  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      2.5.5      Service providers conduct business using backup NPAC     2-9     2.5.6      Backup NPAC notifies Service Providers of switch to primary NPAC and start of cutover quiet period     2-9     2.5.7      Service providers reconnect to primary NPAC     2-9     2.5.8      Primary NPAC notifies Service Providers of availability and end of cutover quiet period     2-9                 2.6      Service Order Cancellation Process     2-9     2.6.1      Service Provider issues service order cancellation     2-9     2.6.2      Service provider cancels an un-concurred Subscription Version     2-10     2.6.3      NPAC requests missing acknowledgment from Service Provider     2-10     2.6.4      NPAC cancels the Subscription Version and notifies both Service Providers     2-10                 2.7      Audit Request Process     2-10     2.7.1      Service provider requests audit     2-10     2.7.2      NPAC SMS issues queries to appropriate Service Providers     2-10     2.7.3      NPAC SMS compares Subscription Version data     2-11     2.7.4      NPAC SMS updates appropriate Local SMS databases     2-11     2.7.5      NPAC SMS sends report of audit discrepancies to requesting SOA     2-11     2.7.6      NPAC SMS sends report of audit results to requesting SOA     2-11                 2.8      Report Request Process     2-11     2.8.1      Service provider requests report     2-11     2.8.2      NPAC SMS generates report     2-11     2.8.3      Report delivered via NPAC Administrative or SOA Low-Tech Interface, Email, electronic file, fax, printer     2-12                 2.9     Data Administration Requests     2-12     2.9.1     Service provider requests administration of data by NPAC personnel     2-12     2.9.2     NPAC SMS personnel confirms user’s privileges     2-12     2.9.3     NPAC SMS personnel inputs user’s request     2-12     2.9.4     NPAC SMS performs user’s request     2-12     2.9.5     NPAC SMS personnel logs request denial if user’s privileges are not validated     2-12                 3.     NPAC DATA ADMINISTRATION     3-1                 3.1     Overview     3-1     3.1.1     Data Type Legend     3-1     3.1.2     NPAC Customer Data     3-2     3.1.3     Subscription Version Data     3-11     3.1.4     Network Data     3-19                 3.2     NPAC Personnel Functionality     3-21     3.2.1     Block Holder, Mass Update     3-23     3.2.2     Service Provider ID (SPID) Migration Update     3-24                 3.3     System Functionality     3-28                 3.4     Additional Requirements     3-32     3.4.1     NPA-NXX Data Validations     3-34                 3.5     NPA Splits Requirements     3-35     3.5.1     NPA-NXX-X, NPA Splits     3-43     3.5.2     Block Holder, NPA Splits     3-46                 3.6     NPA-NXX Filter Management Requirements     3-48                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    iii  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      3.7     Business Hour and Days Requirements     3-49                 3.8     Notifications     3-51     3.8.1     TN Range Notification Indicator     3-51     3.8.2     Customer No New SP Concurrence Notification Indicator     3-51     3.8.3     SOA Notification Priority     3-52     3.8.4     TN and Number Pool Block in Notifications     3-53     3.8.5     SV Type and Alternative SPID Indicators     3-54                 3.9     Multiple Service Provider Ids Per SOA Association Requirements     3-56                 3.10     Bulk Data Download Functionality     3-58     3.10.1     Bulk Data Download Functionality — General     3-58     3.10.2     Network Data, Bulk Data Download     3-58     3.10.3     Subscription Version, Bulk Data Download     3-60     3.10.4     NPA-NXX-X Holder, Bulk Data Download     3-63     3.10.5     Block Holder, Bulk Data Downloads     3-63     3.10.6     Notifications, Bulk Data Download     3-65     3.10.7     Bulk Data Download Response Files     3-66                 3.11     NPA-NXX-X Information     3-68     3.11.1     NPA-NXX-X Download Indicator Management     3-68     3.11.2     NPA-NXX-X Holder Information     3-69     3.11.3     NPA-NXX-X Holder, NPAC Scheduling/Re-Scheduling of Block Creation     3-71     3.11.4     NPA-NXX-X Holder, Addition     3-74     3.11.5     NPA-NXX-X Holder, Modification     3-76     3.11.6     NPA-NXX-X Holder, Deletion     3-77     3.11.7     NPA-NXX-X Holder, First Port Notification     3-79     3.11.8     NPA-NXX-X Holder, Query     3-80     3.11.9     NPA-NXX-X Holder, Bulk Data Download     3-80                 3.12     Block Information     3-81     3.12.1     Version Status     3-81     3.12.2     Block Holder, General     3-83     3.12.3     Block Holder, Addition     3-93     3.12.4     Block Holder, Modification     3-94     3.12.5     Block Holder, Deletion     3-96     3.12.6     Block Holder, Query     3-98     3.12.7     Block Holder, Default Routing Restoration     3-98     3.12.8     Block Holder, Re-Send     3-99     3.12.9     Block Holder, Bulk Data Downloads     3-101                 3.13     Linked Action Replies     3-101                 3.14     GTT Validation Processing by the NPAC SMS     3-105     3.14.1     Sub System Number (SSN) Edit Flag Indicator     3-105     3.14.2     Global GTT Validations     3-108       4.     SERVICE PROVIDER DATA ADMINISTRATION     4-1     4.1     Service Provider Data Administration and Management     4-1     4.1.1     User Functionality     4-1     4.1.2     System Functionality     4-2                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    iv  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      4.1.2.1     Service Provider Data Creation     4-2     4.1.2.2     Service Provider Data Modification     4-5     4.1.2.3     Delete Service Provider Data     4-6     4.1.3     Service Provider Queries     4-7     4.1.3.1     User Functionality     4-7     4.1.3.2     System Functionality     4-7     4.1.3.2.1     Service Provider Query     4-8                 4.2     Additional Requirements     4-8                 5.     SUBSCRIPTION MANAGEMENT     5-1                 5.1     Subscription Version Management     5-1     5.1.1     Subscription Version Management     5-2     5.1.1.1     Version Status     5-2     5.1.2     Subscription Administration Requirements     5-11     5.1.2.1     User Functionality     5-11     5.1.2.2     System Functionality     5-12     5.1.2.2.1     Subscription Version Creation     5-12     5.1.2.2.1.1     Subscription Version Creation — Inter-Service Provider Ports     5-12     5.1.2.2.1.2     Subscription Version Creation — Intra-Service Provider Port     5-20     5.1.2.2.2     Subscription Version Modification     5-25     5.1.2.2.2.1     Modification of a Pending or Conflict Subscription Version     5-25     5.1.2.2.2.2     Modification of an Active/Disconnect Pending Subscription Version     5-28     5.1.2.2.3     Subscription Version Conflict     5-33     5.1.2.2.3.1     Placing a Subscription Version in Conflict     5-33     5.1.2.2.3.2     Removing a Subscription Version from Conflict     5-35     5.1.2.2.4     Subscription Version Activation     5-37     5.1.2.2.5     Subscription Version Disconnect     5-41     5.1.2.2.6     Subscription Version Cancellation     5-47     5.1.2.2.6.1     Un-do a “Cancel-Pending” Subscription     5-52     5.1.2.2.7     Subscription Version Resend     5-53     5.1.3     Subscription Queries     5-57     5.1.3.1     User Functionality     5-57     5.1.3.2     System Functionality     5-57     5.1.4     Subscription Version Processing for National Number Pooling     5-63     5.1.4.1     Subscription Version, General     5-64     5.1.4.2     Subscription Version, Addition for Number Pooling     5-65     5.1.4.3     Subscription Version, Block Create Validation of Subscription Versions     5-66     5.1.4.4     Subscription Version, Modification for Number Pooling     5-68     5.1.4.5     Subscription Version, Deletion for Number Pooling     5-68     5.1.4.6     Subscription Version, Block Delete Validation of Subscription Versions     5-69                 6.     NPAC SMS INTERFACES     6-1                 6.1     SOA to NPAC SMS Interface     6-1                 6.2     NPAC SMS to Local SMS Interface     6-1                 6.3     Interface Transactions     6-1                 6.4     Interface and Protocol Requirements     6-1                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    v  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      6.4.1     Protocol Requirements     6-2     6.4.2     Interface Performance Requirements     6-2     6.4.3     Interface Specification Requirements     6-4     6.4.4     Request Restraints     6-4     6.4.5     Application Level Errors     6-5                 6.5     NPAC SOA Low-tech Interface     6-7                 6.6     CMIP Request Retry Requirements     6-9                 6.7     Recovery –     6-10     6.7.1     Notification Recovery     6-12     6.7.2     Network Data Recovery     6-15     6.7.3     Subscription Data Recovery     6-18     6.7.4     Service Provider Recovery     6-24                 6.8     Out-Bound Flow Control     6-25                 6.9     Roll-Up Activity and Abort Behavior     6-26                 6.10     NPAC Monitoring of SOA and LSMS Associations     6-27                 6.11     Separate SOA Channel for Notifications     6-29                 6.12     Maintenance Window Timer Behavior     6-30                 7.     SECURITY     7-1                 7.1     Overview     7-1                 7.2     Identification     7-1                 7.3     Authentication     7-3     7.3.1     Password Requirements     7-3                 7.4     Access Control     7-5     7.4.1     System Access     7-5     7.4.2     Resource Access     7-8                 7.5     Data and System Integrity     7-9                 7.6     Audit     7-11     7.6.1     Audit Log Generation     7-11     7.6.2     Reporting and Intrusion Detection     7-12                 7.7     Continuity of Service     7-14                 7.8     Software Vendor     7-15                 7.9     OSI Security Environment     7-15     7.9.1     Threats     7-15     7.9.2     Security Services     7-15     7.9.3     Security Mechanisms     7-16                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    vi  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      7.9.3.1     Encryption     7-16     7.9.3.2     Authentication     7-17     7.9.3.3     Data Origin Authentication     7-17     7.9.3.4     Integrity and Non-repudiation     7-18     7.9.3.5     Access Control     7-18     7.9.3.6     Audit Trail     7-19     7.9.3.7     Key Exchange     7-19                 8.     AUDIT ADMINISTRATION     8-1                 8.1     Overview     8-1                 8.2     Service Provider User Functionality     8-1                 8.3     NPAC User Functionality     8-2                 8.4     System Functionality     8-3                 8.5     Audit Report Management     8-5                 8.6     Additional Requirements     8-6                 8.7     Database Integrity Sampling     8-6                 8.8     Audit Processing in a Number Pool Environment     8-7                 9.     REPORTS     9-1                             9.1     Overview     9-1                 9.2     User Functionality     9-1                 9.3     System Functionality     9-3     9.3.1     National Number Pooling Reports     9-4     9.3.2     Cause Code Reports     9-6     9.3.3     Resend Excluded Service Provider Report     9-7                 10.     PERFORMANCE AND RELIABILITY     10-11                 10.1     Availability and Reliability     10-11                 10.2     Capacity and Performance     10-14                 10.3     Requirements in RFP Not Given a Unique ID     10-14                 11.     BILLING     11-1                 11.1     User Functionality     11-1                 11.2     System Functionality     11-1                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    vii  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Table of Contents                      Appendix A. BUSINESS PROCESS FLOWS     A-1                 Appendix B. GLOSSARY     B-1                 Appendix C. SYSTEM TUNABLES     C-1                 Appendix D. ENCRYPTION KEY EXCHANGE     D-1                 Appendix E. DOWNLOAD FILE EXAMPLES     E-1                 Appendix F. Midwest Region Number Pooling (deleted)     F-1                 Appendix G. Deleted Requirements     G-1                 Appendix H. Release Migration     H-1                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    viii  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             List of Figures    List of Figures                    Figure 3-1 — Entity Relationship Model                       Figure 3-2 — Number Pool Block Version Status Interaction Diagram     3-81                 Figure 5-1 — Subscription Version Status Interaction Diagram     5-2                 Figure A- 1 — NPAC Business Process Flows Legend     A-1                 Figure A- 2 — NPAC SMS Provision Service Process     A-1                 Figure A- 3 — Flow 2.1.2 NPAC SMS Subscription Version Creation Process     A-1                 Figure A- 4 — Flow 2.1.4 NPAC SMS Activate and Data Download Process     A-1                 Figure A- 5 — Flow 2.2 NPAC SMS Disconnect Process     A-1                 Figure A- 6 — Flow 2.3 NPAC SMS Repair Process     A-2                 Figure A- 7 — Flow 2.4.1 Conflict Process     A-2                 Figure A- 8 — Flow 2.5 NPAC SMS Disaster Recovery Process     A-2                 Figure A- 9 — Flow 2.6 Cancellation Process     A-2                 Figure A- 10 — Flow 2.7 Audit Process     A-2                 Figure A- 11 — Flow 2.8 Report Process     A-2                 Figure E- 1 — Subscription Download File Example     E-2                 Figure E- 2 — Network Service Provider Download File Example, SP Supports SP Type     E-4                 Figure E- 2a — Network Service Provider Download File Example, SP Does Not Support SP Type     E-4                 Figure E- 5 — Network NPA-NXX-X Download File Example     E-9                 Figure E- 6 — Block Download File Example     E-10                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    ix  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             List of Tables    List of Tables                    Table 0-1 Notation Key     0-6     Table 0-2 Language Key     0-6     Table 1-1 Business Day/Hour Behavior     1-5     Table 1-2 Timer Type Behaviour     1-6     Table 1-3 Vacant Number Treatment/Snapback Notification     1-12     Table 3-1 Data Type Legend     3-2     Table 3-2 NPAC Customer Data Model     3-9     Table 3-3 NPAC Customer Contact Data Model     3-10     Table 3-4 NPAC Customer Network Address Data Model     3-10     Table 3-5 NPAC Customer Associated Service Provider Data Model     3-11     Table 3-6 Subscription Version Data Model     3-15     Table 3-7 Subscription Version Failed SP List Data Model     3-16     Table 3-8 Number Pooling Block Holder Information Data Model     3-18     Table 3-9 Number Pooling Block Failed SP List Data Model     3-19     Table 3-10 Portable NPA-NXX Data Model     3-19     Table 3-11 LRN Data Model     3-20     Table 3-12 LSMS Filtered NPA-NXX Data Model     3-20     Table 3-13 Number Pooling NPA-NXX-X Holder Information Data Model     3-21     Table 3-14 Number Pool Block Version Status Interaction Descriptions     3-83     Table 5-1 Subscription Version Status Interaction Descriptions     5-8     Table 6-1 Interface Protocol Stack     6-2     Requirement Table 3-1, RR3-137.2 — Block Creation     3-87     Requirement Table 3-2, RR3-137.3 — Block Modification     3-88     Requirement Table 3-3, RR3-137.4 — Block Deletion     3-89     Requirement Table 3-4, RR3-138.2 – Failed SP List     3-91     Table C- 1 — Subscription Tunables     C-6     Table C- 2 — Communications Tunables     C-12     Table C- 3 — Audit Tunables     C-12     Table C- 4 — Logs Tunables     C-13     Table C- 5 — Keys Tunables     C-13     Table C- 6 — Block Tunables     C-14                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    xi  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             List of Tables                      Table D- 1 — Encryption Key Exchange File Format     D-2     Table D- 2 — Encryption Key Acknowledgement File Format     D-3     Table E- 1 — Explanation of the Fields in The Subscription Download File     E-3     Table E- 2 — Explanation of the Fields in the Network Service Provider Download File     E-4     Table E- 3 — Explanation of the Fields in the Network NPA/NXX Download File     E-6     Table E- 4 — Explanation of the Fields in the Network LRN Download File     E-8     Table E- 5 — Explanation of the Fields in the Network NPA-NXX-X Download File     E-9     Table E- 6 — Explanation of the Fields in The Block Download File     E-11                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    xii  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface    0. Preface  This section describes the organization and typographical conventions used within the document.  0.1 Document Structure  This document is organized into sections as defined below:                Preface    This section describes the document structure, conventions, and references used to develop this document.           Section 1    Introduction — This section introduces the project and describes its scope and objectives, constraints, associated assumptions, and related references.           Section 2    Business Process Flows — This section provides the high level processing flows for the NPAC SMS.           Section 3    NPAC Data Administration — This section provides the high level functional requirements related to the NPAC SMS data relationships.           Section 4    Service Provider Data Administration — This section contains the functional requirements for managing service provider information on the NPAC SMS.           Section 5    Subscription Administration — This section contains the functional requirements associated with managing service provider subscriptions for ported numbers on the NPAC SMS.           Section 6    NPAC SMS Interfaces — This section contains the functional requirements associated with the NPAC SMS external interfaces.           Section 7    Security — This section contains the functional requirements for the NPAC SMS system security.           Section 8    Audit Administration — This section contains the functional requirements for NPAC SMS audit administration.           Section 9    Reports — This section contains the functional requirements for NPAC SMS reporting capabilities.           Section 10    Performance and Reliability — This section contains the functional requirements for NPAC SMS system performance and reliability.           Section 11    Billing — This section contains the functional requirements for NPAC SMS usage recording for usage billing.                    Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-0  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface                  Appendix A    This section contains the flow diagrams depicting the NPAC SMS process flows.           Appendix B    Glossary — This section provides a description of all acronyms and terms used in this document.           Appendix C    System Tunables — This section provides a list of all system tunables and their default values.           Appendix D    Encryption Key Exchange – This section provides information on exchange of keys between Service Providers and the NPAC SMS.           Appendix E    Download File Examples – This section provides descriptions of the NPAC SMS data download files.           Appendix F    Midwest Region Number Pooling – This section is deleted in release 3.0.0.           Appendix G    Deleted Requirements – This section provides a list of requirements that have been deleted from the FRS.           Appendix H    Release Migration – This section provides requirements for the data migration of the NPAC SMS from Release 2.0 to 3.0.       0.2 Document Numbering Strategy  Starting with Release 2.0 the documentation number of the FRS document will be Version X.Y.Z as follows:  X – will only be incremented when a new major release of the NPAC SMS system is authorized. It will contain only the Change Orders that have been authorized for inclusion in this new major release. Y – Will only be incremented when a new sub-release of an existing release X is authorized. It will contain only the Change Orders that have been authorized for inclusion in this new sub-release. Z – will be incremented when documentation only clarifications and/or backward compatibility issues or other deficiency corrections are made in the FRS and/or IIS. This number will be reset to 0 when Y is incremented. For example, the first release of the Release 2 FRS will be numbered 2.0.0. If documentation only clarifications are introduced in the next release of the FRS document it will be numbered 2.0.1. If requirements are added to Release 2.0 that require NPAC SMS software changes then the next release of the FRS document will be numbered 2.1.0.  This number scheme is intended to make the mapping between NPAC SMS and the FRS and IIS documentation consistent.  Starting with Release 3.2, the documentation number of the FRS document will include a “lowercase letter” following the Z designation. This “lowercase letter” will essentially serve as a version indicator for the release of the documentation, such that the X.Y.Za will be a unique identifier. It will be used for both drafts and final versions.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-1  North American Numbering Council (NANC)      Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface    For example, the first release using this new convention will be 3.2.0a, followed by 3.2.0b, and so on. The “lower case letter” shall be reset to ‘a’ when Z is incremented.    0.3 Document Version History  0.3.1 Release 1.0  NANC Version 1.0, released on 04/07/97, contains changes from the ICC Subcommittee FRS Version 1.1.5.  NANC Version 1.1, released on 05/08/97, contains changes from the NANC FRS Version 1.0.  NANC Version 1.2, released on 05/25/97, contains changes from the NANC FRS Version 1.1.  NANC Version 1.3, released on 07/09/97, contains changes from the NANC FRS Version 1.2.  NANC Version 1.4, released on 08/08/97, contains changes from the NANC FRS Version 1.3.  NANC Version 1.5, released on 09/09/97, contains changes from the NANC FRS Version 1.4.  NANC Version 1.6, released on 11/12/97, contains changes from the NANC FRS Version 1.5.  NANC Version 1.7, released on 12/12/97, contains changes from the NANC FRS Version 1.6.  NANC Version 1.8, released on 2/11/98, contains changes from the NANC FRS Version 1.7.  NANC Version 1.9, released on 5/13/98, contains changes from the NANC FRS Version 1.8.  NANC Version 1.10, released on 7/8/98, contains changes from the NANC FRS Version 1.9.  0.3.2 Release 2.0  NANC Version 2.0.0, released on 12/1/98, contains changes from the NANC FRS Version 1.10.  NANC Version 2.0.1, released on 5/1/99, contains changes from the NANC FRS Version 2.0.0.  NANC Version 2.0.2, released on 9/1/99, contains changes from the NANC FRS Version 2.0.1.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-2  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface            0.3.3   Release 3.0    NANC Version 3.0.0, released on 1/5/00 and 2/4/00 (revised version), contains changes from the NANC FRS Version 2.0.2.  NANC Version 3.0.1, released on 6/6/00, contains changes from the NANC FRS Version 3.0.0  NANC Version 3.0.2, released on 3/1/01, contains changes from the NANC FRS Version 3.0.1  NANC Version 3.0.3, released on 3/19/01, contains changes from the NANC FRS Version 3.0.2          0.3.4   Release 3.1`    NANC Version 3.1, released on 8/6/01, contains changes from the NANC FRS Version 3.0.3.          0.3.5   Release 3.2    NANC Version 3.2.0, released on 7/19/02, contains changes from the NANC FRS Version 3.1.0.  NANC Version 3.2.1a, released on 6/27/03 contains changes from the NANC FRS Version 3.2.0.  NANC Version 3.2.2a, released on 6/30/04 contains the changes from the NANC FRS Version 3.2.1a          0.3.6   Release 3.3    NANC Version 3.3.0a, released on 3/28/05, contains changes from the NANC Version 3.2.2a  NANC Version 3.3.0b, released on 4/22/05 contains changes from the NANC FRS Version 3.3.0a  NANC Version 3.3.0c, released on 5/12/05 contains changes from the NANC FRS Version 3.3.0b  NANC Version 3.3.0d, released on 6/22/05 contains changes from the NANC FRS Version 3.3.0c  NANC Version 3.3.0e, released on 8/2/05 contains changes from the NANC FRS Version 3.3.0d  NANC Version 3.3.1a, released on 10/14/2005 contains changes from the NANC FRS Version 3.3.0e  NANC version 3.3.1b, released on 3/7/2006 contains the following changes from the NANC FRS Version 3.3.1a:                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-3    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface         o   Documentation only changes contained in Change Order NANC 407 NPAC Range Operations and Associated Notifications        o   Documentation only changes contained in Change Order NANC 409 Doc-Only Change Order: FRS Updates    NOTE: With Release 3.3 of the NPAC SMS, new functionality related to SV Type and Optional Data for a subscription version or number pool block, is implemented but is currently inactive in all NPAC Regions. To implement these features new requirements were drafted and existing requirements were impacted. Both new and existing requirements for these features reference change order, “NANC 399”. Until NAPM LLC approval, this functionality will remain inactive in the NPAC SMS system.    0.4 Abbreviations and Notations  To uniquely identify requirements, this document follows a naming convention where the first character is always a letter denoting whether the item is an assumption (A), a constraint (C) or a requirement (R).  In order to identify all NPAC SMS functional requirements this document incorporates information from three sources: the Illinois NPAC SMS RFP, Lockheed Martin’s (NeuStar, Inc. as of December 1999) response to the RFP and requirements definition activities performed with the Illinois Number Portability SMS Subcommittee.  Illinois number of requirements has been adopted for the initial release of the NANC document. In Illinois as requirements were deleted the requirement number and an indication of its deletion were left in the document for tracking purposes. NANC has chosen to leave these deleted requirements in this document for the initial release of the document. Further explanation of the numbering scheme follows.  If the second character is the letter “N”, the item is a requirement, assumption or a constraint that was stated in the narrative portion of the RFP and not assigned a number. The number following this character identifies the item’s section in the RFP/requirements document.  If the second character is the letter “X”, the item is a requirement, assumption or a constraint that was added upon award, and not in the RFP. These items represent clarifications or enhancements to the RFP. The number following this character identifies the item’s section in the RFP/requirements document.  If the second character is the letter “R”, the item is a requirement, assumption or a constraint that was identified during requirements analysis and verification activities subsequent to award. These items represent clarifications or enhancements to the RFP. The number following this character identifies the item’s section in the RFP/requirements document.  The following labels are used to identify assumptions, constraints, and requirements within the document. Each label begins with the letter A, C, or R followed either by a number or letter illustrated below:                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-4    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface                  A-<nnn>    Is a label for each assumption in the document. Assumptions are conditions that are expected to be true during the design and implementation phases of the project. This is an assumption that was a numbered assumption in the RFP.           AN-<nnn>    This is an assumption that was contained in the narrative text in the RFP.           AP-<nnn>    This is an assumption that was added upon award.           AR-<nnn>    This is an assumption that was identified as a new assumption for the system, during post-award meetings with the Illinois LCC.           C-<nnn>    Is a label for each constraint within the document. Constraints are conditions that restrict the design and implementation scope of the project. This is a constraint that was a numbered constraint in the RFP.           CN-<nnn>    This is a constraint that was contained in the narrative text in the RFP.           CP-<nnn>    This is a constraint that was added upon award.           CR-<nnn>    This is a constraint that was identified as a new constraint for the system, during post-award meetings with the Illinois LCC.           R-<nnn>    Is a label for each requirement in the document. Requirements define the functionality expected of the design and implementation. This is a requirement that was a numbered requirement in the RFP.           RN-<nnn>    This is a requirement that was contained in the narrative text in the RFP.           RR-<nnn>    This is a requirement that was identified in a NPAC SMS release subsequent to 1.X.                    Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-5    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Preface                  RX-<nnn>    This is a requirement that was added upon award.           RR-<nnn>    This is a requirement that was identified as a new requirement for the system, during post-award meetings with the Illinois LCC.     Table 0-1 Notation Key    0.5 Document Language  Specific language is used in the document to denote whether a statement is informative or required. The following words have these connotations when used to describe actions or items:                shall    The use of the term “shall” in this document is intended to precede a required statement. Compliance with “shall” must be demonstrated during design review and system acceptance testing.           is,will,    Use of the terms “is,” “will,” or “should” in this document is intended to identify guidance or preference. Statements annotated in this manner are to be treated as informative or preference, but not required.     should    Statements following the words “is,” “will,” or “should” are not a mandatory deliverable for the final system.            Table 0-2 Language Key                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    0-6    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction    1. Introduction  This document defines the functional requirements of the Number Portability Administration Center Service Management System (NPAC SMS) enabling Service Provider Portability.  This introduction gives readers a brief overview of NPAC SMS functionality. It is intended to prepare you for the detailed sections that follow. If you need more information on any particular area, please consult the applicable detailed sections in the remainder of this document or the NPAC SMS Interoperable Interface Specification.  This introduction is also meant to convey the basic course of events that give the best understanding of the system. Alternate courses of events (variants of the basic course or error paths) are described in the detailed sections later in this document and in the NPAC SMS Interoperable Interface Specification.    1.1 NPAC SMS Platform Overview  The Number Portability Administration Center Service Management System (NPAC SMS) is a hardware and software platform, which contains the database of information required to effect the porting of telephone numbers. In general, the NPAC SMS can receive customer information from both the old and new Service Providers (including the new Location Routing Number), validates the information received, and downloads the new routing information when an “activate” message is received indicating that the customer has been physically connected to the new Service Provider’s network. The NPAC SMS also contains a record of all ported numbers and a history file of all transactions relating to the porting of a number. The NPAC SMS shall also provide audit functionality and the ability to transmit LNP routing information to Service Providers to maintain synchronization of Service Provider’s network elements that support LNP.    1.2 NPAC SMS Functional Overview          1.2.1   Provisioning Service Functionality    The new Service Provider will obtain authorization to port the customer and notify the old Service Provider according to processes internal to the Service Providers. Both the old and new Service Providers can send a notification to the NPAC SMS from their Service Order Administration Systems (SOA). When the NPAC SMS receives the notification(s), it will perform certain validation checks, and attempt to match the notification received from the new Service Provider with a concurring notification that may be sent from the old Service Provider. Assuming the notifications are valid, the two Service Providers will complete any physical changes required. When the new Service Provider due date is reached, the new Service Provider can send an activation notice to the NPAC SMS. The NPAC SMS will broadcast the update out in real time to each local SMS. Upon receiving the update from the NPAC SMS, all Service Providers will update their networks. The NPAC SMS will record any transmission failures and take the appropriate action.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-1    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction    In the case where either the old or new Service Providers did not send a notification to the NPAC SMS, the NPAC SMS will notify the Service Provider from which it did not receive a notification that it is expecting a notification. If it then receives the missing notification and the notifications indicate agreement among the Service Providers, the process proceeds as normal. If it still does not receive a notification and if it is the old Service Provider that failed to respond, the NPAC SMS will log the failure to respond and allow the new Service Provider to proceed with activation when the new Service Provider due date is reached. If it was the new Service Provider that failed to respond, the NPAC will log the failure to respond, cancel the request, and notify both Service Providers of the cancellation. If there is disagreement among the Service Providers as to who will be providing service for the telephone number, the conflict resolution procedures will be implemented (see Section 1.2.4). Processes for obtaining authorization from the customer to port a number are defined by the Service Providers. The NPAC is not involved in obtaining or verifying customer approval to port a TN.          1.2.2   Disconnect Service Functionality    When a ported number is being disconnected, the customer and Service Provider will agree on a date. The current Service Provider will send an update indicating the disconnect to the NPAC SMS. If the Service Provider needs to change the Customer Disconnect Date (CDD) or Effective Release Date (ERD) of the disconnect, the Service Provider will send a modify request to the NPAC SMS. The NPAC SMS will broadcast the update to all Service Providers based on the disconnect effective date and remove the telephone number from its database of ported numbers. Upon receiving the update, all Service Providers will remove the telephone number from their LNP databases. The NPAC SMS will log the update in history. Calls to the telephone number will be routed as a non-ported number.          1.2.3   Repair Service Functionality    A problem will be detected either by a Service Provider or by a customer contacting a Service Provider.  There will be audit capabilities in the NPAC SMS to aid in isolating problems. If an inaccuracy is found, the NPAC SMS will supply the correct data to any local SMS requesting updates.          1.2.4   Conflict Resolution Functionality    If Service Providers disagree on who will serve a particular line number, the NPAC SMS will place the request in the “conflict” state and notify both Service Providers of the conflict status and the Status Change Cause Code. The Service Providers will determine who will serve the customer via internal processes. When a resolution is reached, the NPAC will be notified and will remove the request from the “conflict” state by one of the two Service Providers. The new Service Provider can cancel the Subscription Version.          1.2.5   Disaster Recovery and Backup Functionality    If there is unplanned downtime, the NPAC will assess how long the primary machine will be down. The NPAC will notify all of the Service Providers of the situation and planned action by electronic notification and telephone calls to the Service Providers’ contact numbers. The Service Providers will attempt to switch to the backup NPAC.                Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-2    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction            1.2.6   Order Cancellation Functionality    If a Create Subscription has been sent by only the new Service Provider, the new Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If a Create Subscription has been sent by only the old Service Provider, the old Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If both Service Providers have sent a Create Subscription, either may send a message to the NPAC SMS to cancel the Subscription Version. If both Service Providers concur with the cancellation, the NPAC SMS will set the Subscription Version to canceled and notify both Service Providers that the Subscription Version has been canceled. If cancellation concurrence is not provided by the new Service Provider the Subscription Version is placed in conflict by the NPAC SMS. If cancellation concurrence is not provided by the old Service Provider, the Subscription Version is set to cancel by the NPAC SMS.          1.2.7   Audit Request Functionality    An audit function will be necessary for troubleshooting customer problems and also as a maintenance process to ensure Subscription Version data integrity across the entire LNP network. Audits will be concerned with the process of comparing the NPAC SMS view of the LNP network’s Subscription Version data with one or more of the Service Provider’s views of its network. In the case of “on demand” audits, audits may be initiated by any Service Provider who has reason to believe a problem may exist in another Service Provider’s network. These audits are executed via queries to the appropriate Service Provider’s network, and corrected via downloads to those same networks.  In addition, Local Service Providers will be responsible for comparing database extracts of Subscription data written to an FTP site by the NPAC SMS with their own versions of the same Subscription data.  In a third scenario, the NPAC SMS will select a random sample of active Subscription Versions from its own database, then compare those samples to the representation of that same data in the various Local SMS databases. All three of the methods outlined above are designed to help ensure data integrity across the LNP network.          1.2.8   Report Request Functionality    The NPAC SMS supports report generation for pre-defined and ad-hoc reports. The report generation function creates output report files according to specified format definitions, and distributes reports to output devices as requested. The report distribution service supports distribution to electronic files local/remote printers, e-mail and FAX machines.          1.2.9   Data Management Functionality    The NPAC SMS will support functionality to manage network, Service Provider, and Subscription Version data.          1.2.9.1   NPAC Network Data    The NPAC SMS contains data, which defines the configuration of the LNP service and network. This includes such data as: participating Service Providers, NPA-NXXs that are portable, and LRNs associated with each Service Provider.                Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-3    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction            1.2.9.2   Service Provider Data    The Service Provider data indicates who the LNP Service Providers are and includes location, contact name, security, routing, and network interface information.          1.2.9.3   Subscription Version Data    The subscription data indicates how local number portability should operate to meet subscribers’ needs.          1.2.10   NPA-NXX Split Processing    NPA Splits are initiated on the NPAC through regular processing of an industry source that contain industry standard data. Based on information from these files, the NPAC SMS will automatically perform all the data processing necessary (Creating/Deleting NPA-NXXs, updating Subscription Versions appropriately) to ensure reliable representation of ported telephone number data used in call processing leading up to, during and after an NPA Split has occurred.  In the case of emergency updates to NPA Split information, certain NPAC Operations personnel have the ability to manually enter all required NPA Split information into the NPAC Administrative Interface so as to ensure successful NPA Split processing within the NPAC SMS.  For an impending NPA split, there is no communication between each SOA and the NPAC via an electronic interface (SOA, LSMS, or NPAC Administrative Interface) other than providing the NPAC with the new network data (LRNs), if applicable. The NPAC will update its subscription version records when permissive dialing starts to the new NPA. During the permissive dialing period the NPAC will accept messages with either old or new NPA but broadcasts/downloads with the new NPA only. In addition, all notifications and responses to the SOA system will contain the new NPA only during the permissive dialing period regardless of whether the SOA system is using the old or new NPA in its requests to the NPAC SMS. If a delete request is received, it is broadcast with the new NPA. The subscription version ID that the NPAC SMS is aware of for the TN is used in the messages.  Based on information from the industry source, the service providers will update their networks/LSMS to accommodate the permissive dialing period and will update the data in their networks/LSMS after permissive dialing ends. There is no communication from the NPAC to cause these updates to occur. No assumptions are made about what the LSMS does during the permissive period to track the NPA-NXX split for a subscription version.  After permissive dialing ends, the NPAC removes any old NPA-NXXs and/or NPA-NXX-Xs related to the NPA Split that are no longer valid, and broadcasts these network data deletes to the appropriate SOAs/LSMSs. Additionally, the service providers can remove any old LRNs that are no longer valid due to the split, if any, via an electronic interface (SOA, LSMS, or NPAC Administrative Interface).                Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-4    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction            1.2.11   Business Days/Hours    For support of service providers that have different needs for business hours and days available for porting, two types of business days/hours have been defined in the NPAC SMS. The two types are long and short business days/hours.  The following table illustrates the outcome of business hours/days to be used based on the possible combinations:                                     OLD Service Provider   New   Business   Short   Long   Service   Type           Provider                                      Short    When both the old and new service providers support short business days/hours for a subscription version port short business days/hours will be used.    When the new service provider supports short business days/hours and the old service providers supports long business days/hours for a subscription version port short business days/hours will be used.                            No action is necessary by either the old or new service provider operations personnel.    The old service provider who supports the long business days/hours will have to recognize that the short business days/hours are being used instead of the expected long business days/hours.                        Long    When the new service provider supports long business days/hours and the old service providers supports short business days/hours for a subscription version port short business days/hours will be used.    When both the old and new service providers support long timers for a subscription version port long timers will be used.                No action is necessary by either the old or new service provider operations personnel.                            The new service provider who supports the long business days/hours will have to recognize that the short timers are being used instead of the expected long timers.         Table 1-1 Business Day/Hour Behavior                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-5    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction            1.2.12   Timer Types    For support of service providers that have different needs for timers available for porting, two types of timers have been defined in the NPAC SMS. The two types are long and short timers.  The following table illustrates the outcome of timers to be used based on the possible combinations:                          OLD Service Provider   New   Timer Type   Port Out-  Short   Port Out-  Long   Service               Provider                      Port In – Short    When both the old and new service providers support short timers for a subscription version port short timers will be used.    When the new service provider supports short timers and the old service providers supports long timers for a subscription version port long timers will be used.                            No action is necessary by either the old or new service provider operations personnel.    The new service provider who supports the short timers will have to recognize that the long timers are being used instead of the expected short timers.                        Port In – Long    When the new service provider supports long timers and the old service providers supports short timers for a subscription version port long timers will be used.    When both the old and new service providers support long timers for a subscription version port long timers will be used.                            The old service provider who supports the short timers will have to recognize that the long timers are being used instead of the expected short timers.    No action is necessary by either the old or new service provider operations personnel.     Table 1-2 Timer Type Behaviour          1.2.13   Recovery Functionality    The NPAC SMS provides a mechanism that allows a Service Provider to recover messages sent to either the SOA or LSMS, during a period of time that the Service Provider was not available to receive messages from the NPAC SMS. This recovery mechanism (also referred to as resynchronization) is initiated when a Service Provider’s SOA or LSMS re-associates to the NPAC SMS, by setting the recovery mode indicator to TRUE on the Access Control structure, then requests the recovery of missed messages, by requesting the missed Network Data, Subscription Versions and/or Notifications.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-6    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction    The SOA requests network data and notification data for a specific period of time from the NPAC SMS, which is sent by the NPAC SMS as requested. The NPAC SMS will send the recovery data requested based on the Service Provider’s Linked Replies Indicator setting (separate indicators for SOA and LSMS). If the Linked Replies Indicator is set to TRUE the NPAC SMS will send the updates in smaller, linked messages (e.g., groups of 50 at a time). If the Linked Replies Indicator is set to FALSE the NPAC SMS will send the updates in a single larger, non-linked message. In the case of linked replies, data is sent in multiple linked M-ACTION replies, followed by an “empty” non-linked normal response (indicating the end of the linked reply data). During the recovery process, new messages are queued on the NPAC SMS. Additionally, during the recovery process, the “x by y” retry functionality (where “x” is the number of attempts, and “y” is the interval in number of minutes in between attempts) continues on the NPAC SMS, but message sending is suspended to the SOA, and the retry attempts counter is not decremented, as long as the SOA is still in recovery mode. Once the recovery is finished, the SOA sends a recovery complete message to the NPAC SMS, which in turn triggers the NPAC SMS to send the previously queued messages to the SOA, at the next normally scheduled retry interval. At the completion of sending the previously queued messages, the interaction between the SOA and the NPAC SMS resumes for normal message processing.  The LSMS recovery functionality works similar to the SOA, with the addition of recovering subscription data.  Service Provider systems may implement an optional recovery method called, “Send What I Missed” (SWIM). This implementation uses the existing recovery messages, and incorporates a new attribute (SWIM, rather than a time range). When the NPAC SMS receives a SWIM recovery request it issues a SWIM recovery response that contains only the messages that were previously missed by the requesting Service Provider system. Linked Reply functionality is utilized in the SWIM responses, so a Service Provider system must support that feature as well. SWIM improves the efficiency of recovery processing for the NPAC SMS and Service Providers because guesswork of determining a recovery timeframe that includes the actual messages that were missed is eliminated.          1.2.13.1   Network Data Recovery    Network Data Recovery in the NPAC SMS allows a Service Provider for both SOA and LSMS to capture, via a recovery process, all network data downloads that were missed during a downtime period for the Service Provider. The processing steps for this functionality include:     1.   The Service Provider system sends a network data recovery request to the NPAC.      2.   The NPAC takes the time range in the requested criteria, and compares the number to the current tunable value.      3.   If the time range exceeds the tunable value, a DownloadReply is returned to the SP system with the status field populated with value 2, signifying “time-range-invalid”. No network data will be included with this reply.      4.   When an SP system sees this response, the suggested behavior is to reduce the time range requested in the network data recovery action and re-issue the request.            NOTE:   Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system or a record-based recovery request to recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.            1.2.13.2   Subscription Data Recovery    Subscription Data Recovery in the NPAC SMS allows a Service Provider’s LSMS to capture, via a recovery process, all subscription data downloads that were missed during a downtime period for the Service Provider. The processing steps for this functionality include:     1.   The Service Provider system sends a subscription data recovery request to the NPAC.      2.   The NPAC takes the time range in the requested criteria, and compares the number to the current tunable value.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-7    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction       3.   If the time range exceeds the tunable value, a DownloadReply is returned to the SP system with the status field populated with value 2, signifying “time-range-invalid”. No subscription data will be included with this reply.      4.   When an SP system sees this response, the suggested behavior is to reduce the time range requested in the subscription data recovery action and re-issue the request.            NOTE:   Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system or a record-based recovery request to recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.            1.2.13.3   Notification Recovery    Notification Recovery in the NPAC SMS allows a Service Provider for both SOA and LSMS to capture, via a recovery process, all notifications that were missed during a downtime period for the Service Provider. The processing steps for this functionality include:     1.   The Service Provider system sends a notification recovery request to the NPAC.      2.   The NPAC retrieves the records that match the requested criteria, and compares the number to the current tunable value.      3.   If the number of records exceeds the tunable value, a NetworkNotificationRecoveryReply is returned to the SP system with the status field populated with value 3, signifying “criteria-too-large”. No notifications will be included with this reply.      4.   When an SP system sees this response, the suggested behavior is to reduce the time range requested in the notification recovery action and re-issue the request.            NOTE:   Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system. This type of recovery request does not require a time range.            1.2.13.4   Service Provider Data Recovery    Service Provider Data Recovery in the NPAC SMS allows a Service Provider for both SOA and LSMS to capture, via a recovery process, all Service Provider data updates that were missed during a downtime period. The processing steps for this functionality include:     1.   The Service Provider system sends a service provider data recovery request to the NPAC.      2.   The NPAC takes the time range in the request criteria, and compares the number to the current tunable value.      3.   If the time range exceeds the tunable value, a DownloadReply is returned to the SP system with the status field populated with value 2, signifying “time-range-invalid”. No service provider data will be included with this reply.      4.   When an SP system sees this response, the suggested behavior is to reduce the time range requested in the service provider data recovery action and re-issue the request.            NOTE:   Alternatively, a Service Provider system may issue a SWIM recovery request and recover only the messages that were previously missed by the Service Provider system or a record-based recovery request to recover a range of data missed during a downtime period. These types of recovery requests do not require a time range.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-8    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction            1.2.14   Number Pooling Overview    At the present time, the National Number Pooling approach includes the following:     1.   Pre-Port 1K Blocks to a single switch (i.e., all Pooled TNs contain same LRN).      2.   EDR (Efficient Data Representation) is captured through the use of “1K Blocks” in the NPAC, and over the SOA-to-NPAC and NPAC-to-LSMS interfaces.      3.   The NPA-NXX-X Holder Information in the NPAC is a representation of the 1K Block managed by the Pooling Administrator, and represented in the LERG Routing Guide.      4.   The NPAC Customer SOA NPA-NXX-X Indicator in the NPAC Customer Data Model will be added to indicate whether or not the Service Provider accepts NPA-NXX-X downloads from the NPAC (TRUE = yes, FALSE = no) to their SOA via the SOA-to-NPAC SMS Interface.      5.   The NPAC Customer LSMS NPA-NXX-X Indicator in the NPAC Customer Data Model will be added to indicate whether or not the Service Provider accepts NPA-NXX-X downloads from the NPAC (TRUE = yes, FALSE = no) to their LSMS via the NPAC SMS-to-Local SMS Interface.      6.   The NPAC Customer Data Model (logical) and Service Provider Profile (physical) refer to the same information.      7.   The NPA-NXX-X Holder Information is broadcast over the SOA-to-NPAC SMS Interface to all Service Providers in that NPAC region (exclusive of those that have filters for that NPA-NXX, and those who have a SOA NPA-NXX-X indicator in the Customer Data Model set to FALSE), for the block allocation of NPA-NXX-X data to the NPA-NXX-X Holder.      8.   The NPA-NXX-X Holder Information is broadcast over the NPAC SMS-to-Local SMS Interface to all Service Providers in that NPAC region (exclusive of those that have filters for the NPA-NXX, and those who have an LSMS NPA-NXX-X indicator in the Customer Data Model set to FALSE), for the block allocation of NPA-NXX-X data to the NPA-NXX-X Holder.      9.   The NPA-NXX-X Holder Information’s “Effective Date” is the date the LERG Routing Guide, the Pooling Administrator, and the NPAC, consider to be the “ownership switchover” date for the 1K Block from the Code Holder (NPA-NXX owning SP) to the Block Holder (NPA-NXX-X owning SP).      10.   At the time of NPA-NXX-X creation, the NPAC will check for “pending-like, no-active” SVs or “pending-like Port-To-Original” SVs. If any are found, the NPAC will reject the creation of this NPA-NXX-X. An error message will be generated for the NPAC personnel. Additionally, the NPAC Personnel will be able to view the discrepant TNs (on the screen in the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version REPORT format), then be able to select multiple output destinations for the report, or exit the NPA-NXX-X Creation and continue with other GUI activities.      11.   The Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report will be available to NPAC personnel. The report will contain TN, Old SPID, New SPID, Due Date, and Status.      12.   The recipients of the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report (e.g., Pooling Administrator, Code Holder) will have their own M&P (outside of NPAC) to clean up these SVs (either cancel or activate). Once they are cleaned up, NPAC personnel will attempt the NPA-NXX-X creation again.      13.   Once the NPA-NXX-X has been created on the NPAC, the Code Holder is prohibited from performing intra-service provider ports. If TNs were missed during the Code Holder’s pre-donation intra-port activities, then NPAC personnel only are allowed to perform these intra-service provider port creates of SVs with no previously active SV, on behalf of the Code Holder. The NPAC will allow NPAC personnel, via the OpGUI, to create these LISP ports up to the effective date (11:59p of the day prior to the effective date), and to activate these LISP ports up to the Block’s activation date/time. The Code Holder can also assist in the activation of the LISP ports up to the Block’s activation date/time.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-9    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction       14.   Once the NPA-NXX-X’s Effective Date has been reached, but prior to the Block’s activation, snapback messages will go to the Block Holder, and default routing will be the responsibility of the Code Holder. The exception to this is during the de-pool process for the NPA-NXX-X (see #31 below).      15.   Once the Block has been created (the record exists in the NPAC SMS and the Creation Timestamp in the Object has been set) in the NPAC, either from a scheduled event on the NPAC, or from a Service Provider SOA sending up the Block, then NPAC processing considers the Block to be “activated” for the Block Holder, and all snapback messages and default routing will go to the Block Holder.      16.   The Block Holder Information is broadcast over the NPAC-to-LSMS interface, when the SP’s LSMS EDR flag in the Customer Profile record in the NPAC, is set to TRUE (non-EDR LSMSs get individual SVs, since the SP’s LSMS EDR flag is set to FALSE).      17.   The Block Holder Information’s “Activation Timestamp” is the date/time the NPAC broadcasts block or SV data to the applicable LSMSs. Only at this point in time are all SPs notified of the “ownership switchover” date for the 1K Block from the Code Holder (NPA-NXX owning SP) to the Block Holder (NPA-NXX-X owning SP).      18.   Block Create messages over the SOA-to-NPAC SMS Interface will set the SOA Origination to TRUE.      19.   The Block Holder Information’s SOA notification is broadcast over the SOA to NPAC Interface, when the SOA Origination on the Block record is set to TRUE.      20.   At the time of Block creation by the NPAC (attempted on or after the NPA-NXX-X’s Effective Date), the NPAC will check for “pending-like, no-active” SVs. If any are found, the NPAC will reject the creation of this Block. A unique alarmable error message (new error message and error number for Block) will be generated and alarm NPAC personnel.      21.   At the time of Block creation by the SP’s SOA (attempted on or after the NPA-NXX-X’s Effective Date), the NPAC will check for “pending-like, no-active” SVs. If any are found, the NPAC will reject the creation of this Block. A unique alarmable error message (new error message and error number for Block, but no alarm to NPAC Personnel) will be generated and sent back to the SP’s SOA. A new M&P will require the SP to contact NPAC personnel (USA) and request the generation of the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report.      22.   The Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report will be created and will contain TN, Old SPID, New SPID, Due Date, and Status.      23.   The recipients of the Pending-Like No-Active Subscription Version and Pending-Like Port-to-Original Subscription Version report (e.g., Pooling Administrator, Code Holder) will have their own M&P (outside of NPAC) to clean up these SVs (either cancel or activate) by the Code Holder and the NPAC Personnel. Once they are cleaned up, NPAC personnel will attempt the Block creation again (if it is NPAC initiated), or contact the Block Holder SP and inform them that they could re-submit the Block request.      24.   If during the broadcast of the Pooled Data (Blocks and SVs), one or more Service Providers cause the Block to go into a Partial Failure or Failed status, the NPAC will generate a unique alarmable message, and NPAC Personnel will be notified of the error, only when the SOA Origination is FALSE (if value is TRUE, existing M&Ps for partial failure or failed conditions will be used). M&P will be established to have NPAC Personnel resolve the broadcast failures with the Service Providers on the Block’s Failed SP List.      25.   The NPAC will execute a background process, once a day, to check for Block completeness. During this background process, the NPAC will check for active blocks that haven’t been verified to contain 1000 SVs (combination of POOL, LISP, LSPP) for that Block.. This is designed to capture any “disconnect requests that were sending on it’s way to old”, which may result in an orphan TN that does NOT have an Active SV. This background process will be run for the first time within 24 hours of Block Creation (with an Active status), and once every 24 hours thereafter for incomplete Blocks. For missing TNs that are identified during this process, the NPAC will create, activate and broadcast the missing SVs to non-EDR Local SMSs (i.e., self-fixing create, activate and broadcast of missing SVs). Once all 1000 TNs have been accounted for in the NPAC, this Block will no longer be checked by the NPAC.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-10    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction       26.   The NPAC will manage the synchronization of, and maintain the integrity of, the data between a Block and the subordinate Pooled Subscription Versions within the Block. This means that, at all times, the LRN and GTT routing data for the Block and all SVs with LNP Type of POOL within the 1K Block, will contain the same values. The status for the Block and status for each SV with LNP Type of POOL within the 1K Block, may not always contain the same value. The matrix to coordinate the status is found in the detailed requirements. The failed SP List for the Block and Failed SP List for each SV with LNP Type of POOL within the 1K Block, may not always contain the same Service Providers. The matrix to coordinate the various Failed SP Lists is found in the detailed requirements.      27.   Once a Block is “active”, the routing data can be modified. This may be performed by NPAC Personnel using the NPAC OpGUI, Service Provider Personnel using the NPAC Low-tech Interface, or Service Provider via the SOA-to-NPAC SMS Interface.      28.   At the time of NPA-NXX-X deletion (i.e., de-pool), the NPAC will check for “pending-like, with Active POOL” SVs, or “pending-like, port-to-original” SVs. If any are found, the NPAC will reject the Deletion of this NPA-NXX-X. An error message will be generated for the NPAC personnel. Additionally, the NPAC Personnel will be able to view the discrepant TNs (on the screen in the Pending-Like With Active POOL Subscription Version and Pending-Like Port-To-Original REPORT format), then be able to select multiple output destinations for the report, or exit the NPA-NXX-X Deletion and continue with other GUI activities.      29.   The Pending-Like With Active POOL Subscription Version and Pending-Like Port-to-Original Subscription Version report will be available to NPAC personnel. The report will contain TN, Old SPID, New SPID, Due Date, and Status.      30.   The recipients of the Pending-Like With Active POOL Subscription Version and Pending-Like Port-to-Original Subscription Version report (e.g., Pooling Administrator, Block Holder) will have their own M&P (outside of NPAC) to clean up these SVs (either cancel or activate). Once they are cleaned up, NPAC personnel will await notification from the Pooling Administrator prior to attempting the NPA-NXX-X deletion again.      31.   The NPAC performs a “cascading delete” when processing an NPA-NXX-X Deletion. This includes sending deletes of Pooled SV data to non-EDR LSMSs, and sending deletes of Block data to EDR LSMSs. Once all LSMSs have successfully deleted the Pooled data (the status of all SVs and the Block is Old, and both Failed SP Lists are empty), the NPA-NXX-X is deleted. Similar to the NPA-NXX-X Creation, the NPA-NXX-X Deletion is broadcast to the appropriate Service Providers, based on the values in their NPA-NXX-X Indicators.      32.   During the de-pooling process, the vacant number treatment responsibility and snapback for TN re-assignment notifications have unique behavior, once the Block has migrated to a status of Old. As defined in #14 above, snapback messages will go to the Block Holder, and default routing will be the responsibility of the Code Holder, once the NPA-NXX-X’s Effective Date has been reached. However, in this de-pooling situation, both snapback messages and default routing responsibility will be the Code Holder. So, even though the NPA-NXX-X still exists, it has the same behavior as the “pre-effective date” NPA-NXX-X situation.      33.   Once the Block has been deleted in the NPAC, then NPAC processing considers the Block to be “deleted” for the Block Holder, and all snapback messages and default routing will go to the Code Holder. Additionally, the Block is now available to be allocated to another Service Provider.      34.   For NPA Split processing, at the start of the Split, the NPAC SMS will automatically create a New NPA-NXX-X to correspond to the Old NPA-NXX-X, and will reject the NPA Split request if the New NPA-NXX-X already exists at the time of the NPA Split entry. The NPAC will remove the New NPA-NXX-X and convert the Block and SVs back to the Old NPA-NXX, if the New NPA-NXX is removed from the NPA Split, prior to the end of PDP. When adding an NPA-NXX-X during an NPA Split, the NPAC will automatically add a corresponding New/Old NPA-NXX-X for an NPA-NXX involved in a Split. During PDP, the NPAC will treat Block data similar to the treatment of SV data (i.e., either the Old or New NPA-NXX can be sent to the NPAC, but the NPAC will broadcast the New NPA-NXX).      35.   The NPAC Customer LSMS EDR Indicator in the NPAC Customer Data Model will be added to indicate whether or not the Service Provider uses Efficient Data Representation on the Local SMS (TRUE = yes, FALSE = no).                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-11    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction       36.   The two new objects that will be broadcast over the interface include the NPA-NXX-X (1K Block) block allocation, and Block for EDR compatible Local SMSs that represent the 1000 TNs of POOL’ed numbers as the 1K Block.      37.   The basis for the National Number Pooling requirements was the Illinois Number Pooling NPAC Release 1.4. The Number Pooling Delta document, National Number Pooling requirements, represents the requirements for National Number Pooling functionality.    The following table portrays “vacant number treatment” responsibility and “snapback for TN re-assignment” notifications throughout each phase of number pooling, once the Block has been donated to the Pooling Administrator:                          Vacant Number   Pre effective date   post effective date           post Block    during Block de-    Treatment                    activation                     pool     Contaminated         Code holder         Code holder    Block holder       Code holder   disconnect                                       Non-contaminated       Code holder       Code holder    Block holder       Code holder                       Snapback for TN                   re-assignment                                       Contaminated       Code holder*       Block holder    Block holder       Code holder*   disconnect                                       Non-contaminated                    N/A                    N/A    Block holder                    N/A     Table 1-3 Vacant Number Treatment/Snapback Notification      * = Code Holder receives a notification but CANNOT reassign this TN.  Note: for the last column (during Block de-pool), the behavior is the same as the pre-effective date column. A block may still exist in the NPAC SMS with a status of Old. At the time of de-pooling, the Block goes back to the Pooling Administrator and is awaiting re-assignment to the next Block Holder. The NPA-NXX-X may also exist in the NPAC SMS until a Block is successfully deleted from all Local SMSs.         1.2.15   Time References in the NPAC SMS    Time references in the NPAC SMS can be confusing because multiple time zones are involved across the seven US regions, as well as the Canadian region. Additionally, the universal time zone (UTC/GMT) is also used. The descriptions below are designed to point out the various time references that are used throughout the system.  Universal Time Zone – As a general rule, the NPAC SMS application runs on the universal time zone. The following items use UTC/GMT:       1.   NPAC DB (all timestamp fields)        2.   CMIP interface messages (SOA and LSMS)        3.   NPAC timers (short and long)        4.   NPAC parameters         a.   Short Business Day Start Time        b.   Long Business Day Start Time                     Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-12    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction         c.   Conflict Restriction Window (18:00/17:00 GMT)         5.   NPA Split Permissive Dial Dates (the Time portion)        6.   NPAC reports        7.   NPAC BDD files    NPAC GUI – The NPAC GUI (both administrative GUI for USAs and LTI GUI for NPAC customers) is based on the setting for each specific user’s PC. Therefore, even though NPAC data is stored in UTC/GMT, it is converted and displayed for a user in their local time zone as defined in their PC setting.  The only exception to this rule is on the administrative GUI, for the following data. In both of these cases, the data is displayed in Central Time.       1.   NPA-NXX-X Effective Date        2.   Number Pool Block Scheduled Activation Date    Business Hours/Days – The definition of Business Hours/Days in the NPAC SMS are defined using a combination of three variables. Wireline Service Providers typically use SHORT variables, and Wireless Service Providers typically use LONG variables.                    Wireline    Short Business Days    Monday – Friday (five days)                    Short Business Day Start Time    13:00/12:00 GMT                    Short Business Day Duration    12 hours               Wireless    Long Business Days    Sunday – Saturday (seven days)                    Long Business Day Start Time   14:00/13:00 GMT (for eastern regions)                         15:00/14:00 GMT (for central regions)                        15:00/14:00 GMT (for Canadian region)                        16:00/15:00 GMT (for mountain region)                        17:00/16:00 GMT (for pacific region)                    Long Business Day Duration    12 hours     Using this information, the region equivalents are defined by the table below:                  Region   SPs using Short Hours/Days   SPs using Long Hours/Days         NE    Monday – Friday, 8a-8p ET    Sunday – Saturday, 9a-9p ET               MA    Monday – Friday, 8a-8p ET    Sunday – Saturday, 9a-9p ET               SE    Monday – Friday, 8a-8p ET    Sunday – Saturday, 9a-9p ET               MW    Monday – Friday, 7a-7p CT    Sunday – Saturday, 9a-9p CT               SW    Monday – Friday, 7a-7p CT    Sunday – Saturday, 9a-9p CT               WE    Monday – Friday, 6a-6p MT    Sunday – Saturday, 9a-9p MT               WC    Monday – Friday, 5a-5p PT    Sunday – Saturday, 9a-9p PT          CA    Monday — Friday, 7a-7p CT    Sunday — Saturday, 9a-9p CT                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-13    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction    Concurrence Windows/Timers – Various porting activities initiated by one Service Provider require some type of concurrence from a second Service Provider. This concurrence is defined as performing some activity within x number of business hours. At the time an activity occurs in the NPAC that requires the use of a window/timer, the future expiration time is calculated and stored, based on the NPAC settings in the table above, at the time of the activity. These windows/timers will then expire based on the pre-calculated date/time.  Standard Time/Daylight Time – The following NPAC tunables are adjusted twice a year for Standard/Daylight.       1.   Short Business Day Start Time        2.   Long Business Day Start Time        3.   Conflict Restriction Window    A note regarding concurrence windows/timers: As mentioned in the previous section, a timer is not a meter that “runs” only during the Business Day intervals, but rather is a calculation in GMT of the timer’s expiration date/time. When the Short or Long Business Day Start Time, or Conflict Restriction Window, is adjusted twice each year to reflect the daylight savings adjustment in local time (of the predominant time zone within each region), a timer that started just prior to the daylight savings adjustment will continue to “run” as if the adjustment had not been made. So in terms of local time, each Spring for a few days certain timers will appear to run for one hour too short and each Fall for a few days these same timers will appear to run for one hour too long.          1.2.16   SV Type and Alternative SPID in the NPAC SMS    SV Type and Alternative SPID functionality is implemented in NPAC software release 3.3 but is currently inactive in all NPAC Regions. Until NAPM LLC approval, this functionality will remain inactive in the NPAC SMS system.  With implementation of software release 3.3, the NPAC SMS will provide an SV Type indicator in each SV and Pooled Block record. This indicator will initially distinguish every TN and Pooled Block as being served by Wireline, Wireless, VoIP, or VoWIFI service. The SV Type indicator will be able to distinguish additional “types” as deemed necessary in the future by adding additional values. This information will be provisioned by the SOA and broadcast to the LSMS upon initial creation of the SV or Pooled Block and upon modification of the SV Type for those SOA and LSMS associations optioned “on” to send and receive this data.  The SV Type attribute will be populated by the SP Type, if this attribute is not supported by the Service Provider. The SV Type attribute must be provided if supported by the Service Provider.  The NPAC SMS shall provide an Alternative SPID field for each SV and Pooled Block record. This new field shall identify (if applicable) a second service provider – either a facility-based provider or reseller, acting as a non facility-based service provider associated with each TN or Pooled Block via their 4-digit SPID. The Alternative SPID must be a valid SPID defined in the NPAC SMS database. Alternative SPID is an optional attribute in a SV or Pooled Block record, even if it is supported by the Service Provider.            1.3   Background    Release 1.0                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-14    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction    An industry task force was formed in Illinois in April 1995, pursuant to the Illinois Commerce Commission (ICC) Order on Customers First Plan (Docket 94-0096 dated April 7, 1995), to develop a permanent number portability solution for Illinois. During that year, the task force made significant progress in defining and resolving the issues related to implementing number portability. All North American regions for deployment in all North American Local Number Portability Regions then used the work done by the Illinois task force to move forward with LNP implementation. A group was formed under NANC called the LNPA Working Group that oversaw implementation issues and documentation clarifications to the FRS and IIS for Release 1.0.  Midwest Region Number Pooling  To support number pooling in the Midwest Region requirements were developed and implemented. The requirements are included in Appendix F for completeness. If a service provider system is implementing Midwest Region Number Pooling then some of these requirements will supercede other requirements in this FRS document.  Release 2.0  The industry through work in the LNPA Working Group defined requirements for the next major release to be adopted by all regions. The Release 2.0 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality as well as modifications to existing functionality. The major enhancements include service bureau support and network data support for SOA systems as well as enhancements to support service providers implementing wireless portability.  Release 3.0  Through the work of the LNPA Working Group, requirements for National Number Pooling were defined for Release 3.0 of the NPAC SMS. National Number Pooling is implemented as a replacement to the Midwest Region Number Pooling solution that was implemented as Release 1.4 of the NPAC SMS. This approach includes the optional use of a new Block object over the interface, such that the NPAC SMS now supports both the 1K Block of TNs using Subscription Versions and the new Block object, to represent a 1K block of pooled numbers. This approach is further defined in section 1.2.14 Number Pooling Overview, of this document.  Release 3.1  With the deployment of NPAC Release 3.0 in the Northeast region a SOA – NPAC Interface problem surfaced. The improved performance of NPAC Release 3.0 and the faster hardware platform that this software is running on is resulting in transactions being processed for broadcast to the industry quicker than the SOA – NPAC interface can transmit them. During peak periods the interface cannot support the volumes of notifications that the NPAC SMS is generating, thus there is a long delay in notification delivery that results in operational issues. There are several change orders that, together, have the potential of alleviating this problem. NeuStar and the LNPA Working Group has bundled these change orders together for NPAC Release 3.1.  Release 3.2  The industry through work in the LNPA Working Group defined requirements for the next release to be adopted by all regions. The Release 3.2 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality as well as modifications to existing functionality. The major enhancements include enhanced Bulk Data Download File processing capabilities, improved recovery functionality that supports the generation of linked reply messages over the NPAC SMS to SOA and/or LSMS interface, enhanced DPC/SSN value edits to ensure the data is formatted based on industry LNP standards, enhanced NPA Split processing that includes automated processing based on industry standard information, further Subscription Version processing capabilities, additional NPAC SMS edits to ensure that telephone numbers are not ported outside of a single LATA, and capabilities that will ease partial and full SPID migration (in the event of a purchase or merger between Service Providers).                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-15    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction    Release 3.3  The industry through work in the LNPA Working Group defined requirements for the next release to be adopted by all regions. The Release 3.3 as agreed upon in all regions includes enhancements to the NPAC SMS for new functionality as well as modifications to existing functionality. The major enhancements include restriction of conflict resolution to alleviate inadvertent porting, improved recovery, flow control to assist with congestion situations, “un-do” cancel-pending SVs, improved abort behavior, BDD for notifications, performance improvements, resend exclusion, association heartbeat, application level error messages, and separate SOA association for notifications.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-16    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Introduction      1.4 Objective  The objective of this document is to uniquely identify the baseline end-user, functional requirements that define the LNP SMS supporting number portability.    1.5 Assumptions          A1-1   Proportional Billing    The Service Providers will be billed in proportion to their usage of the services provided by the NPAC SMS.          AR1-1   Service Provider ID    All NPAC Customers will obtain a unique Service Provider ID from a proper source.          A1-2   Resource Accounting    The resource accounting measurements will not cause degradation in the performance of the basic functions of the NPAC SMS.          AR3-1   Greenwich Mean Time    Specific time of day references in the Functional Requirements Specification are assumed to be in Greenwich Mean Time (GMT) for the following:     •   SOA to NPAC SMS Messages      •   NPAC SMS to Local SMS Messages      •   Reports      •   Bulk Data Download Files            AN3-4.1   NPA Split Information Source    The default information source for NPA Split processing shall be the NPA Split Load Flat File, which is processed automatically based on a housekeeping process.          AR3-2   NPAC Administrative and SOA Low-Tech Interface Time    DELETED          AR3-3   System Tunable Time    DELETED                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-17    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction            AR4-1.1   Service Provider ID    All NPAC Customers will obtain a unique Service Provider ID from a proper source.          AR5-2   Conflict Resolution Tunable due date value    The time used for the conflict restriction tunable calculation relies on the time value specified in the New Service Provider due date.          AR5-3   Changing of TN Range Notification Indicator while Notifications are Queued    In the event that the TN Range Notification Indicator is changed from TRUE to FALSE any notifications for multiple TNs that were already created and are in queue will be sent in the range format and in the event that the TN Range Notification Indicator is changed from FALSE to TRUE any notifications for multiple TNs that were already created and are in queue will be sent in the single format.          AR6-1   Range Activations    DELETED          AR6-2   Percent of Range Activations    DELETED          AR6-3   TN-to-Transaction Ratio    There is one TN per CMIP transaction as specified in R6-28.1, R6-28.2, R6-29.2, RR6-107, RR6-108, and RR6-109. (previously NANC 393, AR-New-1)          AR6-4   CMIP Transaction Definition    A CMIP transaction is a request/notification and it’s corresponding response. (previously NANC 393, AR-New-2)          AR6-5   Peak Period Definition    Peak, as specified in R6-28.2 and R6-29.2, is defined as a five-minute period, and one peak can occur within any 60-minute window. (previously NANC 393, AR-New-3)          AR6-6   Number of Local SMS Associated to the NPAC SMS    There are thirty (30) Local SMSs associated to the NPAC SMS as specified in RR6-109, related to the total NPAC SMS bandwidth for a single NPAC SMS region. (previously NANC 393, AR-New-4)          A8-1   Service Provider Audits Issued Immediately    NPAC SMS will process audit requests from service providers immediately.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-18    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction            AR10-1   Scheduled Downtime    NPAC initiated downtime as defined in R10-5 does not include downtime needed for software release updates initiated by or collectively agreed to by the Service Providers.          A11-2   Accounting Measurements Will Not Degrade the Basic System Performance    The resource accounting measurements will not cause degradation in the performance of the basic functions of the NPAC.          A3-5   Associated Service Provider Multiple Service Provider Ids    Associated service providers using SOA functionality from another primary service provider must use another service provider id if they choose to interact with the NPAC independently from the primary service provider for SOA functionality.    1.6 Constraints  The following constraints shall be adhered to during the development of the software associated with the requirements within this document.          C1-1   Real Time Call Processing    The NPAC SMS is not involved in real time call processing.          C1-2   Service Provider Activity Tracking    The NPAC SMS is not involved in facilitating or tracking Service Provider-to-Service Provider activities.          CN2-1.1.1   Interactions between Service Providers are beyond the scope of the NPAC SMS    Processes for obtaining authorization from the customer to port a number are defined by the Service Providers. The NPAC is not involved in obtaining or verifying customer authorization. Details of steps in those processes do not involve the NPAC or NPAC SMS, and are beyond the scope of the NPAC SMS functionality.          CN2-1.3.1.   Service provider network change activities are beyond the scope of the NPAC SMS    Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as physical changes performed in the Service Provider’s networks, are beyond the scope of the NPAC SMS functionality.          CN2-1.4.1   Service provider’s internal activities are beyond the scope of this document    Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as physical changes performed in the Service Provider’s networks are beyond the scope of this document.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-19    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction            CN2.1.5.1.   Service Provider’s Network Change Validation Activities Are Beyond The Scope Of The NPAC SMS    Network testing performed by the Service Providers, such as testing of call processing and testing of Service Provider network elements, is beyond the scope of the NPAC SMS.          CN2-1.6.1   Service provider’s internal activities are beyond the scope of this document    Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as updates to data performed in the Service Providers network elements are beyond the scope of this document.          CN2-3.3.1   Service provider’s repair activities are beyond the scope of the NPAC SMS    Details of steps in the repair processes that do not involve the NPAC or NPAC SMS, such as the customer’s notification of problems, the Service Provider’s analysis/troubleshooting activities and the Service Provider’s repair activities are beyond the scope of the NPAC SMS functionality.          CN2.4.2.1.   Service provider’s conflict resolution activities are beyond the scope of the SMS NPAC    Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as conflict resolution escalation and arbitration activities are beyond the scope of this document.          CN2-6.1.1   Interactions between Service Providers are beyond the scope of this document    Processes for obtaining authorization from the customer to port a number are defined by the Service Providers. The NPAC is not involved in obtaining or verifying customer authorization. Details of steps in those processes do not involve the NPAC or NPAC SMS, and are beyond the scope of this document.          C3-1   Associated Service Provider Notification Aggregation    NPAC SMS aggregation of all messages over the SOA to NPAC SMS interface for primary and associated service provider ids will not be supported.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    1-20    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Introduction    2. Business Process Flows  The following process flows indicate how the NPAC SMS is used by the Service Providers in business processes associated with number portability. Specific requirements generated by the process flows are included in the appropriate sections later in the document.  The process flows supported by the NPAC SMS are:     •   Service Provisioning      •   Service Disconnection      •   Service Repair      •   Conflict and Conflict Resolution      •   Disaster Recovery and Backup      •   Service Order Cancellation      •   Audit Requests      •   Report Requests      •   Data Administration Requests      2.1 Provision Service Process  This process flow defines the provisioning flow in which a customer ports a telephone number to a new Service Provider. The service provisioning flow activities are shown in Appendix A, Flow 2.1 NPAC SMS Provision Service Process, on page A-1.          2.1.1   Service provider-to-service provider activities    The new Service Provider will notify the old Service Provider according to processes internal to the Service Providers.          CN2-1.1.1   Interactions between Service Providers are beyond the scope of the NPAC SMS    Processes for obtaining authorization from the customer to port a number are defined by the Service Providers. The NPAC is not involved in obtaining or verifying customer authorization. Details of steps in those processes do not involve the NPAC or NPAC SMS, and are beyond the scope of the NPAC SMS functionality.          2.1.2   Subscription version creation process    The Subscription Version creation flow activities are shown in Appendix A, Flow 2.1.2 NPAC SMS Subscription Version Creation Process, on page A-1.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-1    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Business Process Flows            2.1.2.1   Create Subscription Version    When a number is ported, both the old and new Service Providers can send a notification to the NPAC SMS. The NPAC validates the data for each notification and attempts to match the notification with a concurring notification from the other Service Provider. If a notification is missing from either provider after a tunable time period, the NPAC sends a request for the missing notification. If the data provided with the notification is valid, the NPAC SMS creates a pending Subscription Version and awaits the concurring notification. If the data is invalid, the NPAC SMS reports a specific error to the sender of the data and discards the request.          2.1.2.2   Request missing/late notification    If concurring notification or explicit non-concurrence from the old Service Provider is not received, the process flows to process 2.1.3, as illustrated in Appendix A, Flow 2.1 NPAC SMS Provision Service Process, on page A-1. If concurring notification or explicit non-concurrence from the new Service Provider is not received, the process flows to 2.6 (Cancel).          2.1.2.3   Final Concurrence Notification to Old Service Provider    The NPAC will send a final concurrence notification to the Old Service Provider who did not send a concurring notification.          2.1.3   Service providers perform physical changes    The two Service Providers involved in the number port will coordinate and perform the physical changes to their respective networks.          CN2-1.3.1.   Service provider network change activities are beyond the scope of the NPAC SMS    Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as physical changes performed in the Service Provider’s networks, are beyond the scope of the NPAC SMS functionality.          2.1.4   NPAC SMS “activate and data download” process    The NPAC network data broadcast download flow is shown in Appendix A, Flow 2.1.4 NPAC SMS Activate and Data Download Process, on page A-1.          2.1.4.1   New Service Provider sends activation to NPAC SMS    The new Service Provider sends an activate notification to the NPAC SMS. If the current date is greater than or equal to the new Service Provider due date, the flow continues. Otherwise, broadcast of the activation is rejected.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-2    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Business Process Flows            2.1.4.2   NPAC SMS broadcasts network data to appropriate Service Providers    Upon receipt of the activation notification, the NPAC SMS broadcasts the network update data in real time to the appropriate Service Providers’ Local SMSs.          2.1.4.3   Failure — notify NPAC    If the NPAC SMS does not receive positive acknowledgment of the broadcast from all Service Providers, the NPAC SMS will rebroadcast the network data download to the Service Providers that did not acknowledge the original broadcast. The NPAC SMS will perform the rebroadcast a tunable number of times within a tunable time frame.          2.1.4.4   Initiate repair procedures    If the tunable rebroadcast parameters have been exceeded, the NPAC staff will initiate repair processes with the appropriate Service Providers. The NPAC SMS will send the list of Service Providers associated with each failed or partial failure subscription version to the old and new Service Providers.          2.1.5   Service providers perform network updates    Upon receiving the network data download broadcast from the NPAC SMS, all Service Providers’ local SMSs will confirm the receipt of the download broadcast, and update their network elements. The Service Providers may also test their network changes.          CN2-1.5.1.   Service Provider’s Network Change Validation Activities Are Beyond The Scope Of The NPAC SMS    Network testing performed by the Service Providers, such as testing of call processing and testing of Service Provider network elements, is beyond the scope of the NPAC SMS.    2.2 Disconnect Process  This process flow defines the activities associated with the discontinuance of service for a ported number. The NPAC Disconnect Service flow is shown in Appendix A, Flow 2.2 NPAC SMS Disconnect Process, on page A-1.          2.2.1   Customer notification, Service Provider initial disconnect service order activities    When a ported number is being disconnected, the customer and Service Provider will agree on a date. The Service Provider will send a notification to the NPAC SMS indicating the date of the physical disconnect of the number and, optionally, the date that the disconnect information is to be broadcast to all Local SMSs (the ‘effective release date’).                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-3    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Business Process Flows            2.2.2   NPAC waits for effective release date    The NPAC SMS will send delete actions containing the disconnect information based on the effective release date specified by the Service Provider. If no effective release date is specified on the disconnect request, the NPAC SMS processes the request immediately.          2.2.3   NPAC donor notification    The NPAC SMS will broadcast the effective release date and disconnect date to the donor SOA.          2.2.4   NPAC performs broadcast download of disconnect data    The NPAC SMS will broadcast the disconnect information to all Service Providers. If the broadcast is not acknowledged, the disconnect information will be resent a tunable number of times within a tunable time frame. If the tunable parameters for the collection of responses have been exceeded, the NPAC staff will initiate repair processes with the appropriate Service Providers (Flow 2.3), and send a list of failed Service Providers to the current Service Provider.    2.3 Repair Service Process  This process flow defines the activities performed when a problem is detected either by the NPAC SMS, a Service Provider, or by a customer who contacts a Service Provider. The repair service flow is shown in Appendix A, Flow 2.3 NPAC SMS Repair Process, on page A-2.          2.3.1-A   Service provider receives problem notification from customer    If a customer determines there is a problem with their service, they may contact the Service Provider and request Repair Service. This is one possible entry point to the Repair Process flow.          2.3.1-B   Service provider receives problem notification from another Service Provider    If another Service Provider determines there is a problem with a customer’s service, they may contact the current Service Provider and request Repair Service. This is one possible entry point to the Repair Process flow.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-4    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Business Process Flows            2.3.1-C   Service provider receives problem notification from NPAC SMS    If the NPAC determines there is a problem with a customer’s service, they may contact the current Service Provider and request Repair Service. This is one possible entry point to the Repair Process flow.          2.3.2   Service provider analyzes the problem    If NPAC SMS intervention is needed to resolve the problem, up to three repair actions may be required before repairs can be initiated.          2.3.2-A   Subscription data query required    If a Subscription data query is required to initiate the repair, a query is launched to the Local Service Providers.          2.3.2-B   Subscription data audit required    If a Subscription data audit is required before the repair can be initiated, an audit is initiated with the local Service Providers.          2.3.2-C   Network synchronization required    If network synchronization is required, the process flows to 2.3.5, Request broadcast of subscription data.          2.3.3   Service provider performs repairs    There will be audit capabilities in the NPAC SMS to aid in isolating problems.          CN2-3.3.1   Service provider’s repair activities are beyond the scope of the NPAC SMS    Details of steps in the repair processes that do not involve the NPAC or NPAC SMS, such as the customer’s notification of problems, the Service Provider’s analysis/troubleshooting activities and the Service Provider’s repair activities are beyond the scope of the NPAC SMS functionality.          2.3.4   Request broadcast of subscription data    There will be audit capabilities in the NPAC SMS to aid in isolating problems. A Service Provider may request a download of subscription data to assist in the repair process, if necessary.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-5    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Business Process Flows            2.3.5   Broadcast repaired subscription data    If inaccurate routing data is found, the NPAC SMS will broadcast the correct subscription data to any involved Service Provider’s networks to correct inaccuracies.    2.4 Conflict Process  This process flow defines the activities performed when Service Providers disagree on who will serve a particular customer. The conflict flow is shown in Appendix A, Flow 2.4.1 Conflict Process, on page A-2.          2.4.1   Subscription version in conflict    A Subscription Version may be put into a conflict state either by the old Service Provider (assuming certain conditions are true), or as a result of a failure to acknowledge a Subscription Version in Cancel-Pending state by the new Service Provider. Subscription Versions set to either conflict or cancel initiate the creation of an entry in the Subscription Cause Code field identifying the cause of the status change.          2.4.1.1   Cancel-Pending Acknowledgment missing from new Service Provider    If the new Service Provider has not yet acknowledged a Subscription Version in Cancel-Pending state, the Subscription Version is put into Conflict, and the Cause Code is updated accordingly.          2.4.1.2   Old Service Provider requests conflict status    If the old Service Provider requests that a Subscription Version be put in conflict, it must be the first time the request has been made (a request to put a Subscription Version in conflict can only be made once by the old Service Provider). The request must be received in the NPAC a tunable number of hours prior to 12:00 A.M. of the new Service Provider due date and the expiration of the Final Concurrence Window unless short timers are being used for the port. If the old Service Provider has not satisfied these conditions then the Subscription Version cannot be put into conflict.          2.4.1.3   Change of status upon problem notification    Subscription version’s conflict status “on” is achieved when a Service Provider notifies NPAC SMS personnel of a disagreement between the new and old Service Providers as to whether or not a TN may be ported. The old Service Provider can only place a “pending” Subscription Version in “conflict” one time.          2.4.1.4   Change of status upon Old Service Provider non-concurrence    A Subscription Version creation with authorization set to “False” from the Old Service Provider causes the NPAC SMS to place the Subscription Version in conflict during the “Create Version” process (2.1.2).                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-6    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Business Process Flows       2.4.1.5   Change of status upon New Service Provider non-concurrence    Non-concurrence from the New Service Provider causes the NPAC SMS to cancel the Subscription Version during the “Create Version” process (2.1.2).     2.4.2   New Service Provider coordinates conflict resolution activities    The New and Old Service Providers use internal and inter-company processes to resolve the conflict. If the conflict is resolved, the new Service Provider sets the Subscription Version status to pending. If the conflict is not resolved with the tunable maximum number of days, the NPAC SMS cancels the Subscription Version, and sets the Cause Code for the Subscription Version.     2.4.2.1   Cancel pending notification    The cancel-pending notification is used for Subscription Versions where both the Old and New Service Providers have sent their Create message to the NPAC SMS. The status will be either pending or conflict.  If the Old Service Provider sends the Cancel message, the Subscription Version is set to cancel-pending. A notification is sent to both Old and New Service Providers.     1.   If the New Service Provider sends a cancellation acknowledgment, the status is set to Canceled.      2.   If the New Service Provider does NOT send a cancellation acknowledgment, the NPAC SMS waits for both Cancellation Concurrence Windows to expire, at which time the status is set to Conflict and the NPAC SMS sends a notification to both the Old and New Service Providers indicating the status change.      3.   The Old Service Provider may optionally send the cancellation acknowledgment.    If the New Service Provider sends the Cancel message, the Subscription Version is set to cancel-pending. A notification is sent to both Old and New Service Providers.     1.   If the Old Service Provider sends a cancellation acknowledgment, the status is set to Canceled.      2.   If the Old Service Provider does NOT send a cancellation acknowledgment, the NPAC SMS waits for both Cancellation Concurrence Windows to expire, at which time the status is set to Cancel.      3.   The New Service Provider may optionally send the cancellation acknowledgment.    If the Service Provider (either Old or New) that sent the Cancel message, issued the cancel request in error, that Service Provider can “un-do” the request by sending a subsequent modify request, and the Subscription Version is set back to pending. A notification is sent to both Old and New Service Providers.          CN2.4.2.1.       Service provider’s conflict resolution activities are beyond the scope of the SMS NPAC    Details of steps in the processes that do not involve the NPAC or NPAC SMS, such as conflict resolution escalation and arbitration activities are beyond the scope of this document.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-7    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flows       2.4.3   Subscription version cancellation    If the Subscription Version status has been set to conflict “on” for 30 days [tunable parameter] and no resolution has occurred, the NPAC SMS will cancel the Subscription Version, set the Cause Code for the Subscription Version, and notify both the old and new Service Providers of the cancellation.     2.4.4   Conflict resolved    When both Service Providers agree to resolve the conflict, one of the Service Providers will send a request to the NPAC SMS to change the Subscription Version status to pending. In the case of cause codes 50 or 51, the NPAC will only accept the resolve conflict message from the Old Service Provider.    2.5 Disaster Recovery and Backup Process  This process flow defines the backup and restore activities performed by the NPAC and the Service Providers. The disaster recovery flow is shown in Appendix A, Flow 2.5 NPAC SMS Disaster Recovery Process, on page A-1.     2.5.1   NPAC personnel determine downtime requirement    If there is planned downtime for the NPAC SMS, the NPAC SMS will send an electronic notification to the Service Providers’ SOAs that includes information on when the downtime will start, how long it will be, and if they will be required to switch to the backup or disaster recovery machine. Downtime is considered planned when the NPAC can provide notification to the Service Providers at least 24 hours in advance.  If there is unplanned downtime, the NPAC will assess how long the primary machine will be down. The NPAC will notify all of the Service Providers by electronic notification and telephone calls to the Service Providers’ contact numbers. The notification will describe the situation and the planned action. The Service Providers will attempt to switch to the backup NPAC.     2.5.2   NPAC notifies Service Providers of switch to backup NPAC and start of cutover quiet period    The NPAC Service Providers will switch to the backup or disaster recovery machine as indicated in the notification.     2.5.3   Service providers connect to backup NPAC    The Service Providers must use an alternate connection route to the backup NPAC and establish associations with the backup NPAC application.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flows       2.5.4   Backup NPAC notifies Service Providers of application availability and end of cutover quiet period    When the backup NPAC application and database are on-line, processes will proceed as normal. The backup NPAC application will be at the same version level as the primary NPAC application. The NPAC SMS database will also contain the same routing information as the primary database.     2.5.5   Service providers conduct business using backup NPAC    The Service Provider should continue to process as normal when connected to the backup NPAC.     2.5.6   Backup NPAC notifies Service Providers of switch to primary NPAC and start of cutover quiet period    When the primary machine is brought back up, the backup NPAC will advise the Service Providers of the timing of their switch back to the primary machine.     2.5.7   Service providers reconnect to primary NPAC    The Service Providers re-establish associations with the primary NPAC application using their normal connections.     2.5.8   Primary NPAC notifies Service Providers of availability and end of cutover quiet period    When the primary NPAC is available, NPAC personnel will notify Service Providers of the end of the cutover quiet period.    2.6 Service Order Cancellation Process  This flow defines the process performed when a Service Provider cancels a service order. The service order cancellation flow is shown in Appendix A, Flow 2.6 Cancellation Process, on page A-2.     2.6.1   Service Provider issues service order cancellation    From the time both Service Providers have sent a valid notification of a new Subscription Version to the time the Subscription Version is activated, either Service Provider may send a message to the NPAC SMS to cancel the Subscription Version. If this occurs, the NPAC SMS will notify both Service Providers that the Subscription Version is in a cancel-pending state.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flows       2.6.2   Service provider cancels an un-concurred Subscription Version    If a Service Provider issues a cancel on a Subscription Version that was created by that Service Provider and not concurred to by the other Service Provider involved in that port, or if the Subscription Version was initiated, then subsequently canceled by the NPAC, the Subscription Version will be canceled immediately and a notification will be sent to both Service Providers.     2.6.3   NPAC requests missing acknowledgment from Service Provider    When notified that a Subscription Version has been set to cancel-pending, the non-requesting Service Provider must concur by returning a cancel-pending acknowledgment to the NPAC SMS within a tunable amount of hours. If the NPAC does not receive acknowledgment in the allowable time from the Service Provider, a request is sent to that Service Provider for a cancel-pending-acknowledgment. If the missing cancel-pending-acknowledgment is not received within a tunable time frame, the Subscription Version status is set to “conflict” if it is the new Service Provider that failed to acknowledge, but is set to cancel if the old Service Provider failed to acknowledge. In either case, the Cause Code is then set for the Subscription Version, and both Service Providers are then notified of the Subscription Version status change.     2.6.4   NPAC cancels the Subscription Version and notifies both Service Providers    When acknowledgment is received from both Service Providers, within the allowed time frame the NPAC SMS will set the Subscription Version to canceled in its database, update the Cause Code for the Subscription Version, and notify both Service Providers that the Subscription Version has been canceled. All canceled Subscription Versions are purged from the NPAC database after a tunable period.    2.7 Audit Request Process  This process flow defines the activities performed by the NPAC when Service Providers request audits of LNP data. The audit request flow is shown in Appendix A, Flow 2.7 Audit Process, on page A-1.     2.7.1   Service provider requests audit    Any Service Provider can request an audit of another Service Provider’s LSMS.     2.7.2   NPAC SMS issues queries to appropriate Service Providers    Upon receipt of an audit request, the NPAC SMS queries the appropriate Service Provider’s Local SMS databases.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flows       2.7.3   NPAC SMS compares Subscription Version data    The NPAC SMS compares its own Subscription Version data to the data it finds in the targeted Local SMS Subscription Version databases.     2.7.4   NPAC SMS updates appropriate Local SMS databases    The NPAC SMS updates Subscription Version information in the appropriate Local SMS databases.     2.7.5   NPAC SMS sends report of audit discrepancies to requesting SOA    Once the NPAC SMS has completed updates to the appropriate Local SMSs, the NPAC SMS generates an Audit Discrepancy report to the Service Provider SOA that initiated the Audit request.     2.7.6   NPAC SMS sends report of audit results to requesting SOA    The NPAC SMS sends the audit results to the Service Provider SOA that initiated the audit request, to indicate the audit is complete.    2.8 Report Request Process  This process flow defines the activities performed by the NPAC when the Service Providers request report generation and delivery. The report request flow is shown in Appendix A, Flow 2.8 Report Process, on page A-2.     2.8.1   Service provider requests report    Service Provider personnel request report generation via either the SOA Low Tech Interface or by contacting NPAC personnel.     2.8.2   NPAC SMS generates report    The NPAC SMS generates the report that Service Provider Personnel requested via either the SOA Low Tech to NPAC SMS interface or based on NPAC personnel input into the NPAC Administrative GUI.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flows       2.8.3   Report delivered via NPAC Administrative or SOA Low-Tech Interface, Email, electronic file, fax, printer    The NPAC SMS delivers the report to the destination specified in the request.  2.9 Data Administration Requests  This section defines the activities performed by the NPAC when Service Providers make a manual request for data administration.     2.9.1   Service provider requests administration of data by NPAC personnel    Service provider personnel are able to contact NPAC personnel to request data administration activities.     2.9.2   NPAC SMS personnel confirms user’s privileges    Before NPAC personnel fulfill the data administration request, they will confirm the user’s privileges and validate the request.     2.9.3   NPAC SMS personnel inputs user’s request    Upon validation of the request, NPAC personnel will input the request.     2.9.4   NPAC SMS performs user’s request    The NPAC SMS processes the request.     2.9.5   NPAC SMS personnel logs request denial if user’s privileges are not validated    If the user’s privileges are not confirmed, or the request cannot be validated, the NPAC personnel log the activity and end the process.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    2-12    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    3. NPAC Data Administration    3.1 Overview  The NPAC SMS manages the ported TN information associated with Service Provider portability for the LNP service. This section describes the high level requirements associated with managing ported telephone numbers from an operations perspective. Figure 3-1 Entity Relationship Model illustrates the logical data model associated with the data elements for the NPAC SMS, and the relationship between NPAC Customer data and other data tracked or created by the system.          AR3-1       Greenwich Mean Time    DELETED          AR3-2       NPAC Administrative and SOA Low-Tech Interface Time    DELETED          AR3-3       System Tunable Time    DELETED  [Graphic Omitted: Entity Relationship Model]     3.1.1   Data Type Legend    The following table describes the data types used in the data models.  DATA TYPE LEGEND              Data Type   Description     Address    Network Address: raw binary data stored as unformatted bytes.           B    Boolean (True or False) indicator.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration                  C    Character or Alphanumeric strings.           E    Enumeration.           M    Bit Mask comprised of one or more bytes.           N    Numeric data (up to 32 bit integer, numeric data that can be arithmetically manipulated).           N(x)    Character string of “x” digits only.           T    Timestamp: month, day, year, hour, minute, and seconds.           TN    Telephone Number: 3digit NPA, 3digit NXX, 4digit Station Number.     Table 3-1 Data Type Legend     3.1.2   NPAC Customer Data    NPAC Customer Data contains information about NPAC customers participating in the LNP service. The data items that need to be administered by NPAC Customer Data Management are represented in the tables that follow:          NOTE: A   check in the “Required” column means that this attribute must exist in the record before the record is considered useable.    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                 NPAC Customer ID    C (4)    Ö    An alphanumeric code which uniquely identifies an NPAC Customer.                   NPAC Customer Name    C (40)    Ö    A unique NPAC Customer Name.                   NPAC Customer Allowable Function    ns M    Ö    Each bit in the mask represents a Boolean indicator for the following functional options: •    SOA Management •    SOA Network Data Management •    SOA Data Download •    LSMS Network Data Management •    LSMS Data Download •    LSMS Queries/Audits                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                 NPAC New Functionality Support    B    Ö    Each value represents a Boolean indicator is set to true if a service provider supports the functionality defined below. This Boolean is used to support backward compatibility. All values default to FALSE. •    Timer Type – True if the SOA supports timer type over the interface. •    Business Hours – True if the SOA supports business days/hours over the interface. •    LSMS WSMSC DPC SSN Data – True if the LSMS system supports WSMSC DPC and SSN Data in subscription versions. •    SOA WSMSC DPC SSN Data – True if the SOA system supports WSMSC DPC and SSN Data in subscription versions.                   Port In Timer Type    E    Ö    Timer type supported by the Service Provider for porting where they are the New Service Provider: S – Short Timers L – Long Timers                   Port Out Timer Type    E    Ö    Timer type supported by the Service Provider for porting where they are the Old Service Provider: S – Short Timers L – Long Timers                   Business Hour/Days    E    Ö    Business Hours supported by the Service Provider: S – Short Business Hours L – Long Business Hours                   NPA-NXX-X downloads Indicator    B    Ö    A Boolean that indicates whether NPAC Customer SOA NPA-NXX-X the NPAC Customer accepts                                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                              from the NPAC SMS to their SOA. This would be used in conjunction with the SOA Data Download bit mask value. The default value is False.                   NPAC Customer LSMS NPA-NXX-X Indicator    B    Ö    A Boolean that indicates whether the NPAC Customer accepts NPA-NXX-X downloads from the NPAC SMS to their LSMS. This would be used in conjunction with the LSMS Data Download bit mask value. The default value is False.                   NPAC Customer LSMS EDR Indicator    B    Ö    A Boolean that indicates whether the NPAC Customer utilizes Efficient Data Representation (EDR) on the LSMS. This would be used in conjunction with the LSMS Data Download bit mask value. The default value is False.                   TN Range Notification Indicator    B    Ö    A Boolean that indicates whether or not the NPAC Customer supports receiving the range format for SOA Notifications. The default value is False.                   No New SP Concurrence Notification Indicator     B    Ö    A Boolean that indicates whether or not the NPAC Customer supports receiving the SOA Notification “No New SP Concurrence Notification. The default value is False.                   SOA Notification Priority Tunable Parameters    C    Ö    Allows a NPAC Customer to establish the priority to be used for transmitting the notifications listed in Appendix C, Table C7 to his SOA. Valid priority values for these notifications are HIGH, MEDIUM, LOW, and NONE. A priority of NONE indicates that the NPAC Customer does NOT wish to receive that particular notification. The default value is MEDIUM.                   NPAC Customer SOA Linked Replies    B    Ö    A Boolean that indicates whether or not the                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                 Indicator            NPAC Customer supports receiving Linked Reply recovery responses over the NPAC SMS to SOA interface. The default value is FALSE.                   NPAC Customer Local SMS Linked Replies Indicator    B    Ö    A Boolean that indicates whether or not the NPAC Customer supports receiving Linked Reply recovery responses over the NPAC SMS to Local SMS interface. The default value is FALSE.                   Maximum TN Download in Recovery Request    N    Ö    A Service Provider specific tunable indicating the maximum number of TNs that can be recovered in a single timebased, recovery request. Valid range is 11-0000.  The default value is 2000. Refer to Appendix C System Tunables for information on the maximum for TN-based SV recovery requests.                   Service Provider SOA SWIM Recovery Indicator    B    Ö    A Service Provider Boolean that indicates whether or not this Service Provider supports SWIM Recovery over their SOA to NPAC SMS interface. The default value is FALSE.                   Service Provider LSMS SWIM Recovery Indicator    B    Ö    A Service Provider Boolean that indicates whether or not this Service Provider supports SWIM Recovery over their LSMS to NPAC SMS interface. The default value is FALSE.                   NPAC SMS-to-SOA Application Level Heartbeat Indicator    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer SOA supports an Application Level Heartbeat message. The default value is FALSE.                   NPAC SMS-to-LSMS Application Level    B    Ö    A Service Provider Boolean that defines                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                 Heartbeat Indicator            whether the NPAC Customer LSMS supports an Application Level Heartbeat message. The default value is FALSE.                   SOA Action Application Level Errors Indicator    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer supports Application Level Errors across the SOA Interface for M-ACTIONs. The default is FALSE.                   LSMS Action Application Level Errors Indicator    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer supports Application level Errors across the LSMS Interface for M-ACTIONs. The default is FALSE.                   SOA Non-Action Application Level Errors Indicator    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer supports Application Level Errors across the SOA Interface for all non-M-ACTIONs.                   LSMS Non-Action Application Level Errors Indicator    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer supports Application Level Errors across the LSMS Interface for all non-M-ACTIONs.                   SOA Notification Channel Service Provider Tunable    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer SOA supports a separate SOA association dedicated to notifications. The default is FALSE.                   Subscription Version TN Attribute Flag Indicator    B    Ö    A Service Provider Boolean that defines whether the NPAC Customer supports receipt of the Subscription Version TN attribute in a Subscription Version Status Attribute Value Change or Subscription Version Attribute Value Change notification. The default is FALSE.                   Number Pool Block NPA-NXX-X            A Service Provider Boolean that defines                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                 Attribute Flag Indicator    B    Ö    whether the NPAC Customer supports receipt of the Number Pool Block NPA-NXX-X attribute in a Number Pool Block Status Attribute Value Change or Number Pool Block Attribute Value Change notification.  The default is FALSE.                   Cancel-Pending-to-Conflict Cause Code Indicator    B    Ö    A Service Provider Boolean that defines whether a SOA NPAC Customer supports a Conflict message that uses the CancelPendingtoConflict Cause Code.  The default is FALSE.                   Service Provider SOA SV Query Indicator    B    Ö    A Service Provider Boolean that defines whether a SOA NPAC Customer supports enhanced Subscription Verison query functionality over their SOA to Service Provider SOA SV Query NPAC SMS Interface. The default is FALSE.                   Service Provider LSMS SV Query Indicator    B    Ö    A Service Provider Boolean that defines whether a LSMS NPAC Customer supports enhanced Subscription Version query functionality over their LSMS to Service Provider LSMS SV Query  NPAC SMS Interface.   The default is FALSE.                   Service Provider Type    E    Ö    Enumeration indicating what type of service provider the NPAC Customer is: •   Wireline (0) •   Wireless (1) •   Non-Carrier (2) •   SP Type3 (3) (supported by the interface, but not accepted until industry use defined) •   SP Type 4 (4) (supported by the interface, but not accepted until industry use defined)                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                              •   SP Type 5 (5) (supported by the interface, but not accepted until industry use defined)                   Service Provider Type SOA Indicator    B        A Service Provider Boolean that indicates whether the NPAC Customer SOA supports the Service Provider Type attribute. Default value is FALSE.                   Service Provider Type LSMS Indicator    B        A Service Provider Boolean that indicates whether the NPAC Customer LSMS supports the Service Provider Type attribute. Default value is FALSE.                   NPAC Customer SOA SV Type Indicator    B    Ö    A Boolean that indicates whether the NPAC Customer supports SV Type (or Number Pool Block SV Type) information from the NPAC SMS to their SOA. The default value is False.                   NPAC Customer SOA Alternative SPID Indicator    B    Ö    A Boolean that indicates whether the NPAC Customer supports Alternative SPID information (a second service provider – either a facility-based provider or reseller, acting as a non facility-based provider) from the NPAC SMS to their SOA. The default value is False.                   NPAC Customer LSMS SV Type Indicator    B    Ö    A Boolean that indicates whether the NPAC Customer supports SV Type (or Number Pool Block SV Type) information from the NPAC SMS to their LSMS. The default value is False.                   NPAC Customer LSMS Alternative SPID Indicator    B    Ö    A Boolean that indicates whether the NPAC Customer supports Alternative SPID information (a second service provider — either a facility-based provider or reseller, acting as a non facility-based provider) from the NPAC SMS to their LSMS.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER DATA MODEL                      Attribute Name   Type   Required   Description       (Size)                              The default value is False.     Table 3-2 NPAC Customer Data Model  NPAC CUSTOMER CONTACT DATA MODEL                      Attribute Name   Type   Required     Description       (Size)                   NPAC Customer Contact ID    N    Ö    A unique sequential number assigned upon creation of the Contact record.                   NPAC Customer ID    C (4)    Ö    An alphanumeric code which uniquely identifies an NPAC Customer.                   Contact Type    C (2)    Ö    The type of NPAC Customer Contact Organization. Valid values are: •   BI -   Billing •   CF-   Conflict Resolution Interface •   LI-   Local SMS Interface •   NC -   NPAC Customer •   NF -   Network and Communications Facilities Interface •   OP -   Operations •   RE -   Repair Center Contact Organization •   SE -   Security •   SI -   SOA System Interface •   UA -   User Administration •   WI -   Web Interface                   Contact    C (40)    Ö    Name of NPAC Customer Contact Organization.                   Contact Address Line 1    C (40)    Ö    Contact Organization address Line 1.                   Contact Address Line 2    C (40)    Ö    Contact Organization address Line 2.                   Contact City    C (20)    Ö    Contact Organization city.                   Contact State    C (2)    Ö    Contact Organization state.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER CONTACT DATA MODEL                      Attribute Name   Type   Required    Description       (Size)                   Contact Zip    C (9)    Ö    Contact Organization zip code or postal code.                   Contact Country    C (20)    Ö    Contact Organization country.                   Contact Province    C (2)        Contact Organization province.                   Contact Phone    TN    Ö    Contact Organization phone number.                   Contact Fax    TN        Contact Organization Fax phone number.                   Contact Pager    TN        Contact Organization Pager phone number.                   Contact Pager PIN    C (10)        Contact Organization Pager Personal Identification Number (PIN).                   Contact Email    C (60)        Contact Organization E-mail address.     Table 3-3 NPAC Customer Contact Data Model  NPAC CUSTOMER NETWORK ADDRESS DATA MODEL                      Attribute Name   Type   Required    Description       (Size)                   NPAC Customer Network Address ID    N    Ö    A unique sequential number assigned upon creation of the Network Address record.                   NPAC Customer ID    C (4)    Ö    An alphanumeric code which uniquely identifies an NPAC Customer.                   Network Address Type    C (1)    Ö    Type of Network Address. Valid values are:                  •   S   -   SOA interface •   L   -   Local SMS interface                   NSAP Address    Address (12)    Ö    OSI Network Service Access Point Address                   TSAP Address    Address (4)        OSI Transport Service Access Point Address.                   SSAP Address    Address (4)    Ö    OSI Session Service Access Point Address.                   PSAP Address    Address (4)    Ö    OSI Presentation Service Access Point Address.                   Internet Address    Address (12)        Internet address of the Service Provider Web interface.     Table 3-4 NPAC Customer Network Address Data Model                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NPAC CUSTOMER ASSOCIATED SERVICE PROVIDER DATA MODEL                      Attribute Name   Type   Required    Description         (Size)                   Primary NPAC Customer ID    C (4)    Ö    An alphanumeric code which uniquely identifies an NPAC Customer that will act as a primary SPID                   Associated NPAC Customer ID    C (4)    Ö    An alphanumeric code that uniquely identifies an NPAC Customer that will act as a SPID associated with a  primary SPID.     Table 3-5 NPAC Customer Associated Service Provider Data Model     3.1.3   Subscription Version Data    Subscription Version Data consists of information about the ported TNs. The data items that need to be administered by Subscription Version Data Management functions are identified in the table that follows:  SUBSCRIPTION VERSION DATA MODEL                      Attribute Name   Type   Required     Description         (Size)                   Version ID    N    Ö    A unique sequential number assigned upon creation of the Subscription Version.                   LRN    TN    Ö    The LRN is an identifier for the switch on which portable NPA-NXXs reside.                   Old Service Provider ID    C (4)    Ö    Old Service Provider ID.                   New Service Provider ID    C (4)    Ö    New Service Provider ID.                   TN    TN    Ö    Subscription Version telephone number.                                Number Portability Type. Valid enumerated values are:   Local Number Portability Type    E    Ö    • LSPP — Local Service Provider Portability (0) • LISP — Local Intra-Service Provider Portability • POOL — Pooled Block Number Port (2)                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    SUBSCRIPTION VERSION DATA MODEL                      Attribute Name   Type   Required     Description         (Size)                   Status    E    Ö    Status of the Subscription Version.   The default value is P for Pending.  Valid enumerated values are:•   X — Conflict (0) •   A — Active (1) •   P — Pending (2) •   S — Sending (3) •   F — Failed (4) •   PF — Partial Failure (5) •   DP — Disconnect Pending (6) •   O — Old (7) •   C — Canceled (8) •   CP — Cancel Pending (9)                   CLASS DPC    N (9)    Ö    DPC for 10-digit GTT for CLASS features.                   CLASS SSN    N (3)    Ö    CLASS SSN for the Subscription Version.                   LIDB DPC    N (9)    Ö    DPC for 10-digit GTT for LIDB features.                   LIDB SSN    N (3)    Ö    LIDB SSN for the Subscription Version.                   CNAM DPC    N (9)    Ö    DPC for 10-digit GTT for CNAM features.                   CNAM SSN    N (3)    Ö    CNAM SSN for the Subscription Version.                   ISVM DPC    N (9)    Ö    DPC for 10-digit GTT for ISVM features.                   ISVM SSN    N (3)    Ö    ISVM SSN for the Subscription Version.                   WSMSC DPC    N (9)    Ö    DPC for 10-digit GTT for WSMSC features. This field is only required if the service provider supports WSMSC data.                   WSMSC SSN    N (3)    Ö    WSMSC SSN for the Subscription Version. This field is only required if the service provider supports WSMSC data.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-12    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    SUBSCRIPTION VERSION DATA MODEL                      Attribute Name   Type   Required    Description         (Size)                   New Service Provider Due Date    T    Ö    The due date planned by the new Service Provider for Subscription Version Transfer. The seconds’ field should always be populated with zeros.                   Old Service Provider Due Date    T    Ö    The due date planned by the old Service Provider for Subscription Version Transfer. The seconds’ field should always be populated with zeros.                   Old Service Provider Authorization    B        A Boolean indicator set by the old Service Provider to indicate authorization or denial of Transfer of Service for the Subscription Version to the new Service Provider.                   New Service Provider Create Time Stamp    T        The date and time that the New Service Provider authorized Transfer of Service of the Subscription Version.                   Old Service Provider Authorization Time Stamp    T        The date and time that the old Service Provider authorized Transfer of Service for the Subscription Version.                   Activation Request Time Stamp    T        The date and time that the Subscription Version activation request was made by the new Service Provider.                   Activation Broadcast Date    T        The date and time that broadcasting began to all local SMS systems for the activation of the Subscription Version.                   Activation Broadcast Complete Time Stamp    T        The date and time that at least one Local SMS system successfully acknowledged the broadcast for the activate of the Subscription Version.                   Disconnect Request Time Stamp    T        The date and time that the Subscription Version disconnect request was made by the local Service Provider.                   Disconnect Broadcast Time Stamp    T        The date and time that broadcasting began to all local SMS systems for the disconnect of the Subscription Version.                   Disconnect Complete Time Stamp    T        The date and time that at least one Local SMS system successfully acknowledged the broadcast for the disconnect of the Subscription Version.                   Effective Release Date    T        The date that the Subscription Version is to be deleted from all Local SMS systems.                   Customer Disconnect Date    T        The date that the Customer’s service was disconnected.                   Pre-Cancellation Status    E        Status of the Subscription Version prior to cancellation. Valid enumerated values are: •   X — Conflict (0) •   P — Pending (2) •   DP — Disconnect Pending (6)                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-13    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    SUBSCRIPTION VERSION DATA MODEL                      Attribute Name   Type   Required    Description         (Size)                 Old Service Provider Cancellation Time Stamp    T        The date and time that the Old Service Provider acknowledged that the Subscription Version be canceled.                   New Service Provider Cancellation Time Stamp    T        The date and time that the New Service Provider acknowledged that the Subscription Version be canceled.                   Cancellation Time Stamp    T        The date and time that the Subscription Version became canceled.                   Old Time Stamp    T        The date and time that the Subscription Version became old.                   Conflict Time Stamp    T        The date and time that the Subscription Version was last placed in conflict.                   Conflict Resolution Time Stamp    T        The date and time that the resolution of a Subscription Version in conflict is acknowledged.                   Create Time Stamp    T    Ö    The date and time that this Subscription Version record was created.                   Modified Time Stamp    T    Ö    The date and time that this Subscription Version record was last modified. The default value is the Create Time Stamp.                   Porting to Original    B    Ö    A Boolean that indicates whether the Subscription Version created is to be ported back to the original Service Provider.                   End User Location Value    N (12)        For future use.                   End User Location Value Type    N (2)        For future use.                   Modify Request Timestamp    T        The date and time that the Subscription Version Modify request was made.                   Modify Broadcast Timestamp    T        The date and time that broadcasting began to all local SMS systems for the modification of the Subscription Version.                   Modify Broadcast Complete Timestamp    T        The date and time that at least one local SMS system successfully acknowledged the broadcast for the modification of the Subscription Version.                   Billing ID C    (1- 4)        For future use. Can be variable 1-4 alphanumeric characters.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-14    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    SUBSCRIPTION VERSION DATA MODEL                      Attribute Name   Type   Required    Description         (Size)                   Status Change Cause Code    N (2)        Used to specify reason for conflict when old Service Provider Authorization is set to False, or to indicate NPAC SMS initiated cancellation. Valid values are: 0 — No value 1 — NPAC SMS Automatic Cancellation 2 – NPAC SMS Automatic Conflict from Cancellation 50 – LSR/WPR Not Received 51 – Initial Confirming FOC/WPRR Not Issued 52 — Due Date Mismatch 53 — Vacant Number Port 54 – General Conflict                   Timer Type    E    Ö    Timer type used for the subscription version. S – Short Timers L – Long Timers                   Business Hour Type    E    Ö    Business Hours used for the subscription version. S – Short Business Hours L – Long Business Hours                   Alternative SPID    C (4)        An alphanumeric code which uniquely identifies Alternative SPID information (a second service provider – either a facility-based provider or reseller, acting as a non facility-based provider) for this SV. This field may only be specified if the service provider SOA supports Alternative SPID.                   SV Type    E    Ö    Subscription Version Type. Valid enumerated values are: • Wireline – (0) • Wireless – (1) • VoIP – (2) • VoWIFI – (3) • SV Type 4– (4) • SV Type 5– (5) • SV Type 6– (6) This field is only required if the service provider supports SV Type data.     Table 3-6 Subscription Version Data Model                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-15    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    SUBSCRIPTION VERSION FAILED SP LIST DATA MODEL                      Attribute Name   Type (Size)   Required   Description         Subscription Version ID (Key)    N    Ö    A unique sequential number assigned upon creation of the Subscription Version.                   SPID    C(4)    Ö    The Service Provider ID of the discrepant SP.                   SP Name    C(40)    Ö    The NPAC Customer Name of the discrepant SP.     Table 3-7 Subscription Version Failed SP List Data Model  NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL                      Attribute Name   Type (Size)   Required   Description     Block ID   N   Ö   A unique sequential number assigned upon creation of the Block.                   Block Holder SPID   C(4)   Ö   The Service Provider Id of the block holder.                   NPA-NXX-X   N(7)   Ö   NPA-NXX-X of the 1K Block.                   LRN   TN   Ö   The LRN is an identifier for the switch on which the pooled NPA-NXX-X resides for the 1K Block.                   CLASS DPC   N (9)   Ö   DPC for 10-digit GTT for CLASS features for the 1K Block.                   CLASS SSN   N (3)   Ö   CLASS SSN for the 1K Block.                   LIDB DPC   N (9)   Ö   DPC for 10-digit GTT for LIDB features for the 1K Block.                   LIDB SSN   N (3)   Ö   LIDB SSN for the 1K Block.                   CNAM DPC   N (9)   Ö   DPC for 10-digit GTT for CNAM features for the 1K Block.                   CNAM SSN   N (3)   Ö   CNAM SSN for the 1K Block.                   ISVM DPC   N (9)   Ö   DPC for 10-digit GTT for ISVM features for the 1K Block.                   ISVM SSN   N (3)   Ö   ISVM SSN for the 1K Block.                   WSMSC DPC   N (9)   Ö   DPC for 10-digit GTT for WSMSC features for the 1K Block.  This field is only required if the service provider                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-16    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL                      Attribute Name   Type (Size)   Required   Description                       supports WSMSC data, as defined in the NPAC Customer Data Model.                   WSMSC SSN   N (3)   Ö   WSMSC SSN for the 1K Block.  This field is only required if the service provider supports WSMSC data, as defined in the NPAC Customer Data Model.                   Creation Date   T       The date and time (GMT) that this Block Holder record was created.                   Activation Start Timestamp   T       Date and time (GMT) of the Start of the Activation.  This field defines the date and time of the start of the activation request (i.e., the date and time the NPAC begins the broadcasts to the LSMSs).                   Activation Broadcast  Complete Timestamp   T       Date and time (GMT) of the Completion of the Activation.  This field defines the date and time of the completion of the activation request (i.e., the date and time the NPAC receives at least one Local SMS acknowledgment of the broadcast, for the activation of the Block).                   Last Modified  Timestamp   T       Date and time (GMT) of the Last Modification to the Block.  The initial value is the Creation Timestamp.                   Disconnect Request Time  Stamp   T       The date and time that the Block disconnect request was made by the NPAC personnel.                   Disconnect Broadcast  Time Stamp   T       The date and time that broadcasting began to all local SMS systems for the disconnect of the Block.                   Disconnect Complete  Time Stamp   T       The date and time that at least one Local SMS system successfully acknowledged the broadcast, for the disconnect of the Block.                   Old Time Stamp   T       The date and time that the Block became old.                   Modify Request  Timestamp   T       The date and time that the Block Modify request was made.                   Modify Broadcast  Timestamp   T       The date and time that broadcasting began to all local SMS systems for the modification of the Block.                   Modify BroadcastComplete Timestamp    T       The date and time that at least one local SMS system successfully acknowledged the broadcast, for the modification of the Block.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-17    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NUMBER POOLING BLOCK HOLDER INFORMATION DATA MODEL                      Attribute Name   Type (Size)   Required   Description         SOA Orgination  Indicator   B   Ö   A Boolean that indicates whether or not the NPA-NXX-X Holder’s SOA initiated the Block over the SOA to NPAC SMS Interface, and whether or not to send notifications to the SOA.               This attribute will be initially set by the NPAC SMS at the time of Block creation.               If originated by SOA, value is TRUE.               If originated by NPAC, value is FALSE.                   Status   E   Ö   Status of the Block.               The initial value is S for Sending.               Valid enumerated values are:               A - Active (1)                S - Sending (3)                F - Failed (4)                PF - Partial Failure (5)                O - Old (7)                   Download Reason   E       The reason the Block is being downloaded to the SOA or LSMS.  Valid values are:               0 – new1               1 – delete1               2 – modified               3 – audit-discrepancy     Table 3-8 Number Pooling Block Holder Information Data Model  NUMBER POOLING BLOCK FAILED SP LIST DATA MODEL                      Attribute Name   Type (Size)   Required   Description         Block ID (Key)    N    Ö    A unique sequential number assigned upon creation of the Block.                   SPID    C(4)    Ö    The Service Provider ID of the discrepant SP.                   SP Name    C(40)    Ö    The NPAC Customer Name of the discrepant SP.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-18    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    Table 3-9 Number Pooling Block Failed SP List Data Model     3.1.4   Network Data    The network data represents the attributes associated with network topology and routing data with respect to local number portability. This information is used by the respective network elements to route ported numbers to the new termination points. The data items that need to be administered by Network Data Administration functions are identified in the tables that follow:  PORTABLE NPA-NXX DATA MODEL                      Attribute Name   Type (Size)   Required   Description         NPA-NXX Id    N    Ö    A unique sequential number assigned upon creation of the NPA-NXX record.                   NPA-NXX    C (6)    Ö    The NPA-NXX open for porting.                   NPAC Customer ID    C (4)    Ö    An alphanumeric code which uniquely identifies an NPAC customer.                   NPA-NXX Effective Date    T    Ö    The date that the NPA-NXX is available for LNP in the NPAC Customer networks.                   Split new NPA    C (6)        The new NPA-NXX for an NPA split.                   Split Activation Date    T        The date that the new NPA-NXX becomes available for use in an NPA split. This date represents the beginning of the permissive dialing period.                   Split Disconnect Date    T        The data that the old NPA-NXX becomes unavailable for use in an NPA split. This date represents the end of the permissive dialing period.                   NPA-NXX has been Ported    T        A timestamp that indicates when the first TN within this NPA-NXX has been ported.     Table 3-10 Portable NPA-NXX Data Model  LRN DATA MODEL                      Attribute Name   Type (Size)   Required   Description         LRN ID    N    Ö    A unique sequential number assigned upon creation of the LRN record.                   LRN    TN    Ö    The LRN is the unique identifier for the switch on which a ported TN or Number Pool Block resides.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-19    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    LRN DATA MODEL                      Attribute Name   Type (Size)   Required   Description         NPAC Customer ID    C (4)    Ö    An alphanumeric code which uniquely identifies an NPAC Customer.     Table 3-11 LRN Data Model  LSMS FILTERED NPA-NXX DATA MODEL                      Attribute Name   Type (Size)   Required   Description         LSMS Filter NPA-NXX ID    N    Ö    A unique sequential number assigned upon creation of the LSMS Filtered NPA-NXX record.                   NPAC Customer ID    C (4)    Ö    An alphanumeric code that uniquely identifies the LSMS NPAC Customer who is filtering subscription version broadcasts.                   NPA-NXX    C (6)    Ö    The NPA-NXX for which the LSMS is filtering subscription version broadcasts.                   Creation Timestamp    T    Ö    Date the filtered NPA-NXX was created.     Table 3-12 LSMS Filtered NPA-NXX Data Model  NUMBER POOLING NPA-NXX-X HOLDER INFORMATION DATA MODEL                      Attribute Name   Type (Size) Required Description         NPA-NXX-X ID    N    Ö    A unique sequential number assigned upon creation of the NPA-NXX-X.                   NPAC Customer ID-    C(4)    Ö    The Service Provider Id of the NPA-NXX-X holder.                   NPA-NXX-X    N(7)    Ö    NPA-NXX-X of the 1K Block.                   NPA-NXX-X Effective Date    T    Ö    The effective date of the 1K Block. The time for this field will be stored in GMT, but equivalent to 00:00:00 network data time CST.                   Creation Time Stamp    T        The date and time (GMT) that this NPA-NXX-X Holder record was created.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-20    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration    NUMBER POOLING NPA-NXX-X HOLDER INFORMATION DATA MODEL                      Attribute Name   Type (Size)   Required   Description         Last Modified Time Stamp    T        The date and time (GMT) of the Last Modification to this NPA-NXX-X Holder record. The default value is the Creation Timestamp.                   Download Reason    E        The reason the NPA-NXX-X is being downloaded to the SOA or LSMS. Valid values are: 0 – new1 1 – delete1 2 – modified 3 – audit-discrepancy                   Alternative SPID    C (4)        An alphanumeric code which uniquely identifies Alternative SPID information (a second service provider – either a facility-based provider or reseller, acting as a non facility-based provider) for this Number Pool Block. This field may only be specified if the service provider SOA supports Alternative SPID.                   Number Pool Block SV Type    E   Ö   Number Pool Block SV Type. Valid enumerated values are:                  • Wireline – (0) • Wireless – (1) • VoIP – (2) • VoWIFI – (3) • SV Type 4– (4) • SV Type 5– (5) • SV Type 6– (6) This field is only required if the service provider supports Number Pool Block SV Type data.     Table 3-13 Number Pooling NPA-NXX-X Holder Information Data Model  3.2 NPAC Personnel Functionality  The following requirements describe the functionality required by the NPAC SMS to support the daily operation of the Regional LNP SMS support staff. These requirements define the high level functionality required by the system with the specifics of each requirement defined in more detail in sections 4 and 5.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-21    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration            R3-3      Create NPA-NXX data for a Service Provider    NPAC SMS shall allow NPAC personnel to create a new LNP NPA-NXX for a Service Provider.          R3-6.2       Mass Update Filter Usage    NPAC SMS shall, for a mass update request, only send updates for subscription versions that are not filtered on the Local SMS.          R3-7.1       Select Subscription Versions mass changes for one or more Subscription Versions    NPAC SMS shall allow NPAC personnel to select Subscription Versions for mass update which match a user defined combination of any of the following: SPID, LNP Type (any single LNP Type or none), TN, TN range (NPA-NXX-xxxx through yyyy, where yyyy is greater than xxxx), LRN, DPC values, SSN values, Billing ID, End User Location Type or End User Location Value, on the NPAC Administrative Interface. (Previously part of B-760 and B-761)  Note: If a single LNP Type is selected, then only that LNP Type will be used, otherwise, if no LNP Type is selected, then no restriction is imposed on the LNP Type as a selection criteria.          R3-7.2       Administer Mass update on one or more selected Subscription Versions    NPAC SMS shall allow NPAC personnel to specify a mass update action to be applied against all Subscription Versions selected (except for Subscription Versions with a status of old, partial failure, sending, disconnect pending or canceled) for LRN, DPC values, SSN values, SV Type, Alternative SPID (if the requesting SOA supports Alternative SPID data), Billing ID, End User Location Type or End User Location Value. (reference NANC 399)          R3-7.3      Mass Update Selection Criteria    NPAC SMS shall require at least one selection criteria to be entered for a mass update.          R3-7.4       Mass Update Service Provider Id    NPAC SMS shall match the Service Provider Id entered as selection criteria with the New or current Service Provider Id in the Subscription Version.          R3-7.5       Mass Update — Creation of Old Subscription Version    DELETED          R3-7.6       Mass Update — Old Subscription Version No Broadcast    DELETED.          R3-7.7       Mass Update Error Processing    NPAC SMS shall log an exception and proceed with Mass Update processing upon finding a subscription version in sending, disconnect pending, or partial failed status.                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-22    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration            R3-7.8      Mass Update Exception Report    NPAC SMS shall produce an exception report for NPAC Personnel when requested that lists the Subscription Versions that were exceptions not processed during Mass Update processing.          RR3-254      Validation of LATA ID Errors on Mass Updates    NPAC SMS shall log an entry to be used for the mass update exception report when any of the LATA ID data edits are violated when mass updating a Subscription Version or Number Pool Block, and continue processing the mass update request. (Previously NANC 319 req 10)  Note: In an example where 2000 SVs are being mass updated and 100 encountered LATA ID edit errors, the NPAC will perform the mass update by updating the 1900 SVs that are valid, and logging the remaining 100 SVs to be picked up on the mass update exception report.          R3-7.9      Mass Update Required Entry of Service Provider ID    NPAC SMS shall require NPAC personnel to specify a Service Provider ID when entering Selection Criteria for a Mass Update.          R3-13      NPAC SMS mass change update capability to the Local SMS    NPAC SMS shall have the capability to identify all Subscription Versions affected by mass changes, (such as NPA splits), and automatically carry out the required updates to modified data in the Local SMSs.          3.2.1       Block Holder, Mass Update            RR3-210       Block Holder Information Mass Update – Update Fields    NPAC SMS shall allow NPAC Personnel, via a mass update, to update the block holder default routing information (LRN, DPC(s), and SSN(s)), SV Type, Alternative SPID (if the requesting SOA supports Alternative SPID data) for a 1K Block as stored in the NPAC SMS. (Previously B-762, reference NANC 399)          RR3-211      Block Holder Information Mass Update – Block Intersection Rejection    NPAC SMS shall reject a mass update request by NPAC Personnel, and issue an error message, if the TN Range and LNP Type of either POOL or none, is entered as Selection Criteria, for the requesting Service Provider, and intersects an existing 1K Block, for that requesting Service Provider, as stored in the NPAC SMS, other than Blocks with a status of old. (Previously B-763)          RR3-212      Block Holder Information Mass Update – Block Status Validation    NPAC SMS shall reject a mass update request to a Block, if the Block’s status is NOT active, or if the Block Failed SP List contains one or more Service Providers. (Previously B-764)                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-23    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration            RR3-213      Block Holder Information Mass Update – Download to EDR Local SMS    NPAC SMS shall download Number Pooling Block Information, for mass updates, using the Number Pooling Block Object, via the NPAC SMS to Local SMS Interface, when the Service Provider’s EDR Indicator is TRUE, at the time of the mass update request. (Previously B-780)          RR3-214      Block Holder Information Mass Update – Download to non-EDR Local SMS    NPAC SMS shall download Number Pooling Block Information, for mass updates, using Subscription Version(s) with LNP Type of POOL, via the NPAC SMS to Local SMS Interface, when the Service Provider’s EDR Indicator is FALSE, at the time of the mass update request. (Previously B-790)          RR3-215      Block Holder Information Mass Update – Download of SVs of Type POOL to non-EDR Local SMS    NPAC SMS shall NOT break up Subscription Versions of LNP Type POOL in a 1K Block, when downloading Number Pooling Block Information, for mass updates, via the NPAC SMS to Local SMS Interface, to non-EDR Local SMSs. (Previously B-800)          RR3-216       Block Holder Information Mass Update — Creation of Old Block    DELETED.          RR3-217       Block Holder Information Mass Update — Old Block No Broadcast    DELETED.          3.2.2       Service Provider ID (SPID) Migration Update    The following section defines how the NPAC SMS supports modification of Service Provider ID on Local Number Portability information. NPAC Personnel generate Selection Input Criteria SPID Migration Update Request Files (SIC-SMURF) that are used by both NPAC and Service Providers to update their databases. The update is performed off-line during a maintenance window. No data is transmitted across the interface.          RR3-255      SPID Migration Update – OpGUI Entry    NPAC SMS shall allow NPAC Personnel, via the NPAC SMS Administrative Interface, to enter selection input criteria (mandatory: migrating away from SPID, migrating to SPID; at least one of the following three: NPA-NXX, LRN, and/or NPA-NXX-X) for a partial SPID Migration Update Request Process. (Previously NANC 323 Req 1)          RR3-256      SPID Migration Update – Generation of SIC-SMURF Files    NPAC SMS shall provide a mechanism that generates SIC-SMURF for NPA-NXX, LRN, and/or NPA-NXX-X upon completion of the entry of the selection input criteria in the NPAC SMS Administrative Interface, for a partial SPID Migration Update Request Process in the NPAC SMS. (Previously NANC 323 Req 2)                      Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-24    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             NPAC Data Administration            RR3-257       SPID Migration Update — NPAC SMS Processing of Requested Data    NPAC SMS shall provide a mechanism to migrate SPID information according to the requested selection input criteria, when changing from one SPID to another SPID in selected NPA-NXX, LRN, and/or NPA-NXX-X data, and subordinate Number Pool Block and Subscription Version data in the NPAC SMS. (Previously NANC 323  Req 3)          RR3-258       SPID Migration Update — Suppression of Notifications    NPAC SMS shall suppress notifications to all Service Providers via the SOA to NPAC SMS Interface and NPAC SMS to LSMS Interface, when performing the partial SPID Migration Update Request Process. (Previously NANC 323 Req 4)          RR3-259       SPID Migration Update — NPAC SMS Processing of Requested Data Based on Status    NPAC SMS shall migrate NPA-NXX, LRN, and/or NPA-NXX-X data, as well as Number Pool Block and Subscription Version data that have ‘active-like’ statuses when performing the partial SPID Migration Update Request Process. (Previously NANC 323 Req 5)  Notes:       •   ‘Active-like’ Blocks or Subscription Versions are defined to be Blocks or Subscription Versions that contain a status of active, sending, partial failure, old with a Failed SP List, or disconnect pending.        •   ‘Pending-like’ Blocks or Subscription Versions are defined to be Blocks or Subscription Versions that contain a status of pending, conflict, cancel-pending, or failed. These will be required to be cleaned-up (activated or cancelled) prior to the execution of the migration process, so that none exist during the migration process.        •   “Old” history data containing a status of cancelled or old with an empty FailedSP-List will NOT be migrated.            RR3-260       SPID Migration Update — SIC-SMURF File Names    NPAC SMS shall follow the SIC-SMURF file naming convention as described in Appendix E. (Previously NANC 323 Req 6)          RR3-261       SPID Migration Update — SIC-SMURF File Formats    NPAC SMS shall follow the SIC-SMURF file format as described in Appendix E. (Previously NANC 323 Req 7)          RR3-262       SPID Migration Update — SIC-SMURF NPA-NXX File Processing — Update NPA-NXX Network Data    NPAC SMS shall use the SIC-SMURF NPA-NXX file to update the SPID associated with NPA-NXXs in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 8)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-25    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-263       SPID Migration Update — SIC-SMURF NPA-NXX File Processing — Update Old SPID on SV Data    NPAC SMS shall use the SIC-SMURF NPA-NXX file to update the old service provider SPID on ‘active-like’ subscription versions when the NPA-NXX code holder SPID is the same as the migrating away from SPID value in the old service provider SPID on the ‘active-like’ subscription version, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 9)  Note: Service Providers need to be aware that if they query the NPAC SMS, historical copies of subscription versions and number pool blocks will still contain the SPIDs they had prior to migration.          RR3-264       SPID Migration Update — SIC-SMURF LRN File Processing — Update LRN Data    NPAC SMS shall use the SIC-SMURF LRN file to update the SPID associated with LRNs in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 10)          RR3-265       SPID Migration Update — SIC-SMURF LRN File Processing — Update Block Data    NPAC SMS shall update the blockholder SPID on Number Pool Blocks associated with the LRN that was updated in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 11)          RR3-266       SPID Migration Update — SIC-SMURF-LRN File Processing — Update SV Data    NPAC SMS shall update the new service provider SPID on subscription versions, regardless of LNP Type, associated with the LRN that was updated in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 12)          RR3-267       SPID Migration Update — SIC-SMURF NPA-NXX-X File Processing — Update NPA-NXX-X    NPAC SMS shall use the SIC-SMURF NPA-NXX-X file to update the SPID associated with NPA-NXX-Xs in the NPAC SMS, from the migrating away from SPID value to the migrating to SPID value, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 13)          RR3-268       SPID Migration Update — Maximum Level of Granularity    NPAC SMS shall perform the partial SPID Migration Update Request Process at a maximum level of granularity of a single SPID. (Previously NANC 323 Req 14)          RR3-269       SPID Migration Update — Minimum Level of Granularity    NPAC SMS shall perform the partial SPID Migration Update Request Process at a minimum level of granularity of an NPA-NXX-X. (Previously NANC 323 Req 15)          RR3-270       SPID Migration Update — Creation of Number Pool Block for Old Service Provider    DELETED                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-26    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-271       SPID Migration Update — Creation of Number Pool Block for Old Service Provider — No Broadcast    DELETED          RR3-272       SPID Migration Update — Creation of Subscription Version for Old Service Provider    DELETED          RR3-273       SPID Migration Update — Creation of Subscription Version for Old Service Provider — No Broadcast    DELETED          RR3-274       SPID Migration Update — Exclusion of Data During Recovery    NPAC SMS shall exclude data in a recovery request for activity related to partial SPID Migration Update Request Process activity. (Previously NANC 323 Req 20)          RR3-275       SPID Migration Update — Rejection for ‘pending-like’ Number Pool Blocks or Subscription Versions    NPAC SMS shall reject a SPID Migration Update Request Process by NPAC Personnel, via the NPAC SMS Administrative Interface, if any “pending-like” Number Pool Blocks or Subscription Versions exist where the migrating away from SPID value is present. (Previously NANC 323 Req 21)  Note: For Number Pool Blocks this will be the Block Holder SPID, and for Subscription Versions this will be either the New SPID or Old SPID.          RR3-276       Update SPID on Messages Queued for Recovery    NPAC SMS shall apply the SPID update to any messages that are in the queue for recovery. (Previously NANC 323 Req 24)          RR3-277       SPID Migration Update — Consistency Check Across Network Data and LRN    NPAC SMS shall perform a consistency check across the selection criteria for NPA-NXX, LRN, and/or NPA-NXX-X, to ensure applicable data belonging to the migrating away from SPID is included in the SMURF files for NPA-NXX, LRN, and/or NPA-NXX-X, and issue an error to NPAC Personnel, during the partial SPID Migration Update Request Process. (Previously NANC 323 Req 25)  Note: The selection criteria of network data and/or LRN will have consistency edits enforced. In the case where all applicable data are NOT in the selection criteria, an error will be issued to the NPAC Personnel. As an example, NPA-NXX of 703-222 is owned by the migrating from SPID, which also uses 703-222-0000 as it’s primary LRN, and has an Number Pool Block of 703-567-2 which uses the 703-222-0000 LRN. When performing the input data for the migration, only one of these are specified as selection criteria, which will cause an error to be issued to the NPAC user. The NPA-NXX, LRN, and NPA-NXX-X must all be specified for the migration process to continue and generate the correct SMURF files.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-27    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    3.3 System Functionality          R3-8       Off-line batch updates for Local SMS Disaster Recovery    NPAC SMS shall support an off-line batch download (via 4mm DAT tape and FTP file download) to mass update Local SMSs with Subscription Versions, NPA-NXX-X Information, Number Pool Block and Service Provider Network data. (reference NANC 399)  The contents of the batch download are:     •   Subscriber data:         -   Version ID        -   TN        -   LRN        -   New Current Service Provider ID        -   Activation Request Timestamp        -   Version Status        -   CLASS DPC        -   CLASS SSN        -   LIDB DPC        -   LIDB SSN        -   ISVM DPC        -   ISVM SSN        -   CNAM DPC        -   CNAM SSN        -   WSMSC DPC (for Local SMSs that support WSMSC data)        -   WSMSC SSN (for Local SMSs that support WSMSC data)        -   End User Location — Value        -   End User Location — Type        -   Billing ID        -   LNP Type        -   Download Reason        -   SV Type (for Local SMSs that support SV Type data)        -   Alternative SPID (for Local SMSs that support Alternative SPID data)       •   Network data:         -   NPAC Customer ID  - NPAC Customer name       •   NPA-NXX-Download Data:         -   NPA-NXX ID        -   NPA-NXX Value        -   NPAC Customer ID        -   Effective TimeStamp        -   Download Reason       •   NPA-NXX-X Data         -   Service Provider ID        -   NPA-NXX-X ID        -   NPA-NXX-X Value        -   Creation Timestamp        -   Effective Timestamp        -   Download Reason       •   Block Data         -   Block ID                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-28    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration         -   NPA-NXX-X        -   LRN        -   New Current Service Provider ID        -   Activation Timestamp        -   CLASS DPC        -   CLASS SSN        -   LIDB DPC        -   LIDB SSN        -   ISVM DPC        -   ISVM SSN        -   CNAM DPC        -   CNAM SSN        -   WSMSC DPC (for Local SMSs that support WSMSC data)        -   WSMSC SSN (for Local SMSs that support WSMSC data)        -   Download Reason        -   Number Pool Block SV Type (for Local SMSs that support SV Type data)        -   Alternative SPID (for Local SMSs that support Alternative SPID data)       •   LRN-Download Data:         -   LRN ID        -   LRN Value        -   Download Reason            R3-9       NPAC SMS download of network data to the Local SMS and SOA    NPAC SMS shall be able to communicate creation or deletion of NPA-NXX data and LRN data for a Service Provider to Local SMSs and SOAs.  The contents of the network download are:     •   Network data:         -   NPAC Customer ID        -   NPAC Customer Name       •   NPA-NXX-Download Data:         -   NPA-NXX ID        -   NPA-NXX Value        -   Effective TimeStamp        -   Download Reason       •   LRN-Download Data:         -   LRN ID        -   LRN Value        -   Download Reason            RR3-66       Number Pool NPA-NXX-X Holder Information — NPAC SMS download of network data to the SOA or Local SMS    NPAC SMS shall be able to communicate creation, modification, or deletion of NPA-NXX-X data for a Service Provider to SOAs or Local SMSs. (Previously N-61)  The contents of the network download are:     •   Network data:         -   NPAC Customer ID        -   NPAC Customer Name       •   NPA-NXX-X Download Data:                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-29    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration         -   NPA-NXX-X ID        -   NPA-NXX-X        -   NPA-NXX-X Effective Date        -   Last Modified TimeStamp        -   Download Reason            RR3-67.1       Number Pool NPA-NXX-X Holder Information — NPAC SMS download via SOA and/or Local SMS Interface of NPA-NXX-X allocation to the Service Providers    NPAC SMS shall inform all Service Providers about the allocation of the NPA-NXX-Xs for pooling to the Block Holder via the SOA to NPAC SMS Interface and/or NPAC SMS to Local SMS interface. The NPA-NXX-X data fields sent via the SOA to NPAC SMS interface and/or NPAC SMS to Local SMS interface are: (Previously N-62.1)     •   NPAC Customer ID      •   NPAC Customer Name      •   NPA-NXX-X ID      •   NPA-NXX-X      •   NPA-NXX-X Effective Date      •   Creation TimeStamp      •   Last Modified TimeStamp      •   Download Reason            R3-10       NPAC SMS notification of NPA-NXX availability to the Service Providers    NPAC SMS shall inform all Service Providers about the availability of the NPA-NXXs for porting via the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces or the Web bulletin board. The NPA-NXX data fields sent via the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces interface are:     •   NPAC Customer ID      •   NPAC Customer Name      •   NPA-NXX ID      •   NPA -NXX Value      •   Effective Date      •   Download Reason    The NPA-NXX data fields sent to the WEB bulletin board are:     •   NPAC Customer ID      •   NPAC Customer Name      •   NPA-NXX Value      •   Effective Date            R3-11       NPAC SMS notification of LRNs and Service Provider data by Service Provider    NPAC SMS shall inform all Service Providers about a new Service Provider and the associated LRNs via the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces. NPAC SMS shall post the new Service Providers and/or new LRNs on the Web bulletin board.  The Service Provider data fields sent to the WEB bulletin board are:     •   NPAC Customer ID      •   NPAC Customer Name      •   NPAC Customer Type                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-30    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration       •   Contact Type      •   Contact Name      •   Contact Address 1      •   Contact Address 2      •   Contact City      •   Contact State      •   Contact Zip      •   Contact Province      •   Contact Country      •   Contact Phone      •   Contact Fax      •   Contact Pager      •   Contact Pager PIN      •   Contact Email    The LRN data fields sent to the WEB bulletin board are:     •   NPAC Customer ID      •   NPAC Customer Name      •   LRN Value            RR3-67.2       Number Pool NPA-NXX-X Holder Information — NPAC SMS download via Web Bulletin Board of NPA-NXX-X allocation to the Service Providers    NPAC SMS shall inform all Service Providers about the allocation of the NPA-NXX-Xs for pooling to the Block Holder via the Web bulletin board. The NPA-NXX-X data fields sent to the WEB bulletin board are: (Previously N-62.2)     •   NPAC Customer ID      •   NPAC Customer Name      •   NPA-NXX-X      •   NPA-NXX-X Effective Date            RR3-278       LATA ID Information Source    NPAC SMS shall obtain LATA ID information from an industry source. (Previously NANC 319 Req 1)          RR3-279       Association of LATA ID with NPA-NXXs    NPAC SMS shall associate a LATA ID with each NPA-NXX used by the NPAC SMS. (Previously NANC 319 Req 2)          RR3-280       Association of LATA ID with LRNs    NPAC SMS shall associate a LATA ID with each LRN used by the NPAC SMS. (Previously NANC 319 req 3)          RR3-439       Validation of LATA ID for NPA-NXX Creates    NPAC shall reject NPA-NXX Create requests if a valid LATA ID reference does not exist in the industry source data.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-31    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-440       Validation of LATA ID for LRN Creates    NPAC shall reject LRN Create requests if a valid LATA ID reference does not exist in the industry source data.    3.4 Additional Requirements          RX3-1.1.1       Service Provider NPA-NXX Data Addition    NPAC SMS shall allow Service Providers to add their NPA-NXX data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface.          RX3-1.1.2       Service Provider NPA-NXX Data Effective Date Validation    NPAC SMS shall allow Service Providers to add their NPA-NXX data with an effective date that is set to a past, present, or future date.          RX3-1.2       Service Provider LRN Data Addition    NPAC SMS shall allow Service Providers to add their LRN data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface.          RX3-3.1       Service Provider NPA-NXX Data Deletion    NPAC SMS shall allow Service Providers to delete their NPA- NXX data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface provided the changes do not cause any updates to the Subscription Versions, Number Pooling NPA-NXX-X or Number Pooling Block Information.          RX3-3.2       Service Provider LRN Data Deletion    NPAC SMS shall allow Service Providers to delete their LRN data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface provided the changes do not cause any updates to the Subscription Versions, or Number Pooling Block Information.          RR3-1       Service Provider Download Indicator    NPAC SMS shall provide a mechanism for the Service Provider to indicate whether or not they want NPA-NXX data and LRN data downloaded to their Local SMS via the NPAC SMS to Local SMS Interface and/or SOA via the SOA to NPAC SMS interface.          RR3-2       Service Provider Download Indicator    NPAC SMS shall download NPA-NXX data and LRN data via the NPAC SMS to Local SMS Interface and/or the SOA to NPAC SMS interface if the indicator is ON.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-32    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            R3-14       Bulk Database Extracts    NPAC SMS shall periodically perform NPAC SMS database extracts of active Subscription Versions on an NPA-NXX basis to an ASCII file.          R3-15       FTP Site for Database Extracts    NPAC SMS shall store database extract files at the NPAC SMS FTP site for Local SMS file retrieval.          R3-16       Database Extract File Creation    NPAC SMS shall allow NPAC personnel to specify database extract file creation on a weekly, monthly, or quarterly basis.          R3-17       Scope of Database Extract File Creation    NPAC SMS shall allow NPAC personnel to specify an NPA-NXX for database extract file creation.          RR3-3       NPAC SMS Input Restrictions    NPAC SMS shall prevent the entry of pipe characters (|) as part of text strings.          RR3-4       Create LRN data for a Service Provider    NPAC SMS shall allow NPAC personnel to create a new LRN for a service provider.          RR3-15       NPAC Clock Synchronization    NPAC SMS shall synchronize its system clock using NTP to a Stratum 1 host.          RR3-474       NPA-NXX Availability — First Usage Effective Date Window — Tunable Parameter    NPAC SMS shall provide a First Usage Effective Date Window tunable parameter, which is defined as the minimum length of time between the current date (exclusive) and the effective date/due date (inclusive), when creating a NPA-NXX-X or Subscription Version for the first time within that NPA-NXX. (previously NANC 394, Req 1)          RR3-475       NPA-NXX Availability — First Usage Effective Date Window — Tunable Parameter Default    NPAC SMS shall default the First Usage Effective Date Window tunable parameter to five (5) business days. (previously NANC 394, Req 2)  Note: The value of five (5) business days is selected because of the first port notification, since this would affect SPs operationally if this value is set to less than five business days.          RR3-476       NPA-NXX Availability — First Usage Effective Date Window — Tunable Parameter Modification    NPAC SMS shall allow NPAC SMS Personnel, via the NPAC Administrative Interface, to modify the NPA-NXX Availability First Usage Effective Date Window tunable parameter. (previously NANC 394, Req 2.5)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-33    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-477       NPA-NXX— Live TimeStamp    NPAC SMS shall calculate an NPA-NXX Live TimeStamp for every NPA-NXX, which is the sum of the First Port Notification Broadcast TimeStamp (or the current system TimeStamp in cases where the first port notification has NOT been sent), plus the First Usage Effective Date Window tunable parameter. (previously NANC 394, Req 3)  Note: This is an internal TimeStamp, and therefore, not represented in the NPA-NXX Data Model.          RR3-478       Region Supports First Usage Effective Date Indicator    NPAC SMS shall provide a Region Supports First Usage Effective Date Indicator, which is defined as an indicator on whether or not First Usage Effective Date Window functionality will be supported by the NPAC SMS for a particular NPAC Region. (previously NANC 394, Req 8)          RR3-479       Region Supports First Usage Effective Date Modification    NPAC SMS shall provide a mechanism for NPAC Personnel to modify the Region Supports First Usage Effective Date Indicator. (previously NANC 394, Req 9)          RR3-480       Region Supports First Usage Effective Date Indicator — Default Value    NPAC SMS shall default the Region Supports First Usage Effective Date Indicator to TRUE. (previously NANC 394, Req 10)  3.4.1     NPA-NXX Data Validations          RR3-441       Valid NPAs for each NPAC Region    NPAC SMS shall establish a list of valid NPAs for each NPAC region using information obtained from an industry source. (previously NANC 321, Req1)          RR3-442       Maintaining List of Valid NPAs for Each NPAC Region    NPAC SMS shall maintain the list of valid NPAs for each NPAC region. (previously NANC 321, Req 2)          RR3-443       Updating List of Valid NPAs for Each NPAC Region    NPAC SMS shall update the list of valid NPAs for each NPAC region using information obtained from an industry source. (previously NANC 321, Req 3)          RR3-444       Rejection of NPA-NXXs that Do Not Belong to a Valid NPA for the NPAC Region    NPAC SMS shall reject a Service Provider request to open an NPA-NXX for portability if the associated NPA is not valid for the region. (previously NANC 321, Req 4)  Note: The 859 (Lexington, KY and surrounding area) exception needs to be correctly processed.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-34    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-445       Regional NPAC NPA Edit Flag Indicator    NPAC SMS shall provide a Regional NPA Edit Flag Indicator, which is defined as an indicator on whether or not NPA edits will be enforced by the NPAC SMS for a particular NPAC Region. (previously NANC 321, Req 5)          RR3-446       Regional NPAC NPA Edit Flag Indicator Modification    NPAC SMS shall provide a mechanism for NPAC Personnel to modify the Regional NPA Edit Flag Indicator. (previously NANC 321 Req 6)          RR3-447       Regional NPAC NPA Edit Flag Indicator — Default Value    NPAC SMS shall default the Regional NPA Edit Flag Indicator to TRUE. (previously NANC 321, Req 7)          RR3-448       Valid NPA-NXXs for 859 KY Exception    NPAC SMS shall establish a list of valid NPA-NXXs for the KY 859 NPA using information obtained from and industry source. (previously NANC 321, Req 8)          RR3-449       Maintaining List of Valid NPA-NXXs for 859 KY Exception    NPAC SMS shall maintain the list of valid NPA-NXXs for the KY 859 NPA. (previously NANC 321, Req 9)          RR3-450       Updating List of Valid NPAs for 859 KY Exception    NPAC SMS shall update the list of valid NPA-NXXs for the KY 859 NPA using information obtained from an industry source. (previously NANC 321, Req 10)          RR3-451       Rejection of NPA-NXXs that Do Not Belong to a Valid NPA for the 859 KY Exception    NPAC SMS shall reject a Service Provider request to open an NPA-NXX for portability if the associated 859-xxx NPA-NXX is not valid for the region as defined below:       •   859-xxx with LATA 922 may only be opened in the Midwest NPAC Region.        •   859-xxx with LATA OTHER THAN 922 may only be opened in the Southeast NPAC Region.    (previously NANC 321, Req 11)    3.5 NPA Splits Requirements  The following section defines NPA Split functionality within the NPAC SMS. The primary means of processing NPA Split information within the NPAC SMS is through automated and regular processing of NPA Split Load Flat Files from industry source data. In the event of an ‘emergency’ there is a manual process by which authorized NPAC personnel may enter required NPA Split information in order to initiate appropriate processing. This manual process is reserved for only ‘back-up or emergency’ situations as deemed by industry and NPAC representatives.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-35    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RN3-1       NPA Split Permissive Dialing    NPAC SMS shall support a permissive dialing period, during which dialing of both NPAs is allowed during NPA splits.          RN3-2       NPA split    NPAC SMS shall accept both the old and new NPAs during the permissive dialing period, but will only respond and download with the new NPA-NXX, except for query requests that span NPAs.          RN3-3       NPA Split Permissive Dialing Cleanup    NPAC SMS shall perform an update to remove NPAC SMS mapping of the old NPA-NXX(s) to the new NPA-NXX(s) for Subscription Versions associated with an NPA split after the expiration date of the permissive dialing period.          RR3-281       NPA Split — Load File from Industry Source Data    NPAC SMS shall allow an NPA Split Load Flat File from an industry source, to be used to enter, modify, or remove NPA Split information into/from the NPAC SMS. (Previously NANC 192 Req 1)  Note: The information from an industry source is assumed to include all necessary updates, including, but not limited to monthly plus emergency updates. (Previously NANC 192 Req 1)          RR3-282       NPA Split — Load File from Industry Source Data During Housekeeping Process    NPAC SMS shall allow the NPA Split Load Flat File to be loaded into the NPA Split information in the NPAC SMS during the current housekeeping process. (Previously NANC 192 Req 2)          RR3-283       NPA Split — Load File from Industry Source Data Processing Results    NPAC SMS shall be capable of storing NPA Split Load Flat File processing data that can be used to generate the NPA Split Load Flat File Exception Report. (Previously NANC 192 Req 3)          RR3-284       NPA Split — Load File from Industry Source Data, Reject existing new NPA-NXX    NPAC SMS shall process the NPA Split Load Flat File and for each new NPA split that is not yet scheduled in the NPAC SMS, reject the request, log an entry to be used for the NPA Split exception report, and continue processing the NPA Split Load Flat File, when the new NPA-NXX already exists in the NPAC SMS and is not already part of an NPA Split. (Previously NANC 192 Req 3.1)          RR3-285       NPA Split — Load File from Industry Source Data, Generate new NPA-NXX    NPAC SMS shall process the NPA Split Load Flat File and for each new NPA split that is not yet scheduled in the NPAC SMS, automatically generate and broadcast the new NPA-NXX, using the PDP start date/time as the value to populate the effective date for the new NPA-NXX. (Previously NANC 192 Req 3.2)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-36    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-286       NPA Split — Load File from Industry Source Data, Delete new NPA-NXX    NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is scheduled in the NPAC SMS and being removed as an NPA Split, automatically delete and broadcast the delete of the new NPA-NXX. (Previously NANC 192 Req 3.3)          RR3-287       NPA Split — NPA Split Load Flat File Exception Report with An Existing New NPA-NXX    NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA split processing errors:       1.   - NPA splits that cannot be added to the NPAC SMS because the new NPA-NXX already exists in the NPAC SMS at the time the NPA Split Load Flat File from an industry source is processed by the NPAC SMS, and that NPA-NXX is NOT already scheduled for an NPA Split in the NPAC SMS.        2.   - NPA splits already scheduled in the NPAC SMS where the PDP start date is modified, and pending SVs exist in the new NPA-NXX. (Previously NANC 192 Req 4)            RR3-288       NPA Split — Load File from Industry Source Data, Verifying Old and New NPA-NXX    NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, verify the old and new NPA-NXXs exist, and generate an error if at least one does not exist. (Previously NANC 192 Req 5)  RR3-289    | NPA Split — Load File from Industry Source Data, Pushing Out PDP Start Date  NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, check for an effective date change in the new NPA-NXX where the PDP start date is pushed out to a further date in the future, and if no pending subscription versions exist in the new NPA-NXX, update both the new NPA-NXX Effective Date and the PDP start date. (Previously NANC 192 Req 6)  Note: The update of the new NPA-NXX effective date will be accomplished via a delete and re-add of the new NPA-NXX. Both of these will be broadcast to all accepting SOAs and LSMSs.          RR3-290       NPA Split — Load File from Industry Source Data, Pulling In PDP Start Date    NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, check for an effective date change in the new NPA-NXX where the PDP start date is pulled in to a closer date, and if no pending subscription versions exist in the new NPA-NXX update both the new NPA-NXX Effective Date and PDP start date. (Previously NANC 192 Req 7)  Note: The update of the new NPA-NXX effective date will be accomplished via a delete and re-add of the new NPA-NXX. Both of these will be broadcast to all accepting SOAs and LSMSs.          RR3-291       NPA Split — Load File from Industry Source Data, Error Modifying PDP Start Date with Existing Subscription Versions    NPAC SMS shall process the NPA Split Load Flat File and for each NPA split that is already scheduled in the NPAC SMS, check for an effective date change in the new NPA-NXX where the PDP start date is modified, and if pending subscription versions exist in the new NPA-NXX, perform no updates to the NPA Split or new NPA-NXX, and log an error. (Previously NANC 192 Req 8)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-37    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-292       NPA Split — Load File from Industry Source Data, Complete Processing of File    NPAC SMS shall process the NPA Split Load Flat File for each NPA split in the file, and shall NOT process any subsequent NPA Split Load Flat Files until the current file has been processed to completion, except in conditions where a subsequent file corrects an error in a previous file. (Previously NANC 192 Req 9)          RR3-293       NPA Split — Load File from Industry Source Data, Re-Processing of File    NPAC SMS shall be capable of re-processing the NPA Split Load Flat File in cases where the file was not completely processed due to NPA split processing errors, except in conditions where a subsequent file corrects an error in a previous file. (Previously NANC 192 Req 10)          RR3-294       NPA Split — Load File from Industry Source Data, Error Modifying PDP Start Date for NPA Split Already in Progress    NPAC SMS shall process the NPA Split Load Flat File for each NPA split in the file, and shall reject a modify PDP start date request, if the beginning of PDP has already passed for that NPA Split. (Previously NANC 192 Req 11)          RR3-295       NPA Split — Load File from Industry Source Data, Adding an NXX to an Existing Split    NPAC SMS shall process the NPA Split Load Flat File and for an NPA split that is already scheduled or in permissive dialing in the NPAC SMS, and an additional NXX is being added to the split, the NPAC SMS shall accept the addition of the NXX to the existing split. (Previously NANC 192 Req 12)  Note: The NPAC SMS will handle the additional split data appropriately (whether adding the NXX to the existing split, or creating a new split for the NPA-NXX), and maintain split data relationships between the existing split (NPA with different NXXs) and this newly added NXX (NPA with this new NXX), such that any subsequent actions on this split data will treat the relationship between all of the existing NPA-NXXs, and this newly added NXX, as part of the same split.          RR3-296       NPA Split — Load File from Industry Source Data Information on the Web    NPAC SMS shall inform all Service Providers about the processing of the NPA Split Load Flat File from industry source data via the Web bulletin board. The data field sent to the WEB bulletin board is the unique identifier for the file that is processed. (Previously NANC 192 Req 13)  Note: The Web will contain the latest full monthly file, plus the most recent incremental file.          AN3-4.1       NPA Split Information Source    The default information source for NPA Split processing shall be the NPA Split Load Flat File, which is processed automatically based on a housekeeping process.          AN3-4.2       NPAC Personnel Manual NPA Split Request    NPAC SMS shall support a mechanism by which NPAC Personnel may manually enter the required information to initiate NPA Split processing.  Note: Manual entry of NPA Split information by NPAC Personnel is available in ‘emergency’ situations as deemed by industry and NPAC representatives. Manual entry of NPA Split information is not the default method for initiating NPA Split processing on the NPAC SMS.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-38    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RN3-4.1       NPA Split — NPA-NXX existence prior to the NPA Split    NPAC SMS shall verify that only the old NPA-NXX(s) involved in an NPA Split exist when NPAC personnel manually enter the split information.  Note: When NPAC Personnel have to manually enter an NPA Split the New NPA-NXX(s) will automatically be broadcast to all accepting SOAs and LSMSs prior to the NPA Split.          RN3-4.2       NPA Split — New NPA-NXX existence prior to the NPA Split — Error    NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that the new NPA-NXX(s) involved in an NPA Split already exist(s) at the time of entry.          RR3-436       NPA Split —Old NPA-NXX non-existence prior to the NPA Split — Error    NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that the old NPA-NXX(s) involved in an NPA Split do(es) not already exist(s) at the time of entry.          RN3-4.3       NPA Split — NPA-NXX Effective Date Validation — DELETED            RR3-437       NPA Split — New NPA-NXX Creation    NPAC SMS shall automatically generate and broadcast the New NPA-NXX using the permissive dial period start date as the value to populate the effective date for the new NPA-NXX upon successful creation of the respective NPA Split information.          RN3-4.4       DELETED            RN3-4.5       DELETED            RN3-4.6       NPA Split — NPA-NXX involved in one NPA Split Validation    NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that a new NPA-NXX involved in an NPA Split is currently involved in another NPA Split.          RR3-297      NPA Split — NPA Split Load Flat File Exception Report with New NPA-NXX Already Involved in NPA Split    NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the new NPA-NXX is currently involved in another NPA Split. (Previously NANC 192 Req 16)          RN3-4.7      NPA Split — No Active Subscription Versions in the new NPA-NXX    NPA SMS shall verify that only pending, old, conflict, canceled, or cancel pending Subscription Versions exist in the new NPA-NXX involved in an NPA Split upon entering split information.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-39    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RN3-4.8       NPA Split — No Active Subscription Versions in the new NPA-NXX — Error    NPA SMS shall report an error and reject the NPA Split upon determining that there are Subscription Versions with a status other than pending, old, conflict, canceled, or cancel pending in the new NPA-NXX involved in an NPA Split.          RN3-4.9       NPA Split — Prevention of NPA-NXX Deletion    NPAC SMS shall prevent an old or new NPA-NXX involved in an NPA split from being deleted from the network data during permissive dialing.          RN3-4.11       NPA Split — No modification of LRN data    NPAC SMS shall leave the LRN information in Subscription Versions involved in the split unchanged during NPA split processing.  Note: The LRN data if necessary will be changed via mass update.          RN3-4.12       NPA Split — Exception Processing for Subscription Versions that exist in the New and Old NPA-NXX    NPAC SMS shall upon finding a subscription version that exists in the new NPA-NXX that currently exists in the old NPA-NXX during NPA split processing shall do the following and continue processing:       •   log an error        •   the Subscription Version in the new NPA-NXX will be moved to old if active or to canceled if it is in any pending state.        •   the Subscription Version in the old NPA-NXX will be modified to the new NPA-NXX.            RN3-4.13       NPA Split — No Modification of Filter Data    NPAC SMS shall leave filters for NPA-NXX(s) involved in an NPA split unchanged.  Note: Service Providers are responsible for setting filters appropriately.          RN3-4.14       NPA Split — Audit Processing    NPAC SMS shall query the LSMS systems for the new NPA-NXX(s) when an audit is run during the NPA split permissive dialing period.  Note: It is the responsibility of the LSMS to recognize and return the new NPA-NXX in the subscription versions returned.          RN3-4.15       NPA Split — Entering of Split Data    The NPAC SMS shall require the following data for manual entry of NPA Split information into the NPAC:       •   the Service Provider Id        •   the old and new NPA        •   the affected NXX(s)        •   the start date of the permissive dialing period        •   the end date of the permissive dialing period                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-40    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RN3-4.16       NPA Split — Modification of End Date of Permissive Dialing Date    NPAC SMS shall allow the modification of the end of permissive dialing during permissive dialing provided the date is not less than the current date.          RR3-438       NPA Split — Modification of Start Date of Permissive Dialing Date    NPAC SMS shall allow the modification of the permissive dial start date provided the modification is made prior to the scheduled permissive dial period start date and is modified to a date that is still prior to the permissive dial period end date.          RN3-4.17       NPA Split — Removal of NPA-NXX during Permissive Dialing    NPAC SMS shall allow the removal of an NPA-NXX during permissive dialing from the NPA Split information as an NPA-NXX involved in the NPA Split.          RN3-4.18       NPA Split — Removal of NPA-NXX during Permissive Dialing — Subscription Version Processing    NPAC SMS shall upon removal of an NPA-NXX during permissive dialing modify the TN of any subscription versions involved in a split existing in the new NPA-NXX to the old NPA-NXX. This processing includes subscription versions that did not previously exist prior to the NPA Split.          RN3-4.19       DELETED            RN3-4.20       NPA Split — Removal of NPA Split Information prior to NPA Split    NPAC SMS shall allow the removal of pending NPA Split information prior to the start of the permissive dialing period.          RN3-4.21       NPA Split — Removal of NPA Split Information after Permissive Dialing Period End Date    NPAC SMS shall log and remove NPA Split Information from the NPAC SMS at the end of the permissive dialing period.          RN3-4.22       NPA Split — No Broadcast of Subscription Version Modification    NPAC SMS shall broadcast no information to the SOA(s) or LSMS(s) about the creation, modification, or deletion of Subscription Versions due to NPA Split processing on the NPAC SMS.  Note: The LSMS and SOA systems are responsible for creating, deleting, or modifying subscription versions due to an NPA Split.          RN3-4.23       NPA Split — Retention of Subscription Version Id    NPAC SMS shall retain the Subscription Version Id of the Subscription Versions involved in an NPA Split.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-41    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RN3-4.24       NPA Split — Update of Subscription Versions at the Beginning of Permissive Dialing    NPAC SMS shall update all Subscription Versions with a status other than old or canceled with the new NPA at the beginning of the Permissive Dialing Period.          RN3-4.25       NPA Split — Old NPA-NXX involved in one NPA Split Validation    NPAC SMS shall verify that the old NPA-NXX(s) involved in an NPA Split are not currently involved in another NPA Split when NPAC personnel manually enter the NPA split information or the NPA Split Load Flat File is processed.          RN3-4.26       NPA Split — Old NPA-NXX involved in one NPA Split Validation — Error    NPAC SMS shall report an error to NPAC personnel and reject the manual NPA Split request upon determining that an old NPA-NXX involved in an NPA Split is currently involved in another NPA Split.          RR3-298       NPA Split — NPA Split Load Flat File Exception Report with Old NPA-NXX Already Involved in NPA Split    NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the old NPA-NXX is currently involved in another NPA Split. (Previously NANC 192 Req 17)          RN3-4.27       NPA Split — Validation of the Permissive Dialing Period    NPAC SMS shall verify that the end date of permissive dialing is greater than the start date except in cases where there is no permissive dialing period.          RN3-4.28       NPA Split — Old NPA-NXX and New NPA-NXX Ownership Validation    NPAC SMS shall verify that the owner of the old NPA-NXX matches the owner of the new NPA-NXX for each NXX in a NPA split.          RN3-4.29       NPA Split — Old NPA-NXX and New NPA-NXX Ownership Validation — Error — DELETED            RR3-299       NPA Split — NPA Split Load Flat File Exception Report with Mismatched SPIDs for Old and New NPA-NXX    NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the owner of the old NPA-NXX does not match the owner of the new NPA-NXX. (Previously NANC 192 Req 18)          RN3-4.30       NPA Split — Creation of a Subscription Version during the Permissive Dialing Period    NPAC SMS shall change the old NPA-NXX to the new NPA-NXX when a Subscription Version is created with the old NPA-NXX during the permissive dialing period.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-42    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RN3-4.31       NPA Split Current and Pending NPA Split Report    NPAC SMS shall support a Current and Pending NPA Split Report for NPA Splits before or during their permissive dialing period that contains all split data as defined in RN3-4.15.  RN3-4.32     NPA Split — NPA Split History Report  NPAC SMS shall support a NPA Split History Report for completed NPA Splits that contains all split data as defined in RN3-4.15.          RN3-4.33       DELETED            RN3-4.34       DELETED            RN3-4.35       DELETED            RN3-4.36       NPA Split -Creation of Old Subscription Version    DELETED          RN3-4.37       NPA Split — Old Subscription Version No Broadcast    DELETED          RR3-219       NPA Splits — Deletion of Old NPA-NXX at the end of permissive dialing    NPAC SMS shall automatically delete the old NPA-NXX from the Portable NPA-NXX Information in the NPAC, upon reaching the end of the permissive dialing period for the old NPA-NXX involved in an NPA Split.  3.5.1 NPA-NXX-X, NPA Splits          RR3-31       NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split Automatic Create of New NPA-NXX-X    NPAC SMS shall automatically create a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, when a valid request is made to add an NPA Split, if the old NPA-NXX-X exists, but the new NPA-NXX-X does NOT exist in the Number Pooling NPA-NXX-X Information. (Previously N-300)          RR3-32       NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split Error Message if New NPA-NXX-X Already Exists    NPAC SMS shall reject the request and generate an error message when a request is made to add an NPA Split, and the new NPA-NXX-X already exists in the Number Pooling NPA-NXX-X Information. (Previously N-301)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-43    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-300       NPA Split — NPA Split Load Flat File Exception Report with Already Existing New NPA-NXX-X    NPAC SMS shall provide an NPA Split Load Flat File Exception Report that identifies NPA splits that cannot be added to the NPAC SMS because the new NPA-NXX-X already exists in the Number Pooling NPA-NXX-X Information. (Previously NANC 192 Req 19)          RR3-33       NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split Field Values for Automatic Add of New NPA-NXX-X    NPAC SMS shall populate the fields for the automatically generated new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, when a request is made to add an NPA Split or an old NPA-NXX-X is created during a split, as follows: (Previously N-302)       •   NPA-NXX-X ID — value automatically generated by NPAC.        •   NPA-NXX-X Holder SPID — value set to old NPA-NXX-X.        •   NPA-NXX-X — value set to the new NPA-NXX, plus the seventh digit of the old NPA-NXX-X.        •   Effective Date — value set to the latest of, the same field in old NPA-NXX-X, or the start of PDP.        •   Creation Date — value set to current date/time.        •   Last Modified Date — value set to current date/time.        •   Download Reason — value set to “new1”.            RR3-34       NPA Splits and the Number Pool NPA-NXX-X Information — New NPA Split, Skip Block and Subscription Version Create    NPAC SMS shall NOT schedule the Creation of a Block and Subscription Versions with LNP Type of POOL, for an NPA-NXX-X that is automatically generated by the NPAC SMS in the Number Pooling NPA-NXX-X Information, as a result of a request to add an NPA Split. (Previously N-303)  Note: The Block and SVs will be created at PDP Start based on Block and SV split requirements.          RR3-35       NPA Splits and the Number Pool NPA-NXX-X Information — NXX Removal from NPA Split prior to the end of PDP    NPAC SMS shall upon the removal of an NPA-NXX from an NPA Split prior to the end of permissive dialing, remove the new NPA-NXX-X from the NPA-NXX-X Information. (Previously N-310)          RR3-36.1       NPA Splits and the Number Pool NPA-NXX-X Information — Addition of an NPA-NXX-X scheduled for an NPA Split    NPAC SMS shall, upon entry of an old NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically add an entry for the new NPA-NXX-X for an NPA-NXX scheduled for an NPA Split. (Previously N-320.1)          RR3-36.2       NPA Splits and the Number Pool NPA-NXX-X Information — New Addition of an NPA-NXX-X scheduled for an NPA Split With an Error Message    NPAC SMS shall reject the request and generate an error message to the NPAC Personnel when a request is made to add a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, and the NPA-NXX is scheduled for an NPA Split. (Previously N-320.2)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-44    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-36.3       NPA Splits and the Number Pool NPA-NXX-X Information — Addition of an NPA-NXX-X currently in Permissive Dialing in an NPA Split    NPAC SMS shall, upon entry of an NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically add an entry for the new/old NPA-NXX-X for an NPA-NXX currently in Permissive Dialing in an NPA Split. (Previously N-320.3)  Note: Therefore, if entering the new NPA-NXX-X, then the old NPA-NXX-X will be automatically added; and if entering the old NPA-NXX-X, then the new NPA-NXX-X will be automatically added.  RR3-37.1     NPA Splits and the Number Pool NPA-NXX-X Information — Modification of an NPA-NXX-X scheduled for an NPA Split  NPAC SMS shall, upon modification of an old NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically modify the corresponding entry for the new NPA-NXX-X for an NPA-NXX scheduled for an NPA Split, if the new Effective Date is Greater Than or Equal To the start of the Permissive Dialing Period. If the modified Effective Date value is Less Than the start of the Permissive Dialing Period, then the new NPA-NXX-X’s Effective Date is Equal To the start of the Permissive Dialing Period. (Previously N-321.1)          RR3-37.2       NPA Splits and the Number Pool NPA-NXX-X Information — New Modification of an NPA-NXX-X scheduled for an NPA Split With an Error Message    NPAC SMS shall reject the request and generate an error message to the NPAC Personnel when a request is made to modify a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, and the NPA-NXX is scheduled for an NPA Split. (Previously N-321.2)          RR3-37.3       NPA Splits and the Number Pool NPA-NXX-X Information — Modification of an NPA-NXX-X involved in an NPA Split    NPAC SMS shall, upon modification of an NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically modify the old/new NPA-NXX-X for an NPA-NXX currently in Permissive Dialing in an NPA Split.  Note: Therefore, if modifying the new NPA-NXX-X, then the old NPA-NXX-X will be automatically modified; and if modifying the old NPA-NXX-X, then the new NPA-NXX-X will be automatically modified. (Previously N-321.3)          RR3-38.1       NPA Splits and the Number Pool NPA-NXX-X Information — Deletion of an NPA-NXX-X involved in an NPA Split    NPAC SMS shall, upon de-pooling of an old NPA-NXX-X in the Number Pooling NPA-NXX-X Information, prior to the start of the Permissive Dialing Period, automatically de-pool the corresponding entry for the new NPA-NXX-X for an NPA-NXX scheduled for an NPA Split, at the time the requested NPA-NXX-X is de-pooled. (Previously N-322.1)          RR3-38.2       NPA Splits and the Number Pool NPA-NXX-X Information — New Deletion of an NPA-NXX-X scheduled for an NPA Split With an Error Message    NPAC SMS shall reject the request and generate an error message to the NPAC Personnel when a request is made to de-pool a new NPA-NXX-X in the Number Pooling NPA-NXX-X Information, and the NPA-NXX is scheduled for an NPA Split. (Previously N-322.2)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-45    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-38.3       NPA Splits and the Number Pool NPA-NXX-X Information — Deletion of an NPA-NXX-X involved in an NPA Split    NPAC SMS shall, upon de-pool of an NPA-NXX-X in the Number Pooling NPA-NXX-X Information, automatically de-pool the old/new NPA-NXX-X for an NPA-NXX currently in Permissive Dialing in an NPA Split, at the time the requested NPA-NXX-X is de-pooled.  Note: Therefore, if de-pooling the new NPA-NXX-X, then the old NPA-NXX-X will be automatically de-pooled; and if de-pooling the old NPA-NXX-X, then the new NPA-NXX-X will be automatically de-pooled. (Previously N-322.3)          RR3-39       NPA Splits and the Number Pool NPA-NXX-X Information — Broadcast of Addition or Deletion of NPA-NXX-X Split Data    NPAC SMS shall broadcast NPA-NXX-X data defined in RR3-31, RR3-35, RR3-36.1, RR3-36.3, RR3-37.1, RR3-37.3, RR3-38.1, and RR3-38.3, that is added or deleted for an NPA Split; this broadcast shall occur as defined in requirements RR3-66, RR3-67.1, RR3-67.2, RR3-68, RR3-69, RR3-70, RR3-71, RR3-72 and RR3-73. (Previously N-325)          RR3-40       NPA Splits and the Number Pool NPA-NXX-X Information — Deletion of Old NPA-NXX-X at the end of permissive dialing    NPAC SMS shall automatically delete the old NPA-NXX-X from the Number Pooling NPA-NXX-X Information, upon reaching the end of the permissive dialing period for the old NPA-NXX of the NPA-NXX-X. (Previously N-326)  3.5.2 Block Holder, NPA Splits          RR3-41       NPA Splits and the Number Pooling Block Holder Information — Recognition of Both Old NPA and New NPA    NPAC SMS shall upon the start of permissive dialing for an NPA Split, convert the old NPA-NXX to the new NPA-NXX in the Number Pooling Block Information. (Previously B-490)          RR3-42       NPA Splits and the Number Pooling Block Holder Information — NXX Removal from Split    NPAC SMS shall upon the removal of an NPA-NXX from an NPA Split, after the start of permissive dialing, reinstate the original NPA for the NXX-X in the Block Holder Information. (Previously B-500)          RR3-43       NPA Splits and the Number Pool Block Holder Information — Addition of a Block involved in an NPA Split    NPAC SMS shall convert the old NPA-NXX to the new NPA-NXX for a Block involved in an NPA Split upon creation in the Number Pooling Block Holder Information, if the old NPA-NXX is currently in permissive dialing. (Previously B-510)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-46    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-44       NPA Splits and the Number Pool Block Holder Information — Addition of a Block for an NPA-NXX involved in an NPA Split    NPAC SMS shall accept a Block create request from NPAC personnel, Service Provider via the SOA to NPAC SMS Interface or Service Provider via the NPAC SOA Low-tech Interface, with either the old NPA-NXX or the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-520)          RR3-45       NPA Splits and the Number Pool Block Holder Information — Broadcast of a Block Create for an NPA-NXX involved in an NPA Split    NPAC SMS shall broadcast a Block create to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, by sending a Block using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-530)          RR3-46       NPA Splits and the Number Pool Block Holder Information — Modification of a Block for an NPA-NXX involved in an NPA Split    NPAC SMS shall accept a Block modify active request from NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, with either the old NPA-NXX or the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-540)          RR3-47       NPA Splits and the Number Pool Block Holder Information — Broadcast of a Block Modify Active for an NPA-NXX involved in an NPA Split    NPAC SMS shall broadcast a Block modify active to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, by sending a Block using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-550)          RR3-48       NPA Splits and the Number Pool Block Holder Information — De-pooling of the Block during PDP    NPAC SMS shall broadcast a Block delete request to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, by sending a Block using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-551)          RR3-49       NPA Splits and the Number Pool Block Holder Information — Mass Update that includes one or more Blocks for an NPA-NXX involved in an NPA Split    NPAC SMS shall accept a mass update request from NPAC personnel that spans one or more Blocks that are part of an NPA Split that is currently in permissive dialing only when the new NPA-NXX is used.          RR3-50       NPA Splits and the Number Pool Block Holder Information — Broadcast of a Mass Update that includes one or more Blocks for an NPA-NXX involved in an NPA Split    NPAC SMS shall broadcast a mass update that could span one or more Blocks to an EDR Local SMS, via the NPAC SMS to Local SMS Interface, using the new NPA-NXX for an NPA-NXX that is currently in permissive dialing. (Previously B-553)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-47    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-51.1       NPA Splits and the Number Pool Block Holder Information — Creation of Old Block    DELETED          RR3-51.2       NPA Splits and the Number Pool Block Holder Information — Old Block No Broadcast    DELETED          RR3-218       NPA Splits and the Number Pool Block Holder Information — Broadcast of Subscription Versions for an NPA-NXX involved in an NPA Split    NPAC SMS shall broadcast the Subscription Versions with LNP Type of POOL using the new NPA-NXX, for an addition, modification, deletion, re-send, resync, or mass update, to a non-EDR Local SMS, via the NPAC SMS to Local SMS Interface, for an NPA-NXX that is currently in permissive dialing. (Previously SV-430)    3.6 NPA-NXX Filter Management Requirements          RR3-5       Create Filtered NPA-NXX for a Local SMS    NPAC SMS shall allow a Service Provider to create a filtered NPA-NXX for a given Local SMS, via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface, which results in the SMS NOT broadcasting NPA-NXX information, subscription versions, NPA-NXX-X information or Number Pool Blocks with the filtered NPA-NXX to the Local SMS.          RR3-6       Delete Filtered NPA-NXX for a Local SMS    NPAC SMS shall allow a Service Provider to delete a filtered NPA-NXX for a given Local SMS, via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface, which results in the SMS broadcasting NPA-NXX information, subscription versions, NPA-NXX-X information and Number Pool Blocks with the filtered NPA-NXX to the given Local SMS.          RR3-7       Query Filtered NPA-NXXs for a Local SMS    NPAC SMS shall allow a Service Provider to query filtered NPA-NXXs for a given Local SMS via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface.          RR3-8       Query Filtered NPA-NXXs — NPA-NXX Not Provided    NPAC SMS shall return to the requesting Service Provider all filtered NPA-NXXs for a given Local SMS when the NPA-NXX is NOT input upon a Filter NPA-NXX Query via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface.          RR3-9       Query Filtered NPA-NXXs — NPA-NXX Provided    NPAC SMS shall return to the requesting Service Provider a single NPA-NXX for a given Local SMS when the NPA-NXX is input upon a filtered NPA-NXX Query via the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-48    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    3.7 Business Hour and Days Requirements          RR3-10       Business Hours and Days    NPAC SMS shall support definition and processing of long and short business hours and days for operations involving business time calculation.  RR3-11  DELETED  RR3-30  DELETED          RR3-229       Short Business Days Tunable Parameter    NPAC SMS shall provide a Short Business Days tunable parameter that defines the days of the week that are valid for operations involving business time calculation excluding NPAC operations-defined holidays. (Formerly NANC 328 Req 5)          RR3-230       Short Business Days Tunable Parameter — Default Value    NPAC SMS shall default the Short Business Days tunable parameter to Monday through Friday. (Formerly NANC 328 Req 6)          RR3-231       Short Business Days Tunable Parameter — Valid Values    NPAC SMS shall use days of the week as valid values for the Short Business Days tunable parameter. (Formerly NANC 328 Req 7)          RR3-232       Short Business Days Tunable Parameter — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface to modify the Short Business Days Tunable Parameter. (Formerly NANC 328 Req 8)          RR3-233       Long Business Days Tunable Parameter    NPAC SMS shall provide a Long Business Days tunable parameter that defines the days of the week that are valid for operations involving business time calculation excluding NPAC operations-defined holidays. (Formerly NANC 328 Req 1)          RR3-234       Long Business Days Tunable Parameter — Default Value    NPAC SMS shall default the Long Business Days tunable parameter to Sunday through Saturday. (Formerly NANC 328 Req 2)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-49    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-235       Long Business Days Tunable Parameter — Valid Values    NPAC SMS shall use days of the week as valid values for the Long Business Days tunable parameter. (Formerly NANC 328 Req 3)          RR3-236       Long Business Days Tunable Parameter — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Long Business Days Tunable Parameter. (Formerly NANC 328 Req 4)          RR3-12.1       Business Day Duration — Tunable Parameter    NPAC SMS shall provide long and short Business Day Duration tunable parameters, which are defined as the number of hours from the tunable business day start time.          RR3-12.2       Business Day Duration — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Business Day Duration tunable parameters.          RR3-12.3       Short Business Day Duration — Tunable Parameter Default    NPAC SMS shall default the short Business Day Duration tunable parameter to 12 hours.          RR3-12.4       Long Business Day Duration — Tunable Parameter Default    NPAC SMS shall default the long Business Day Duration tunable parameter to 12 hours.          RR3-13.1       Business Day Start Time — Tunable Parameter    NPAC SMS shall provide long and short Business Day Start Time tunable parameters, which are defined as the start of the business day in local time of the predominant time zone within the region (stored in UTC).          RR3-13.2       Business Day Start Time — Tunable Parameter Modification    NPAC SMS shall set the long and short Business Day Start Time tunable parameters to the value specified by the contracting region.          RR3-13.3       Short Business Day Start Time — Tunable Parameter Default    NPAC SMS shall default the short Business Day Start Time tunable parameter to 13:00/12:00 UTC (adjusted for Standard/Daylight time changes).          RR3-13.4       Long Business Day Start Time — Tunable Parameter Default    NPAC SMS shall default the long Business Day Start Time tunable parameter to 9:00 AM local time of the predominant time zone within the region, stored in UTC and adjusted for Standard/Daylight time changes.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-50    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-14       Business Holidays    NPAC SMS shall allow NPAC operations personnel to add/delete business holidays.  3.8 Notifications  3.8.1     TN Range Notification Indicator          RR3-237       NPAC Customer TN Range Notification Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving TN Range Notifications via the SOA to NPAC SMS Interface. (Formerly NANC 179 Req 1)          RR3-238       NPAC Customer TN Range Notification Indicator — Default    NPAC SMS shall default the TN Range Notification Indicator to FALSE. (Formerly NANC 179 Req 2)          RR3-239       NPAC Customer TN Range Notification Indicator — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the TN Range Notification Indicator on the NPAC Customer record. (Formerly NANC 179 Req 3)          3.8.2       Customer No New SP Concurrence Notification Indicator            RR3-240       NPAC Customer No New SP Concurrence Notification Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports the Final Create Window Expiration Notification for a Subscription Version upon the expiration of the New Service Provider Final Create Window. (Formerly NANC 240 Req 3)          RR3-241       NPAC Customer No New SP Concurrence Notification Indicator — Default    NPAC SMS shall default the No New SP Concurrence Notification Indicator to FALSE. (Formerly NANC 240 Req 4)          RR3-242       NPAC Customer No New SP Concurrence Notification Indicator — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the No New SP Concurrence Notification Indicator on the NPAC Customer record. (Formerly NANC 240 Req 5)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-51    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-243       Subscription Version Information — Suppress Notification when Service Provider No New SP Concurrence Notification Indicator is False    NPAC SMS shall suppress the Final Create Window Expiration Notification, if the Service Provider’s No New SP Concurrence Notification Indicator is FALSE. (Formerly NANC 240 Req 6)          RR3-244       Subscription Version Information — Send Notification when Service Provider No New SP Concurrence Notification Indicator is True    NPAC SMS shall send the Final Create Window Expiration Notification, if the Service Provider’s No New SP Concurrence Notification Indicator is TRUE. (Formerly NANC 240 Req 7)  3.8.3   SOA Notification Priority          RR3-245       SOA Notification Priority Tunable Parameter    NPAC SMS shall provide a SOA Notification Priority tunable parameter for each SOA notification that defines the priority of the SOA notification for the given region. (Formerly NANC 329 Req 1)          RR3-246       SOA Notification Priority Based on Attributes    NPAC SMS shall allow SOA Notifications to have separate priorities associated with the value of certain attributes based on the information contained in Appendix C, Table C-7 — SOA Notification Priority Tunables. (Formerly NANC 329 Req 2)  Note: The table referenced above is new and is appended to this document.          RR3-247       SOA Notification Priority Tunable Parameter based on Old or New Service Provider Status    NPAC SMS shall allow different SOA Notification Priority values for Status Attribute Value Change notifications based on whether the Service Provider is acting as the Old Service Provider or as New Service Provider for the port as indicated in Appendix C, Table C-7 — SOA Notification Priority Tunables. (Formerly NANC 329 Req 6)          RR3-248       SOA Notification Priority Tunable Parameter — Valid Values    NPAC SMS shall use HIGH, MEDIUM, LOW, and NONE as valid values for the SOA Notification Priority tunable parameters. (Formerly NANC 329 Req 3)          RR3-249       SOA Notification Priority Tunable Parameter — Default Value    NPAC SMS shall default the SOA Notification Priority tunable parameter values to MEDIUM. (Formerly NANC 329 Req 4)          RR3-250       Modifying the SOA Notification Priority Tunable Parameter Value    NPAC SMS shall allow NPAC Personnel to modify the SOA Notification Priority tunable parameter values based on Service Provider requests. (Formerly NANC 329 Req 5)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-52    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-251       SOA Notification Priority Processing    NPAC SMS shall send HIGH priority messages prior to sending MEDIUM priority messages and MEDIUM priority messages prior to LOW priority messages. (Formerly NANC 329 Req 3.5)          RR3-252       SOA Notification Priority Tunable Parameter —Value Equal to NONE    NPAC SMS shall use the SOA Notification Priority tunable parameter equal to NONE to indicate that the notification is not generated for that Service Provider. (Formerly NANC 329 Req 7)          RR3-253       Processing of SOA Notification Queues    NPAC SMS shall send SOA notifications to a Service Provider based on the SOA notification priority and ‘first in, first out’ within the priority. (Formerly NANC 329 Req 8)  3.8.4 TN and Number Pool Block in Notifications          RR3-452       Subscription Version Status Attribute Value Change — Send TN    NPAC SMS shall, based on the Subscription Version TN Attribute Flag Indicator, send the Subscription Version TN when sending a Subscription Version Status Attribute Value Change notification. (previously NANC 151, Req 1)          RR3-453       Subscription Version Attribute Value Change — Send TN    NPAC SMS shall, based on the Subscription Version TN Attribute Flag Indicator, send the Subscription Version TN when sending a Subscription Version Attribute Value Change notification. (previously NANC 151, Req 2)          RR3-454       Number Pool Block Status Attribute Value Change — Send NPA-NXX-X    NPAC SMS shall, based on the Number Pool Block NPA-NXX-X Attribute Flag Indicator, send the Number Pool Block NPA-NXX-X when sending a Number Pool Block Status Attribute Value Change notification. (previously NANC 151, Req 3)          RR3-455       Number Pool Block Attribute Value Change — Send NPA-NXX-X    NPAC SMS shall, based on the Number Pool Block NPA-NXX-X Attribute Flag Indicator, send the Number Pool Block NPA-NXX-X when sending a Number Pool Block Attribute Value Change notification. (previously NANC 151, Req 4)          RR3-456       Subscription Version TN Attribute Flag Indicator    NPAC SMS shall provide a Subscription Version TN Attribute Flag Indicator, which is defined as an indicator on whether or not the Service Provider supports receipt of the Subscription Version TN attribute in a Subscription Version Status Attribute Value Change or Attribute Value Change notification. (previously NANC 151, Req 5)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-53    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-457       Modification of Subscription Version TN Attribute Flag Indicator    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the Subscription Version TN Attribute Flag Indicator. (previously NANC 151, Req 6)          RR3-458       Subscription Version TN Attribute Flag Indicator Default Value    NPAC SMS shall default the Subscription Version TN Attribute Flag Indicator to FALSE. (previously NANC 151, Req 7)          RR3-459       Number Pool Block NPA-NXX-X Attribute Flag Indicator    NPAC SMS shall provide a Number Pool Block NPA-NXX-X Attribute Flag Indicator, which is defined as an indicator on whether or not the Service Provider supports receipt of the Number Pool Block NPA-NXX-X attribute in a Number Pool Block Status Attribute Value Change or Attribute Value Change notification. (previously NANC 151, Req 8)          RR3-460       Modification of Number Pool Block NPA-NXX-X Attribute Flag Indicator    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the Number Pool Block NPA-NXX-X Attribute Flag Indicator. (previously NANC 151, Req 9)          RR3-461       Number Pool Block NPA-NXX-X Attribute Flag Indicator Default Value    NPAC SMS shall default the Number Pool Block NPA-NXX-X Attribute flag Indicator to FALSE. (previously NANC 151, Req 10)  3.8.5 SV Type and Alternative SPID Indicators  The following section of requirements defines service provider tunable features that indicate if a service provider system supports optional data functionality defined as part of NANC 399. Until NAPM LLC approval, this functionality remains inactive in the NPAC SMS.          RR3-484       Service Provider SOA SV Type Edit Flag Indicator    NPAC SMS shall provide a Service Provider SOA SV Type Edit Flag Indicator tunable parameter which defines whether a SOA supports SV Type. (previously NANC 399, Req 1)          RR3-485       Service Provider SOA SV Type Edit Flag Indicator Default    NPAC SMS shall default the Service Provider SOA SV Type Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 2)          RR3-486       Service Provider SOA SV Type Edit Flag Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SV Type Edit Flag Indicator tunable parameter. (previously NANC 399, Req 3)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-54    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-487       Service Provider LSMS SV Type Edit Flag Indicator    NPAC SMS shall provide a Service Provider LSMS SV Type Edit Flag Indicator tunable parameter which defines whether an LSMS supports SV Type. (previously NANC 399, Req 4)          RR3-488       Service Provider LSMS SV Type Edit Flag Indicator Default    NPAC SMS shall default the Service Provider LSMS SV Type Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 5)          RR3-489       Service Provider LSMS SV Type Edit Flag Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SV Type Edit Flag Indicator tunable parameter. (previously NANC 399, Req 6)          RR3-490       Service Provider SOA Alternative SPID Edit Flag Indicator    NPAC SMS shall provide a Service Provider SOA Alternative SPID Edit Flag Indicator tunable parameter which defines whether a SOA supports Alternative SPID. (previously NANC 399, Req 7)          RR3-491       Service Provider SOA Alternative SPID Edit Flag Indicator Default    NPAC SMS shall default the Service Provider SOA Alternative SPID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 8)          RR3-492       Service Provider SOA Alternative SPID Edit Flag Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Alternative SPID Edit Flag Indicator tunable parameter. (previously NANC 399, Req 9)          RR3-493       Service Provider LSMS Alternative SPID Edit Flag Indicator    NPAC SMS shall provide a Service Provider LSMS Alternative SPID Edit Flag Indicator tunable parameter which defines whether an LSMS supports Alternative SPID. (previously NANC 399, Req 10)          RR3-494       Service Provider LSMS Alternative SPID Edit Flag Indicator Default    NPAC SMS shall default the Service Provider LSMS Alternative SPID Edit Flag Indicator tunable parameter to FALSE. (previously NANC 399, Req 11)          RR3-495       Service Provider LSMS Alternative SPID Edit Flag Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Alternative SPID Edit Flag Indicator tunable parameter. (previously NANC 399, Req 12)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-55    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    3.9 Multiple Service Provider Ids Per SOA Association Requirements          RR3-16       Addition of NPAC Customer Associated Service Provider Information    NPAC SMS shall allow NPAC personnel to store a primary service provider id with the associated service provider id that it will service.          RR3-17       Deletion of NPAC Customer Associated Service Provider Information    NPAC SMS shall allow NPAC personnel to delete an associated service provider id that is serviced by a primary service provider id.          RR3-18       NPAC Customer Associated Service Provider Information — SPID validation    NPAC SMS shall validate that the primary and associated service provider ids specified in the NPAC Customer Associated Service Provider Information are valid service provider ids defined in the NPAC SMS.          RR3-19       NPAC Customer Associated Service Provider Information — Associated SPID    NPAC SMS shall validate that the associated service provider id is not already specified as a primary or associated service provider id in the NPAC Customer Associated Service Provider Information.          A3-5       Associated Service Provider Multiple Service Provider Ids    Associated service providers using services from another primary service provider’s SOA must use another service provider id if they choose to interact with the NPAC independently from the primary service provider.          RR3-20       NPAC Customer Associated Service Provider Information — Validation Error    NPAC SMS shall report an error to the user and reject the addition of NPAC Customer Associated Service Provider Information if validation errors occur.          RR3-21       NPAC Deletion of Service Provider Validation    NPAC SMS shall prevent a service provider from being deleted in the NPAC SMS if it exists in the NPAC Customer Associated Service Provider Information as a primary or associated service provider id.          RR3-22       Association Rejection for Associated Service Provider Id    NPAC SMS shall reject any SOA to NPAC SMS association attempt by a Service Provider Id that is a service provider associated with the primary Service Provider Id in the NPAC Customer Associated Service Provider Information.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-56    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-23       Associated Service Provider Id Use over a Primary Service Provider Id Association    NPAC SMS shall support the specification of an associated service provider id in the access control field over a SOA to NPAC SMS association for the primary service provider provided the associated service provider id is defined in the NPAC Associated Service Provider Information for the primary service provider id.          RR3-24       Validation of Old and New/Current for Associated Service Provider Id    NPAC SMS shall validate the old and new/current service provider id for a message sent over the SOA to NPAC SMS association for the primary association as is done today using the service provider id specified in the access control for the message.          RR3-25       Use of Primary Service Provider Key List    NPAC SMS shall accept and send keys from the key lists associated with the primary service provider for all SOA to NPAC SMS messages sent over the association for the primary service provider.          RR3-26       Notifications for Associated Service Providers    NPAC SMS shall send all SOA notifications for an associated Service Provider over the SOA to NPAC SMS interface association for the primary service provider.          C3-1       Associated Service Provider Notification Aggregation    NPAC SMS aggregation of all messages over the SOA to NPAC SMS interface for primary and associated service provider ids will not be supported by the NPAC SMS.          RR3-27       Filters for Associated Service Providers    NPAC SMS shall apply NPA-NXX filters for the associated Service Provider Id before sending them over the SOA to NPAC SMS interface association for the primary service provider.          RR3-28       Associated Service Provider and Primary Service Provider messages    NPAC SMS shall support messages containing primary and associated service provider ids that are interleaved over the SOA to NPAC SMS interface association for the primary service provider.          RR3-29       Recovery for an Associated Service Provider    NPAC SMS shall support the recovery of network data or notifications for an associated Service Provider over a SOA to NPAC SMS association in recovery mode for a primary service provider.  Note: Recovery of information for associated service providers is the responsibility of the primary service provider. The primary service provider must establish an association in recovery mode, send the recovery actions for each service provider id, primary and associated, and then as the primary SPID indicate recovery is complete.                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-57    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    3.10 Bulk Data Download Functionality  This section describes Bulk Data Download functionality supported by the NPAC SMS. The NPAC can generate files for Network Data (including SPID, LRN, NPA-NXX and NPA-NXX-X), and Subscription Versions (including Number Pool Blocks). The NPAC SMS also has the ability to process Bulk Data Download Response files from Service Providers.  3.10.1 Bulk Data Download Functionality — General          RR3-220       Bulk Data Download File Creation    NPAC SMS shall provide a mechanism that allows a Service Provider to recover network data, notification data and subscription data in file format.          RR3-221       Bulk Data Download — File Naming Convention    NPAC SMS shall follow the file naming convention as described in Appendix E.          RR3-222       Bulk Data Download — File Format    NPAC SMS shall follow the file format as described in Appendix E.          RR3-223       Bulk Data Download — Selection Criteria for File Creation    NPAC SMS shall allow network data only, subscription data only, notification data only, or all, as selection criteria for bulk data download file generation.  3.10.2 Network Data, Bulk Data Download          RR3-224       Bulk Data Download — Required Selection Criteria for Network Data File Generation    NPAC SMS shall require, as selection criteria for network bulk data download file generation, a Service Provider filter of either a single Service Provider ID or ‘All Service Providers’.          RR3-301       Network Data Information Bulk Download File Creation — Selection Criteria    NPAC SMS shall include the Requesting Service Provider, All Network Data or Latest View of Network Data Activity Choice, and Time Range as Selection Criteria fields for the Network Data bulk data download files via the NPAC Administrative Interface. (Previously NANC 354  Req 2)          RR3-302       Network Data Information Bulk Download File Creation — All Network Data or Latest View of Network Data Activity Choice    NPAC SMS shall allow NPAC Personnel to select either All Network Data or Latest View of Network Data Activity, and shall use the selected choice, for Network Data. (Previously NANC 354 Req 3)                                Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-58    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-303       Network Data Information Bulk Download File Creation — Data in All Network Data Choice    NPAC SMS shall use the All Network Data selection to include all Network Data in the Network Data Bulk Data Download files. (Previously NANC 354 Req 4)          RR3-304       Network Data Information Bulk Download File Creation — Data in Latest View of Network Data Activity Choice    NPAC SMS shall use the Latest View of Network Data Activity selection to include all Network Data, in order to capture activation, modification (NPA-NXX-X only), and deletion transactions for Network Data, but only include the latest instance of the Network Data in the Network Data Bulk Data Download files, when Network Data has more than one activity (e.g., addition, then modification of an NPA-NXX-X) within the specified time range. (Previously NANC 354 Req 5)  Note: The format of the BDD file doesn’t change based on the status of the Network Data but some of the fields may be blank. Example: Creates and modifies would have all the attributes specified but disconnect and deletes would have many fields null.          RR3-305       Network Data Information Bulk Download File Creation — Time Range Fields    NPAC SMS shall use the Start Time Range entry field as an inclusive start range, and the End Time Range entry field as an inclusive end range, for Network Data data that were broadcast during the specified Time Range. (Previously NANC 354 Req 6)  Note: The NPAC Administrative Interface is settable for the GUI user’s local time (e.g., a USA in Sterling will have the local time set to Eastern Time). M&Ps will be established to determine the correct time range on the request of the BDD file.          RR3-306       Network Data Information Bulk Download File Creation — Time Range Fields and Network Data Data Model    NPAC SMS shall use the Start and End Time Range entry fields to include Network Data, based on the appropriate Broadcast Time Stamp, in order to capture the start of broadcast activity for Activation/Modification/Disconnect, when generating the file for the Latest View of Network Data Activity selection. (Previously NANC 354 Req 7)          RR3-307       Network Data Information Bulk Download File Creation — Selection Criteria Combinations    NPAC SMS shall edit the selection criteria combination as shown in the table below:                      Time Range   TN Range     All Network Data    Rejected    Not Available   Latest View of Network Data Activity    Required    Not Available     Such that a combination of:       •   All with a Time Range shall be rejected.        •   Latest View shall require a Time Range.        •   TN Range shall not be available for either All or Latest View.            (Previously NANC 354 Req 8)                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-59    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-308   Network Data Information Bulk Data Download – Network Data Results    NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Network Data in the NPAC SMS. (Previously NANC 354 Req 9)          RR3-309   Network Data Information Bulk Data Download – Network Data Results Sort Order    NPAC SMS shall sort the Network Data Bulk Data Download files, in ascending order based on the value in the NPA-NXX/LRN/NPA-NXX-X attribute. (Previously NANC 354 Req 10)          RR3-310   Network Data Information Bulk Data Download – Filters for Network Data    NPAC SMS shall apply NPA-NXX Filters to Network Data in the creation of bulk data download files. (Previously NANC 354 Req 11)          RR3-311   Network Data Information Bulk Data Download – FTP Sub-Directory    NPAC SMS shall automatically put the Network Data bulk data download files into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the Network Data bulk data download files. (Previously NANC 354 Req 12)          RR3-481   Service Provider Data Information Bulk Data Download – Support for Service Provider Type Data    NPAC SMS shall apply the Service Provider Type tunable support of the requesting Service Provider, in the creation of Service Provider bulk data download files. (previously NANC 357, Req 8)          3.10.3   Subscription Version, Bulk Data Download            RR3-225   Bulk Data Download –Required Selection Criteria for Subscription Data File Generation    NPAC SMS shall require, as selection criteria for subscription bulk data download file generation, a Service Provider filter of either a single Service Provider ID or ‘All Service Providers’.          RR3-226   Bulk Data Download – Optional Selection Criteria for Subscription Data File Generation -DELETED.            RR3-312   Subscription Version Information Bulk Download File Creation – Selection Criteria    NPAC SMS shall include the Requesting Service Provider, Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity Choice, Time Range and TN Range as Selection Criteria fields for the Subscription Version bulk data download file via the NPAC Administrative Interface. (Previously NANC 169 Req 2)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-60    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-313   Subscription Version Information Bulk Download File Creation – Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity Choice    NPAC SMS shall allow NPAC Personnel to select either Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity, and shall use the selected choice, for Subscription Version data. (Previously NANC 169 Req 3)          RR3-314   Subscription Version Information Bulk Download File Creation – Data in Active/Disconnect Pending/Partial Failure Subscription Versions Only Choice    NPAC SMS shall use the Active/Disconnect Pending/Partial Failure Subscription Versions Only selection to only include Subscription Versions with a status of either Active, Disconnect Pending, Partial Failure, or Sending that is being downloaded for either an activate or modify but not a disconnect, in the Subscription Version Bulk Data Download file. (Previously NANC 169 Req 4)          RR3-315   Subscription Version Information Bulk Download File Creation – Data in Latest View of Subscription Version Activity Choice    NPAC SMS shall use the Latest View of Subscription Version Activity selection to include all Subscription Versions, regardless of status, in order to capture activation, modification, and deletion transactions for Subscription Version data, but only include the latest instance of the TN in the Subscription Version Bulk Data Download file, for a given NPA-NXX, when a Subscription Version has more than one activity (e.g., addition, then modification) within the specified time range. (Previously NANC 169 Req 5)  Note: The format of the BDD file doesn’t change based on the status of the SV but some of the fields may be blank. Example: Creates and modifies would have all the attributes specified but disconnect and deletes would have many fields null.          RR3-316   Subscription Version Information Bulk Download File Creation – Time Range Fields    NPAC SMS shall use the Start Time Range entry field as an inclusive start range, and the End Time Range entry field as an inclusive end range, for Subscription Version data that were broadcast during the specified Time Range. (Previously NANC 169 Req 6)  Note: The NPAC Administrative Interface is settable for the GUI user’s local time (e.g., a USA in Sterling will have the local time set to Eastern Time).          RR3-317   Subscription Version Information Bulk Download File Creation – Time Range Fields and SV Data Model    NPAC SMS shall use the Start and End Time Range entry fields to include Subscription Version data, based on the appropriate Broadcast Time Stamp, in order to capture the start of broadcast activity for Activation/Modification/Disconnect, when generating the file for the Latest View of Subscription Version Activity selection. (Previously NANC 169 Req 7)          RR3-318   Subscription Version Information Bulk Download File Creation – TN Range Fields    NPAC SMS shall use the first TN Range entry field as an inclusive start range, and the second TN Range entry field as an inclusive end range, for Subscription Version data. (Previously NANC 169 Req 8)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-61    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-319   Subscription Version Information Bulk Download File Creation – Selection Criteria Combinations    NPAC SMS shall edit the selection criteria combination as shown in the table below:                      Time Range   TN Range     Active/Disconnect Pending/Partial Failure Sending with a Download Reason of New or Modify SVs Only    Rejected    Optional   Latest View of SV Activity    Required    Optional     Such that a combination of:       •   Active with a Time Range shall be rejected.        •   Latest View shall require a Time Range.        •   TN Range shall be optional for both Active and Latest View.            (Previously NANC 169 Req 9)            RR3-320   Subscription Version Information Bulk Data Download – Subscription Version Results    NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Subscription Versions in the NPAC SMS. (Previously NANC 169 Req 10)          RR3-321   Subscription Version Information Bulk Data Download – Subscription Version Results Sort Order    NPAC SMS shall sort the Subscription Version Bulk Data Download file, in ascending order based on the value in the TN attribute. (Previously NANC 169 Req 11)          RR3-322   Subscription Version Information Bulk Data Download – Filters for Subscription Versions    NPAC SMS shall apply NPA-NXX Filters to Subscription Versions in the creation of bulk data download files. (Previously NANC 169  Req 12)          RR3-323   Subscription Version Information Bulk Data Download – EDR LSMSs    NPAC SMS shall use the Service Provider’s profile (EDR Flag True or False) to determine if it should include Pooled SVs in the bulk data download file. (Previously NANC 169 Req 13)          RR3-227   Bulk Data Download – FTP Sub-Directory    NPAC SMS shall automatically put the subscription bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the subscription bulk data download file.          RR3-324   Bulk Download File Creation – Pooled Subscription Versions Filtered for EDR Local SMS    NPAC SMS shall filter out Subscription Versions with LNP Type of POOL for Bulk Data Download files of Subscription Version data, when the requesting Service Provider has an EDR Indicator set to TRUE. (Previously SV-521 and RR5-112)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-62    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            3.10.4   NPA-NXX-X Holder, Bulk Data Download    This section of requirements was previously 3.13.9 NPA-NXX-X Holder, Bulk Data Download and was moved to this new section for document consistency. The requirement numbers remain static to their original FRS numbering.          RR3-116   Number Pool NPA-NXX-X Holder Information Bulk Download File – Separate File containing all NPA-NXX-X Data    NPAC SMS shall provide a separate bulk data download file that contains all NPA-NXX-Xs in the NPAC SMS, when generating bulk data download files for Network Data. (Previously N-373)          RR3-117   Number Pool NPA-NXX-X Holder Information Bulk Download File – Filters for NPA-NXX-X Data    NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-Xs in the creation of a bulk data download file. (Previously N-374)          RR3-118   Number Pool NPA-NXX-X Holder Information Bulk Download File – FTP Sub-Directory    NPAC SMS shall automatically put the NPA-NXX-X bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the bulk data download file for Network Data. (Previously N-375)Subscription Version, Bulk Data Download          3.10.5   Block Holder, Bulk Data Downloads    This section of requirements was previously 3.14.9 Block Holder, Bulk Data Download and was moved to this new section for document consistency. The requirement numbers remain static to their original FRS numbering.          RR3-198   Number Pool Block Holder Information Bulk Download File Creation – Blocks    NPAC SMS shall allow NPAC personnel to request a bulk data download file for Block data via the NPAC Administrative Interface. (Previously B-640)          RR3-199   Number Pool Block Holder Information Bulk Download File Creation – Selection Criteria    NPAC SMS shall include the Requesting Service Provider, Active and Partial Failure Blocks Only or Latest View of Block Activity Choice, Time Range, and Block Range as Selection Criteria fields for the Block bulk data download file via the NPAC Administrative Interface. (Previously B-650)          RR3-200.1   Number Pool Block Holder Information Bulk Download File Creation – Active and Partial Failure Blocks Only or Latest View of Block Activity Choice    NPAC SMS shall allow NPAC Personnel to select either Active and Partial Failure Blocks Only or Latest View of Block Activity, and shall use the selected choice, for Block data. (Previously B-652.1)          RR3-200.2   Number Pool Block Holder Information Bulk Download File Creation – Data in Active Blocks Only Choice    NPAC SMS shall use the Active and Partial Failure Blocks Only selection to only include Blocks with a status of either Active or Partial Failure in the Block Bulk Data Download file. (Previously B-652.2)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-63    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-200.3   Number Pool Block Holder Information Bulk Download File Creation – Data in Latest View of Block Activity Choice    NPAC SMS shall use the Latest View of Block Activity selection to include all Blocks, regardless of status, in order to capture activation, modification, and deletion transactions for Block data, but only include the latest instance of the Block in the Block Bulk Data Download file, for a given NPA-NXX-X, when a Block has more than one activity (e.g., addition, then modification) within the specified time range. (Previously B-652.3)          RR3-201.1   Number Pool Block Holder Information Bulk Download File Creation – Time Range Fields    NPAC SMS shall use the Start Time Range entry field as an inclusive start range in GMT, and the End Time Range entry field as an inclusive ending range in GMT, for Block data that were broadcast during the specified Time Range. (Previously B-654.1)          RR3-201.2   Number Pool Block Holder Information Bulk Download File Creation – Time Range Fields and Block Data Model    NPAC SMS shall use the Start and End Time Range entry fields to include Block data, based on the appropriate Timestamps, in the NPAC’s Block Data Model, when generating the file for the Latest View of Block Activity selection. (Previously B-654.2)          RR3-202   Number Pool Block Holder Information Bulk Download File Creation – Block Range Fields    NPAC SMS shall use the first Block Range entry field as an inclusive start range, and the second Block Range entry field as an inclusive ending range, for Block data. (Previously B-655)  Note: If the Block Range was 303-242-2 through 303-355-6, the inclusive range would contain all Blocks within the TN Range of 303-242-2000 through 303-355-6999.          RR3-203   Number Pool Block Holder Information Bulk Download File Creation – Selection Criteria Combinations    NPAC SMS shall edit the selection criteria combination as shown in the table below: (Previously B-657)                      Time Range   Block Range     Active and Partial Failure Blocks Only    Rejected    Optional   Latest View of Block Activity    Required    Optional     Such that a combination of:      •   Active with a Time Range shall be rejected.      •   Latest View shall require a Time Range.      •   Block Range shall be optional for both Active and Latest View.            RR3-204   Number Pool Block Holder Information Bulk Data Download – Block Results    NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Blocks in the NPAC SMS, regardless of the value in the Service Provider’s EDR Indicator. (Previously B-660)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-64    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-205   Number Pool Block Holder Information Bulk Data Download – Block Results Sort Order    NPAC SMS shall sort the Block Bulk Data Download file, in ascending order based on the value in the NPA-NXX-X attribute. (Previously B-662)          RR3-206   Number Pool Block Holder Information Bulk Data Download – Filters for Blocks    NPAC SMS shall apply NPA-NXX Filters to Blocks in the creation of bulk data download files. (Previously B-670)          RR3-207   Number Pool Block Holder Information Bulk Data Download – FTP Sub-Directory    NPAC SMS shall automatically put the bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the bulk data download file. (Previously B-680)          3.10.6   Notifications, Bulk Data Download            RR3-462   Notification BDD Selection Criteria Fields    NPAC SMS shall include the requesting Service Provider and a time range, as selection criteria fields for the Notification bulk data download file, via the NPAC Administrative Interface. (previously NANC 348, Req 2)          RR3-463   Notification BDD Required Selection Criteria    NPAC SMS shall require, as selection criteria for notification bulk data download file generation, a requesting Service Provider ID and a time range. (previously NANC 348, Req 3)          RR3-464   Notification BDD File Name    NPAC SMS shall provide a bulk data download file for notification data, using a file name that indicates the Notification data and requested time range. (previously, NANC 348, Req 4)          RR3-465   Notification BDD Time Range    NPAC SMS shall use the Start Time Range entry field as an exclusive start range, and the End Time Range entry field as an inclusive end range, for Notification data that were broadcast during the specified time range, based on notification attempt timestamp. (previously NANC 348, Req 5)          RR3-466   Notification BDD Results    NPAC SMS shall provide a bulk data download file, based on selection criteria, that contains all Notification data in the NPAC SMS. (previously NANC 348, Req 6)          RR3-467   Notification BDD Sort Order    NPAC SMS shall sort the Notification bulk data download file, in ascending order based on the value for date and time. (previously NANC 348, Req 7)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-65    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-468   Notification BDD Filters    NPAC SMS shall apply SP Profile Flags for ranges and notification type (based on the settings at the time the notification was created). (previously NANC 348, Req 8)          RR3-469   Notification BDD FTP Sub-Directory    NPAC SMS shall automatically put the Notification bulk data download file into the FTP sub-directory of the Service Provider, based on the SPID value of the requesting Service Provider. (previously NANC 348, Req 9)          3.10.7   Bulk Data Download Response Files    The following section describes Bulk Data Download Response files. Bulk Data Download Response Files are used by the NPAC SMS to clean up Failed SP Lists for Subscription Version and Number Pool Block information.          RR3-325   File Name Format for Service Provider BDD Response File    NPAC SMS shall require the file name format of the Service Provider BDD Response File to be the original BDD File Name with a dash and the SPID appended at the end. (Previously NANC 322 Req 7)  Example: Subscription Versions BDD File for SPID 4768                 BDD File Name    NPANXX-NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS   Service Provider BDD Response File Name    NPANXX-NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS-4768             RR3-326   File Contents for Service Provider BDD Response File    NPAC SMS shall require the file contents of the Service Provider BDD Response File to contain a minimum format of SVID/PooledBlock ID and TN/PooledBlock, based on a response file for either Subscription Version data or Block data.  Note: A Service Provider can either send back the same file (with SPID value appended at the end of the file name), or a truncated version of the rest of the data, as long as the first two columns are in the response file. (Previously NANC 322 req 8)  Example of BDD Response File: Subscription Versions BDD Response File for SPID 4768 (Block Response Files would contain the parenthetical attributes)                SVID (or Block ID) <pipe> TN (or Block value) <CR>   123987|7032281234 <CR>    (end of first TN with “positive” response)   123988|7032281235<CR>    (end of second TN with “positive” response)   123989|7032281236 <CR>    (end of third TN with “positive” response)   123990|7032281237 <CR>    (end of fourth TN with “positive” response)   123991|7032281238 <CR>    (end of fifth TN with “positive” response)     Note: There will be separate files for Subscription Versions and Number Pool Blocks.                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-66    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-327   Complete File Processing for Service Provider BDD Response File    NPAC SMS shall require the file contents of the Service Provider BDD Response File to contain a “positive” response for each “in-sync” record from the original BDD File, and the NPAC SMS shall successfully process each record in a Service Provider BDD Response File once. (Previously NANC 322 Req 9)  Note: Service Providers cannot provide more than one BDD Response File for any given BDD File. The definition of a “positive” record in the response file is one where the Service Provider and the NPAC are “in-sync” (whether the Service Provider updated their database or already had the record in their database). So a “positive” response is synchronization-based, not action-based, and the NPAC will use this “positive” response as an indication to remove the Service Provider from the failed list, if applicable.          RR3-328   Processing of the Service Provider BDD Response File for Subscription Versions    NPAC SMS shall process the Service Provider BDD Response File, containing “positive” response records for the original BDD file, received from a Service Provider’s ftp site as a result of the Service Provider receiving and processing a Bulk Data Download File or a Delta Bulk Data Download File for Subscription Versions. (Previously NANC 322 Req 1)  Note: For example in a situation where 1000 SVs are selected and placed in the BDD File, the NPAC will expect the Service Provider to provide a response file for those 1000 records, which would include up to 1000 “positive” responses. The definition of a “positive” record in the response file is one where the Service Provider and the NPAC are in sync (whether the Service Provider updated their database or already had the record in their database). So a “positive” response is synchronization-based, not action-based, and the NPAC will use this “positive” response as an indication to remove the Service Provider from the failed list, if applicable. So, a Service Provider receives a delta BDD that contains 1000 SVs, and they add 990 to their database, and confirm that 8 are already in their database and don’t need any changes. The BDD Response File would contain 998 “positive” responses that the NPAC would then process.          RR3-329   Removing a Service Provider from a Subscription Version Failed SP List    NPAC SMS shall remove a Service Provider from a Subscription Version Failed SP List based on the SVID contained in the Service Provider BDD Response File and the timestamp in the file name being greater than or equal to the broadcast timestamp. (Previously NANC 322 Req 3)          RR3-330   Processing of the Service Provider BDD Response File for Number Pooling Blocks    NPAC SMS shall process the Service Provider BDD Response File, containing “positive” response records for the original BDD file, received from a Service Provider’s ftp site as a result of the Service Provider receiving and processing a Bulk Data Download File or a Delta Bulk Data Download File for Number Pooling Blocks. (Previously NANC 322 Req 2)  Note: For example in a situation where 12 Blocks are selected and placed in the BDD File, the NPAC will expect the Service Provider to provide a response file for those 12 records, which would include up to 12 “positive” responses. The definition of a “positive” record in the response file is one where the Service Provider and the NPAC are in sync (whether the Service Provider updated their database or already had the record in their database). So a “positive” response is synchronization-based, not action-based, and the NPAC will use this “positive” response as an indication to remove the Service Provider from the failed list, if applicable. So, a Service Provider receives a delta BDD that contains 12 Blocks, and they add 10 to their database, and confirm that 1 is already in their database and doesn’t need any changes. The BDD Response File would contain 11 “positive” responses that the NPAC would then process.                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-67    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-331   Removing a Service Provider from a Number Pooling Block Failed SP List    NPAC SMS shall remove a Service Provider from a Number Pooling Block Failed SP List based on the BlockID contained in the Service Provider BDD Response File and the timestamp in the file name being greater than or equal to the broadcast timestamp. (Previously NANC 322 Req 4)          RR3-332   Service Provider Not Found on the Failed SP List    NPAC SMS shall continue processing the Service Provider BDD Response File after finding that the SPID for one of the data items in the Service Provider BDD Response File does not match a SPID on the Failed SP List. (Previously NANC 322 Req 5)          RR3-333   Validation of SPID in the Service Provider BDD Response File Against SPID of the FTP Directory    NPAC SMS shall validate the SPID of the FTP directory against the SPID in the Service Provider BDD Response File it is retrieving. (Previously NANC 322 Req 6)  3.11 NPA-NXX-X Information          3.11.1   NPA-NXX-X Download Indicator Management            RR3-52   NPAC Customer SOA NPA-NXX-X Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving the NPA-NXX-X data, by downloading this data to their SOA via the SOA to NPAC SMS Interface, using the Number Pooling NPA-NXX-X Object. (Previously NC-1)          RR3-53   NPAC Customer SOA NPA-NXX-X Indicator – Default    NPAC SMS shall default the SOA NPA-NXX-X Indicator to FALSE. (Previously NC-3)          RR3-54   NPAC Customer SOA NPA-NXX-X Indicator – Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the SOA NPA-NXX-X Indicator on the NPAC Customer record. (Previously NC-5)          RR3-55   NPAC Customer LSMS NPA-NXX-X Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving the NPA-NXX-X data, by downloading this data to their Local SMS via the NPAC SMS to Local SMS Interface, using the Number Pooling NPA-NXX-X Object. (Previously NC-10)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-68    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-56   NPAC Customer LSMS NPA-NXX-X Indicator – Default    NPAC SMS shall default the LSMS NPA-NXX-X Indicator to FALSE. (Previously NC-20)          RR3-57   NPAC Customer LSMS NPA-NXX-X Indicator – Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the LSMS NPA-NXX-X Indicator on the NPAC Customer record. (Previously NC-30)          RR3-58   NPAC Customer LSMS EDR Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports Efficient Data Representation (EDR), by downloading this data to their Local SMS via the NPAC SMS to Local SMS Interface, using the Number Pooling Block Object. (Previously NC-50)          RR3-59   NPAC Customer LSMS EDR Indicator – Default    NPAC SMS shall default the EDR Indicator to FALSE. (Previously NC-60)         RR3-60   NPAC Customer LSMS EDR Indicator – Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the EDR Indicator on the NPAC Customer record. (Previously NC-70)          3.11.2   NPA-NXX-X Holder Information            RR3-61   Number Pool NPA-NXX-X Holder Information – NPAC Personnel OpGUI    NPAC SMS shall allow NPAC Personnel to add, modify, delete, and query NPA-NXX-X Holder information via the NPAC Administrative Interface. (Previously N-10)          RR3-62   Number Pool NPA-NXX-X Holder Information – Service Provider Request    NPAC SMS shall reject a request from a Service Provider SOA via the SOA to NPAC SMS Interface, Service Provider via the NPAC SOA Low-tech Interface, or Service Provider via the NPAC SMS to Local SMS Interface, to add, modify, or delete, NPA-NXX-X Holder information as stored in the NPAC SMS. (Previously N-20)          RR3-63   Number Pool NPA-NXX-X Holder Information – NPA-NXX Validation    NPAC SMS shall validate that the NPA-NXX specified in the addition of Number Pooling NPA-NXX-X Holder information is a valid NPA-NXX defined in the NPAC SMS. (Previously N-30)          RR3-64   Number Pool NPA-NXX-X Holder Information – NPA-NXX Effective Date    DELETED                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-69    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-65   Number Pool NPA-NXX-X Holder Information – Duplicate NPA-NXX-X Validation    NPAC SMS shall validate that the NPA-NXX-X specified in the addition of Number Pooling NPA-NXX-X Holder Information is not a duplicate for another entry in the Number Pooling NPA-NXX-X Holder Information. (Previously N-50)          RR3-68   Number Pool NPA-NXX-X Holder Information – Service Provider Local SMS NPA-NXX-X Indicator Download of NPA-NXX-X Object    NPAC SMS shall download Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, using the Number Pooling NPA-NXX-X Object, via the NPAC SMS to Local SMS Interface if the Service Provider’s Local SMS NPA-NXX-X indicator is TRUE. (Previously N-63)          RR3-69   Number Pool NPA-NXX-X Holder Information – Service Provider Local SMS NPA-NXX-X Indicator Suppression of Download of NPA-NXX-X Object    NPAC SMS shall suppress the download of Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, via the NPAC SMS to Local SMS Interface if the Service Provider’s Local SMS NPA-NXX-X indicator is FALSE. (Previously N-64)          RR3-70   Number Pool NPA-NXX-X Holder Information – Filters for NPA-NXX-X Download to the Local SMS    NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X downloads to the Local SMS(s). (Previously N-65)          RR3-71   Number Pool NPA-NXX-X Holder Information – Service Provider SOA NPA-NXX-X Indicator Download of NPA-NXX-X Object    NPAC SMS shall download Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, using the Number Pooling NPA-NXX-X Object, via the SOA to NPAC SMS Interface if the Service Provider’s SOA NPA-NXX-X indicator is TRUE. (Previously N-66)          RR3-72   Number Pool NPA-NXX-X Holder Information – Service Provider SOA NPA-NXX-X Indicator Suppression of Download of NPA-NXX-X Object    NPAC SMS shall suppress the download of Number Pooling NPA-NXX-X Information, for additions, modifications, and deletions, via the SOA to NPAC SMS Interface if the Service Provider’s SOA NPA-NXX-X indicator is FALSE. (Previously N-67)          RR3-73   Number Pool NPA-NXX-X Holder Information – Filters for NPA-NXX-X Download to the SOA    NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X downloads to the SOA(s). (Previously N-68)          RR3-74   Number Pool NPA-NXX-X Holder Information – Validation Error    NPAC SMS shall report an error to the NPAC Personnel and reject the addition or modification of Number Pooling NPA-NXX-X Holder information, or the addition of an NPA Split, if validation errors occur as defined in Requirements RR3-63, RR3-65, RR3-85, RR3-96, RR3-32, RR3-482 and RR3-483. (Previously N-70, updated with NANC 394)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-70    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            3.11.3   NPA-NXX-X Holder, NPAC Scheduling/Re-Scheduling of Block Creation            RR3-75.1   Number Pool NPA-NXX-X Holder Information –OpGUI Entry Field for NPAC or SOA Origination    NPAC SMS shall provide a mechanism for NPAC Personnel to select NPAC Origination or SOA Origination for the Block data, when creating NPA-NXX-X Holder information, via the NPAC Administrative Interface. (Previously N-71.1)          RR3-75.2   Number Pool NPA-NXX-X Holder Information –OpGUI Entry Mechanism for Immediate or Scheduled Block Creation    NPAC SMS shall provide a mechanism for NPAC Personnel to request NPAC Block Creation for either immediate execution, once the Effective Date has been reached, or at a future date/time, via the NPAC Administrative Interface. (Previously N-71.2)          RR3-75.3   Number Pool NPA-NXX-X Holder Information –OpGUI Entry Field for Scheduled Date/Time    NPAC SMS shall include the “Scheduled Date/Time for Block Activation” as an entry field in the format of MM/DD/YYYY and HH:MM, for the NPA-NXX-X Holder information via the NPAC Administrative Interface. (Previously N-71.3)          RR3-76.1   Number Pool NPA-NXX-X Holder Information –Default for Scheduled Date/Time Entry Field    NPAC SMS shall default the value in the “Scheduled Date/Time for Block Activation” field in the NPAC Administrative Interface, to the greater of, the Effective Date and 00:01 (HH:MM) Central Time, or, the current date and time. (Previously N-72.1)          RR3-76.2   Number Pool NPA-NXX-X Holder Information –Scheduled Date/Time Entry Field Validation    NPAC SMS shall validate that the “Scheduled Date/Time for Block Activation” field in the NPAC Administrative Interface, is a valid date and time, and is greater than or equal to the NPA-NXX-X Effective Date. (Previously N-72.2)          RR3-77   Number Pool NPA-NXX-X Holder Information –Use of Scheduled Date/Time and NPAC Origination Entry Fields    NPAC SMS shall use the value in the “Scheduled Date/Time for Block Activation” field as the date and time, in Central Time, that the Block Creation scheduled event will occur, when the NPAC Origination has been selected by NPAC Personnel while creating NPA-NXX-X Holder information, or when re-scheduling a Block Create Event. (Previously N-73)          RR3-78   Number Pool NPA-NXX-X Holder Information – Routing Data for NPAC Origination    NPAC SMS shall require NPAC Personnel to enter applicable Block routing data, via the NPAC Administrative Interface, when the NPAC Origination has been selected by NPAC Personnel while creating NPA-NXX-X Holder information, or when re-scheduling a Block Create Event. (Previously N-74)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-71    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-79.1   Number Pool NPA-NXX-X Holder Information – Routing Data Field Level Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, are valid according to the formats specified in the Block Data Model upon Block creation scheduling for a Number Pool, or when re-scheduling a Block Create Event: (Previously N-75.1, reference NANC 399)  NPA-NXX-X Holder SPID NPA-NXX-X LRN Class DPC Class SSN LIDB DPC LIDB SSN CNAM DPC CNAM SSN ISVM DPC ISVM SSN WSMSC DPC (if supported by the Block Holder SOA) WSMSC SSN (if supported by the Block Holder SOA) Number Pool Block SV Type (if supported by the Block Holder SOA) Alternative SPID (if supported by the Block Holder SOA)          RR3-79.2   Number Pool NPA-NXX-X Holder Information – Routing Data LRN Validation    NPAC SMS shall validate that the LRN specified in the scheduling/re-scheduling of Number Pooling Block Holder information is a valid LRN defined in the NPAC SMS for the Block Holder. (Previously N-75.2)          RR3-80.1   Number Pool NPA-NXX-X Holder Information – Modification of Block Create Event    NPAC SMS shall provide a mechanism for NPAC Personnel to modify a Block Create Event that has been previously entered, but not yet executed, via the NPAC Administrative Interface. (Previously N-76.1)          RR3-80.2   Number Pool NPA-NXX-X Holder Information – Modification of Scheduled Date/Time for Block Create Event    NPAC SMS shall allow NPAC Personnel to modify the scheduled date/time for an NPAC initiated Block Create Event, to a different date/time that is on or after the NPA-NXX-X effective date. (Previously N-76.2)          RR3-80.3   Number Pool NPA-NXX-X Holder Information – Modification of Routing Data for Block Create Event    NPAC SMS shall allow NPAC Personnel to modify the routing data for an NPAC initiated Block Create Event. (Previously N-76.3)          RR3-81.1   Number Pool NPA-NXX-X Holder Information – Re-schedule of NPAC Initiated Block Create    NPAC SMS shall provide a mechanism for NPAC Personnel to re-schedule a Block Create, for an existing NPA-NXX-X, via the NPAC Administrative Interface. (Previously N-77.1)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-72    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-81.2   Number Pool NPA-NXX-X Holder Information – Re-schedule of Block Create Scheduling Options    NPAC SMS shall provide a mechanism where the re-schedule of a Block Create, can be immediately executed or scheduled for a future date/time. (Previously N-77.2)          RR3-81.3   Number Pool NPA-NXX-X Holder Information – Re-schedule of Block Create Immediate Execution Edit Check    NPAC SMS shall reject the re-schedule of a Block Create for immediate execution, prior to the effective date of the NPA-NXX-X. (Previously N-77.3)          RR3-82.1   Number Pool NPA-NXX-X Holder Information – Reject Re-schedule Based on Status    NPAC SMS shall allow the re-schedule of a Block Create, if the Block does NOT exist in the NPAC SMS, or if the Block exists with a status of Old without a Failed SP List. (Previously N-78.1)          RR3-82.2   Number Pool NPA-NXX-X Holder Information – Reject Re-schedule Based on Existing Block Create Event    NPAC SMS shall only allow a single Block Create Event that has not been previously executed for this Block, to exist in the NPAC SMS. (Previously N-78.2)          RR3-82.3   Number Pool NPA-NXX-X Holder Information – Validation Error for Schedule/Re-Schedule of Block Create Event    NPAC SMS shall report an error to the NPAC Personnel and reject the addition or modification of a Number Pooling Block Create Event, if validation errors occur as defined in Requirements RR3-76.2, RR3-78, RR3-79.1, RR3-79.2, RR3-81.3, RR3-82.1, and RR3-82.2. (Previously N-78.3)          RR3-83.1   Number Pool NPA-NXX-X Holder Information – Error Message for Pending-Like No-Active SVs during Block Create    NPAC SMS shall provide an error dialog that displays the unique error message described in RR3-147, and provides an option for the NPAC Personnel to either, exit the Block Create request, or generate the Pending-Like No-Active Subscription Version(s) report, in the report format listed in RR9-11, RR9-12, RR9-13, and RR9-14, to the screen on the NPAC Administrative Interface, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.1)          RR3-83.2   Number Pool NPA-NXX-X Holder Information – Pending-Like No-Active SVs Report Output Destinations    NPAC SMS shall, after displaying the Pending-Like No-Active Subscription Version(s) report to the screen, allow the NPAC Personnel to choose an output destination for the report, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.2)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-73    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-83.3   Number Pool NPA-NXX-X Holder Information – Pending-Like No-Active SVs Report Output Destinations for Multiple Destinations    NPAC SMS shall, continue to display the Pending-Like No-Active Subscription Version(s) report, to the screen, and allow the NPAC Personnel to choose additional output destinations one at a time, for the report, until the NPAC Personnel requests the closure of the report window, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.3)          RR3-83.4   Number Pool NPA-NXX-X Holder Information – Output Destination for Pending-Like No-Active SVs    NPAC SMS shall provide output destination options for the Pending-Like No-Active Subscription Version(s) Report, based on the error message in RR3-83.1, that include print, fax, e-mail, stored to a file, when NPAC Personnel are re-scheduling a Block Creation request for immediate execution. (Previously N-79.4)          3.11.4   NPA-NXX-X Holder, Addition            RR3-84   Addition of Number Pooling NPA-NXX-X Holder Information – Required Fields    NPAC SMS shall require NPAC personnel to specify the NPA-NXX-X Holder SPID, the NPA-NXX-X, and the Effective Date, as defined in the Number Pooling NPA-NXX-X Holder Information data model. (Previously N-80)          RR3-85   Addition of Number Pooling NPA-NXX-X Holder Information – SPID Validation    NPAC SMS shall validate that the NPA-NXX-X Holder SPID is a valid Service Provider in the NPAC SMS. (Previously N-90)          RR3-86   Addition of Number Pooling NPA-NXX-X Holder Information – Check for Pending-Like No-Active SVs    NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Creation, if there are any TNs within the 1K Block of that NPA-NXX-X, or in a 1K Block of the corresponding old/new NPA-NXX-X belonging to an NPA-NXX scheduled for or currently in an NPA split, that contain an SV, with a status of pending/conflict/cancel-pending/failed, and where a currently active SV does NOT exist, for the given TN. (Previously N-100)          RR3-87   Addition of Number Pooling NPA-NXX-X Holder Information – Check for Pending-Like Port-To-Original SVs    NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Creation, if there are any TNs within the 1K Block, that contain an SV, with a status of pending/conflict/cancel-pending/failed, and where the SV is a Port-To-Original port, for the given TN. (Previously N-110)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-74    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-88.1   Addition of Number Pooling NPA-NXX-X Holder Information – Error Message for Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs    NPAC SMS shall provide an error dialog that displays the unique error message described in RR3-86 and RR3-87, and provides an option for the NPAC Personnel to either, exit the NPA-NXX-X Create request, or generate the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, in the report format listed in RR9-11, RR9-12, RR9-13, and RR9-14, to the screen on the NPAC Administrative Interface. (Previously N-130.1)          RR3-88.2   Addition of Number Pooling NPA-NXX-X Holder Information –Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs Report Selection of Output Destinations    NPAC SMS shall, after displaying the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, allow the NPAC Personnel to choose an output destination for the report. (Previously N-130.2)          RR3-88.3   Addition of Number Pooling NPA-NXX-X Holder Information –Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs Report Output Destinations for Multiple Destinations    NPAC SMS shall, continue to display the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, and allow the NPAC Personnel to choose additional output destinations one at a time, for the report, until the NPAC Personnel requests the closure of the report window. (Previously N-130.3)          RR3-89   Addition of Number Pooling NPA-NXX-X Holder Information – Output Destination for Pending-Like No-Active SVs and Pending-Like Port-To-Original SVs    NPAC SMS shall provide output destination options, as listed in R9-2, for the Pending-Like No-Active Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, based on the error condition in RR3-88.1. (Previously N-131)          RR3-90   Addition of Number Pooling NPA-NXX-X Holder Information Effective Date Window– Tunable Parameter    DELETED           RR3-91   Addition of Number Pooling NPA-NXX-X Holder Information Effective Date Window – Tunable Parameter Default    DELETED           RR3-92   Addition of Number Pooling NPA-NXX-X Holder Information Effective Date – Validation    DELETED           RR3-482   Number Pooling NPA-NXX-X Holder Information Effective Date – Validation upon Addition    NPAC SMS shall verify that the Effective Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and greater than or equal to the current date, when adding an NPA-NXX-X. (previously NANC 394, Req 4)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-75    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-470   Addition of Number Pooling NPA-NXX-X Holder Information Effective Date – Validation Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window    DELETED           RR3-93   Addition of Number Pooling NPA-NXX-X Holder Information Effective Date – OpGUI Default    NPAC SMS shall set the time portion of the Effective Date Timestamp to 00:00 Central Time, and not allow the NPAC Personnel to modify the Time portion of the Effective Date, on the NPAC Administrative Interface. (Previously N-170)          RR3-94   Addition of Number Pooling NPA-NXX-X Holder Information – Successful Validation    NPAC SMS shall, upon successful validation, store the NPA-NXX-X in the NPAC SMS, and broadcast the NPA-NXX-X to the Service Providers. (Previously N-180)          3.11.5   NPA-NXX-X Holder, Modification            RR3-95   Modification of Number Pool NPA-NXX-X Holder Information – Effective Date Modification from OpGUI    NPAC SMS shall allow NPAC personnel to modify the effective date for an NPA-NXX-X as stored in the NPAC SMS via the NPAC Administrative Interface. (Previously N-190)          RR3-96   Modification of Number Pool NPA-NXX-X Holder Information – Effective Date versus Current Date    NPAC SMS shall allow the NPAC personnel to modify the effective date for an NPA-NXX-X if the current date is less than the effective date for the NPA-NXX-X. (Previously N-200)          RR3-97   Modification of Number Pool NPA-NXX-X Holder Information – Effective Date Update to Scheduled Block Create    NPAC SMS shall, upon modifying the effective date for an NPA-NXX-X, and where the Block Creation was a scheduled event within the NPAC SMS, also modify the corresponding date for that Block Create scheduled event. (Previously N-210)          RR3-98   Modification of Number Pool NPA-NXX-X Holder Information Effective Date Window – Tunable Parameter Modification    DELETE           RR3-99   Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation for Current Date    DELETED                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-76    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-100   Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation for Tunable    DELETED           RR3-483   Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation    NPAC SMS shall verify that the Effective Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and greater than or equal to the current date, when modifying an NPA-NXX-X. (previously NANC 394, Req 5)          RR3-471   Modification of Number Pool NPA-NXX-X Holder Information Effective Date – Validation Within the Tunable Parameter Number of Days    DELETED           RR3-101   Modification of Number Pooling NPA-NXX-X Holder Information – Successful Validation    NPAC SMS shall, upon successful validation, store the updates to the NPA-NXX-X in the NPAC SMS, and broadcast the updated NPA-NXX-X to the Service Providers. (Previously N-235)          3.11.6   NPA-NXX-X Holder, Deletion            RR3-102   Deletion of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X Data    NPAC SMS shall allow NPAC personnel to delete the NPA-NXX-X holder information for an NPA-NXX-X as stored in the NPAC SMS. (Previously N-240)          RR3-103   Deletion of Number Pool NPA-NXX-X Holder Information – Single NPA-NXX-X at a time from OpGUI    NPAC SMS shall allow NPAC personnel to delete the NPA-NXX-X holder information for a single NPA-NXX-X at a time, via the NPAC Administrative Interface. (Previously N-245)          RR3-104   Deletion of Number Pooling NPA-NXX-X Holder Information – Check for Pending-Like With Active POOL SVs    NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if there are any TNs within the 1K Block, that contain an SV with a status of pending/conflict/cancel-pending/failed where the Old SP is equal to the NPA-NXX-X Holder SPID, and the current active SV is LNP Type of POOL. (Previously N-250)          RR3-105   Deletion of Number Pooling NPA-NXX-X Holder Information – Check for Port-to-Original SVs    NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if there are any TNs within the 1K Block, that contain an SV, where the SV is a Port-To-Original port. (Previously N-260)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-77    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-106   Deletion of Number Pooling NPA-NXX-X Holder Information – Check for non-Active Block    NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if the associated Block, contains a status other than Active, or the Failed SP List contains any SPIDs. (Previously N-265)          RR3-107   Deletion of Number Pooling NPA-NXX-X Holder Information – Check for Sending SVs    NPAC SMS shall reject the request and issue an error message to the NPAC personnel at the time of NPA-NXX-X Deletion, if there are any Subscription Versions with a status of sending, as a result of a disconnect request for that given Subscription Version. (Previously N-270)          RR3-108.1   Deletion of Number Pooling NPA-NXX-X Holder Information – Error Message for Pending-Like With Active POOL SVs and Pending-Like Port-To-Original SVs    NPAC SMS shall provide an error dialog that displays the unique error message described in RR3-104 and RR3-105, and provides an option for the NPAC Personnel to either, exit the NPA-NXX-X Delete request, or generate the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, in the report format listed in RR9-15, RR9-16, RR9-17, and RR9-18, to the screen on the NPAC Administrative Interface. (Previously N-280.1)          RR3-108.2   Deletion of Number Pooling NPA-NXX-X Holder Information –Pending-Like With Active POOL SVs and Pending-Like Port-To-Original SVs Report Selection of Output Destinations    NPAC SMS shall, after displaying the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, allow the NPAC Personnel to choose an output destination for the report. (Previously N-280.2)          RR3-108.3   Deletion of Number Pooling NPA-NXX-X Holder Information –Pending-Like With Active POOL SVs and Pending-Like Port-To-Original SVs Report Output Destinations for Multiple Destinations    NPAC SMS shall, continue to display the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, to the screen, and allow the NPAC Personnel to choose additional output destinations one at a time, for the report, until the NPAC Personnel requests the closure of the report window. (Previously N-280.3)          RR3-109   Deletion of Number Pooling NPA-NXX-X Holder Information – Output Destination for Pending-Like and Active POOL SVs and Pending-Like Port-To-Original SVs    NPAC SMS shall provide output destination options, as listed in R9-2, for the Pending-Like With Active POOL Subscription Version(s) and Pending-Like Port-to-Original Subscription Version(s) Report, based on the error condition in RR3-108.1. (Previously N-281)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-78    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-110   Deletion of Number Pool NPA-NXX-X Holder Information – Block and Subscription Version Data Dependency    NPAC SMS shall delete the NPA-NXX-X Holder Information for a 1K Block, through a multi-step process that includes: (Previously N-290)  - Broadcasting the delete of SVs to non-EDR Local SMSs. - - Broadcasting the delete of Blocks to the EDR Local SMSs. - - Receiving a successful response from all EDR and non-EDR Local SMSs. - - Updating all SVs and Blocks on the NPAC SMS. - - Deleting the NPA-NXX-X Holder information from the NPAC SMS. - - Broadcasting the delete of NPA-NXX-X to the NPA-NXX-X enabled SOAs and Local SMSs.           RR3-111   Deletion of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X Dependency    NPAC SMS shall only delete the NPA-NXX-X Holder Information after successfully updating all associated SVs and Blocks to a status of Old with NO Failed SP List. (Previously N-295)          RR3-112   Deletion of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X With an Associated Block Create Scheduled Event    NPAC SMS shall delete an associated Block Create Scheduled Event, that has not been executed, when deleting the NPA-NXX-X Holder Information. (Previously N-297)          3.11.7   NPA-NXX-X Holder, First Port Notification            RR3-228   Number Pool NPA-NXX-X Holder information notification of First Port    NPAC SMS shall notify all accepting Local SMSs and SOAs of the NPA-NXX, effective date, and owning Service Provider when no porting activity has occurred in the NPA-NXX, immediately after creation of a Number Pooling NPA-NXX-X, including those automatically created by NPA Split processing. (Previously N-330)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-79    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            3.11.8   NPA-NXX-X Holder, Query            RR3-113   Query of Number Pool NPA-NXX-X Holder Information – NPAC Personnel and Service Provider Personnel    NPAC SMS shall allow NPAC personnel, Service Provider SOA via the SOA to NPAC SMS Interface, Local SMS via the NPAC SMS to Local SMS Interface, or Service Provider SOA via the NPAC SOA Low-tech Interface, to query the NPA-NXX-X holder information for all data as listed in the NPA-NXX-X Holder Information Data Model, for an NPA-NXX-X as stored in the NPAC SMS. (Previously N-340)          RR3-114   Query of Number Pool NPA-NXX-X Holder Information – Return of Queried Data    NPAC SMS shall return to the NPAC Personnel or requesting Service Provider all NPA-NXX-Xs that match the query selection criteria, as listed in the NPA-NXX-X Holder Information Data Model, for an NPA-NXX-X as stored in the NPAC SMS. (Previously N-360)          RR3-115   Query of Number Pool NPA-NXX-X Holder Information – Return of Queried Data to NPAC Personnel Only    NPAC SMS shall provide to NPAC Personnel only, an indicator on the NPAC Administrative Interface, only after completing a query, if an associated Block Create Scheduled Event, that has not been executed, exists in the NPAC SMS. (Previously N-365)          3.11.9   NPA-NXX-X Holder, Bulk Data Download    This section has been MOVED to 3.12.3 NPA-NXX-X Holder, Bulk Data Download. Requirement numbers remain static.  RR3-116  MOVED to section 3.12.3 NPA-NXX-X Holder, Bulk Data Download.           RR3-117   MOVED to section 3.12.3 NPA-NXX-X Holder, Bulk Data Download.    RR3-118  MOVED to section 3.12.3 NPA-NXX-X Holder, Bulk Data Download.                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-80    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            3.12   Block Information            3.12.1   Version Status    [Graphic Omitted: Pool Block Version Status Interaction Diagram]  In the following table, the reference to “Number Pool Block” data when broadcasting to an LSMS is based on that Service Provider’s EDR Indicator (i.e., Number Pool Block object or Subscription Versions with LNP Type of POOL).  Number Pool Block Version Status Interaction Descriptions                      #   Interaction Name   Type   Description         1    Creation - Set to Sending    NPAC SMS Internal    NPAC SMS creates a Number Pool Block for the Block Holder Service Provider.                            NPAC Operations Interface — NPAC Personnel    User sends a Number Pool Block creation request for the Block Holder Service Provider.                            SOA to NPAC SMS Interface — Block Holder Service Provider    The Service Provider User sends a Number Pool Block creation request for itself (the Block Holder Service Provider).                   2    Sending to Partial Failure    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from sending to partial failure after one or more, but not all, of the Local SMSs fail the Number Pool Block activation after the tunable retry period expires.                   3    Partial Failure to Sending    NPAC Operations Interface — NPAC Personnel    User re-sends a partial failure Number Pool Block.                   4    Sending to Failed    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from sending to failed after all Local SMSs fail Number Pool Block activation after the tunable retry period expires.                   5    Failed to Sending    NPAC Operations Interface — NPAC Personnel    User re-sends a failed Number Pool Block.                                    Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-81    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    Number Pool Block Version Status Interaction Descriptions                              #   Interaction Name   Type   Description         6    Sending to Active    NPAC SMS Internal      1.     NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block activation is successful in all of the Local SMSs.                                          2.     NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block modification is broadcast to all of the Local SMSs and either all have responded or retries have been exhausted.                                          3.     NPAC SMS automatically sets a sending Number Pool Block to active after a failure to all Local SMSs on a de-pool.                           7    Active to Sending    NPAC Operations Interface — NPAC Personnel      1. 2. 3.     User de-pools an active Number Pool Block. User modifies an active Number Pool Block. User resends a failed de-pool or modify Number Pool Block.                                    SOA to NPAC SMS Interface — Block Holder Service Provider    User modifies an active Number Pool Block.                                   8    Sending to Old    NPAC SMS Internal      1.     NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool to all Local SMSs successfully completes.                                          2.     NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool that fails on one or more, but not all Local SMSs.                           9    Old to Sending    NPA Operations Interface – NPAC Personnel    User re-sends a partial failure of a de-pool.                   10    Partial Failure to Partial Failure    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                                    Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-82    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    Number Pool Block Version Status Interaction Descriptions                      #   Interaction Name   Type   Description         11    Partial Failure to Active    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from partial failure to active after all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   12    Old to Old    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from old to old after one or more previously failed Local SMSs successfully de-pools a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.     Table 3-14 Number Pool Block Version Status Interaction Descriptions          3.12.2   Block Holder, General            RR3-119   Number Pool Block Holder Information – NPAC Personnel OpGUI    NPAC SMS shall allow NPAC Personnel to add, modify, or query Block Holder information via the NPAC Administrative Interface. (Previously B-10)          RR3-120   Number Pool Block Holder Information – NPAC Customer EDR Indicator Download of Block Object    NPAC SMS shall download Number Pooling Block Information, for additions, modifications, deletions, re-sends, and resync using the Number Pooling Block Object, via the NPAC SMS to Local SMS Interface if the EDR indicator is TRUE, at the time a request is processed by the NPAC SMS. (Previously B-20)          RR3-121   Number Pool Block Holder Information – NPAC Customer EDR Indicator Download of SVs    NPAC SMS shall download Number Pooling Block Information, for additions, modifications, deletions, re-sends, and resyncs, using individual subscription versions with LNP Type of POOL, for the TNs within the range of the 1K Block, via the NPAC SMS to Local SMS Interface if the EDR indicator is FALSE, at the time a request is processed by the NPAC SMS. (Previously B-30)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-83    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-122   Number Pool Block Holder Information – NPAC Customer EDR Indicator For Requests But Not Retries    NPAC SMS shall use the EDR Indicator when processing a request for Number Pooling Block Information, but not during the retry functionality (“x by y” [where “x” is the number of attempts, and “y” is the interval in number of minutes in between attempts]). (Previously B-32)          RR3-123   Number Pool Block Holder Information – Data Integrity for Block and Pooled Subscription Versions    NPAC SMS shall maintain data integrity for LRN and GTT data, between a Number Pooling Block and the corresponding Subscription Versions with LNP Type of POOL in that 1K Block, in the NPAC SMS. (Previously B-34)          RR3-124   Number Pool Block Holder Information – Service Provider Validation    NPAC SMS shall verify the Block Holder SPID attribute of the Block object matches the SPID in the accessControl for SOA Block Activation. (Previously B-40)          RR3-125   Number Pool Block Holder Information – SPID Validation    NPAC SMS shall verify the SPID of the accessControl matches the owner of the association or one of its secondary providers. (Previously B-50)          RR3-126   Number Pool Block Holder Information – NPA-NXX-X Data Validation    NPAC SMS shall, upon receiving a block activate request, validate that the SPID and the NPA-NXX-X attributes in the request are the same as the SPID and the NPA-NXX-X in a single entry in the NPA-NXX-X Holder Information. (Previously B-60)          RR3-127   Number Pool Block Holder Information – NPA-NXX-X Effective Date    NPAC SMS shall reject a request to create a Block if the current date is prior to the effective date of the Number Pooling NPA-NXX-X as defined in the NPAC SMS. (Previously B-70)          RR3-128   Number Pool Block Holder Information – LRN Validation    NPAC SMS shall validate that the LRN specified in the addition or modification of Number Pooling Block Holder information is a valid LRN defined in the NPAC SMS for the Block Holder. (Previously B-80)          RR3-334   Validation of LATA ID for Number Pool Block Creates    NPAC shall reject Number Pool Block Create Requests if the NPA-NXX of the NPA-NXX-X and the NPA-NXX of the LRN have different LATA IDs. (Previously NANC 319 Req 8)          RR3-335   Validation of LATA ID for Number Pool Block Modifies    NPAC shall reject Number Pool Block Modify Requests if the NPA-NXX of the NPA-NXX-X and the NPA-NXX of the LRN have different LATA IDs. (Previously NANC 319 Req 9)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-84    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-129   Number Pool Block Holder Information – Duplicate Block Validation    NPAC SMS shall validate that the NPA-NXX-X specified in the addition of Number Pooling Block Holder Information does not already exist in the Number Pooling Block Holder Information, except for a status of Old where the Block’s Failed SP List is empty. (Previously B-90)          RR3-130   Number Pool Block Holder Information – SOA Origination Values    NPAC SMS shall set the SOA Origination to TRUE for Blocks sent over the SOA to NPAC SMS Interface or for Blocks sent over the NPAC SOA Low-tech Interface, and to FALSE for Blocks that were created by NPAC personnel, except where the value will be maintained from the Old Block, as a result of an NPA Split. (Previously B-100)          RR3-131   Number Pool Block Holder Information – Validation Error    NPAC SMS shall report an error to the user and reject the addition or modification of Number Pooling Block Holder information if validation errors occur as defined in RR3-124, RR3-125, RR3-126, RR3-127, RR3-128, RR3-129, RR3-146, and RR3-149. (Previously B-110)          RR3-132   Number Pooling Block Holder Information –Update Notification    NPAC SMS shall send all SOA notifications to the current SP (the block holder) for updates on Blocks, when the Block SOA Origination is TRUE. (Previously B-120)          RR3-133   Number Pooling Block Holder Information –Update Notification Suppression    NPAC SMS shall suppress all SOA notifications to the current SP (the block holder) for updates on Blocks, when the Block SOA Origination is FALSE. (Previously B-130)          RR3-134   Number Pooling Block Holder Information – Failed SP List Update for Block for EDR Local SMS    NPAC SMS shall consider an EDR Local SMS to be discrepant and shall update the Block Failed SP List, based on an EDR Local SMS failing to process the Block Object, for an addition, modification, deletion, re-send, resync, or mass update. (Previously B-140)          RR3-135   Number Pooling Block Holder Information – Failed SP List Update for Subscription Versions for non-EDR Local SMS    NPAC SMS shall consider a non-EDR Local SMS to be discrepant and shall update the Block Failed SP List, based on a non-EDR Local SMS failing to process one or more Subscription Versions, with LNP Type of POOL, within the Block, for an addition, modification, deletion, re-send, resync, or mass update. (Previously B-150)          RR3-136   Number Pooling Block Holder Information – Failed SP List Sent to Block Holder    NPAC SMS shall send the Block Failed SP List, to the current SP (the block holder) via the SOA to NPAC SMS Interface, along with the SOA notification for status update of the Block, when the Block SOA Origination is TRUE, and the broadcast to one or more Local SMSs fail. (Previously B-160)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-85    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-137.1   Number Pooling Block Holder Information – Synchronization of Block Status and Subscription Version Status    NPAC SMS shall ensure that the status for Block broadcasts to EDR Local SMSs and Subscription Versions with LNP Type of POOL broadcasts to non-EDR Local SMSs, are synchronized, by performing the following: (Previously B-165.1)     •   The status for the Block and Subscription Versions shall cross-reference one another and contain the results of the broadcast of the Block to the EDR Local SMSs, and the broadcast of the Subscription Versions to the non-EDR Local SMSs.      •   The status for each Subscription Version shall only be set, once the broadcasts of the Block to all EDR and Subscription Versions to non-EDR Local SMSs has been completed, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted.      •   The status for the Block shall only be set, once the broadcasts of the Block to all EDR and Subscription Versions to non-EDR Local SMSs has been completed, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted.      •   The status for the Block shall reflect the information contained in Tables RR3-137.2, RR3-137.3, and RR3-137.4.    Key for Tables RR3-137.2, RR3-137.3, and RR3-137.4 Act = Active status Act/Part = a mix of both Active status and Partial Failure status Part = Partial Failure status Part/Fail = a mix of both Partial Failure status and Failed status Fail = Failed status Old = Old status Act/Old = a mix of both Active status and Old status                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-86    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-137.2   Number Pooling Block Holder Information — Synchronization of Block Status and Subscription Version Status for Block Creation    NPAC SMS shall set the status of a Block for Block Creation, based on the data contained in Table RR3-137.2. (Previously B-165.2)                                                                                  Table RR3-137.2 - Block Creation       EDR Local SMS   Non-EDR Local SMS                                               some but not                                                           all non-EDR                                                           Local SMSs   all non-EDR                                                       respond   Local SMSs                                               all non-EDR   successfully to   fail a given   some but not   none of the                       some but not   none of the   Local SMSs   a given SV,   SV, but   all non-EDR   non-EDR               all EDR Local   all EDR Local   EDR Local   respond   but all respond   respond   Local SMSs   Local SMSs   All Pooled           SMSs respond   SMSs respond   SMSs respond   successfully to   successfully to   successfully to   fail all Pooled   respond   SVs in the           successfully   successfully   successfully   all SVs   another SV   another SV   SVs   successfully   Block   Block     1      4                       4                                     Act    Act   2      4                               4                             Act/Part    Part   3      4                                       4                     Part    Part   4      4                                               4             Part    Part   5      4                                                       4     Part    Part   6              4               4                                     Part    Part   7              4                       4                             Part    Part   8              4                               4                     Part    Part   9              4                                       4             Part    Part   10              4                                               4     Part    Part   11                      4       4                                     Part    Part   12                      4               4                             Part    Part   13                      4                       4                     Part/Fail    Part   14                      4                               4             Part    Part   15                      4                                       4     Fail    Fail     Requirement Table 3-1, RR3-137.2 — Block Creation  As a summary of the table, the Block’s status will be set on Creation to:     •   Active, if ALL EDR and non-EDR Local SMSs respond successfully.      •   Failed, if ALL EDR and non-EDR Local SMSs respond unsuccessfully, or retries are exhausted.      •   Partial Failure, for all other cases.                                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-87    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-137.3   Number Pooling Block Holder Information — Synchronization of Block Status and Subscription Version Status for Block Modification    NPAC SMS shall set the status of a Block for Block Modification, based on the data contained in Table RR3-137.3. (Previously B-165.3)                                                                                  Table RR3-137.2 - Block Creation       EDR Local SMS   Non-EDR Local SMS                                               some but not                                                           all non-EDR                                                           Local SMSs   all non-EDR                                                       respond   Local SMSs                                               all non-EDR   successfully to   fail a given   some but not   none of the                       some but not   none of the   Local SMSs   a given SV,   SV, but   all non-EDR   non-EDR               all EDR Local   all EDR Local   EDR Local   respond   but all respond   respond   Local SMSs   Local SMSs   All Pooled           SMSs respond   SMSs respond   SMSs respond   successfully to   successfully to   successfully to   fail all Pooled   respond   SVs in the           successfully   successfully   successfully   all SVs   another SV   another SV   SVs   successfully   Block   Block     1      4                       4                                     Act    Act   2      4                               4                             Act    Act   3      4                                       4                     Act    Act   4      4                                               4             Act    Act   5      4                                                       4     Act    Act   6              4               4                                     Act    Act   7              4                       4                             Act    Act   8              4                               4                     Act    Act   9              4                                       4             Act    Act   10              4                                               4     Act    Act   11                      4       4                                     Act    Act   12                      4               4                             Act    Act   13                      4                       4                     Act    Act   14                      4                               4             Act    Act   15                      4                                       4     Act    Act     Requirement Table 3-2, RR3-137.3 — Block Modification  As a summary of the table, the Block’s status will be set on Modification to:     •   Active, for all cases.                                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-88    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-137.4   Number Pooling Block Holder Information — Synchronization of Block Status and Subscription Version Status for Block Deletion         NPAC SMS shall set the status of a Block for Block Deletion, based on the data contained in Table RR3-137.4. (Previously B-165.4)                                                                                  Table RR3-137.4 - Block Deletion       EDR Local SMS   Non-EDR Local SMS                                               some but not                                                           all non-EDR                                                           Local SMSs   all non-EDR                                                       respond   Local SMSs                                               all non-EDR   successfully to   fail a given   some but not   none of the                       some but not   none of the   Local SMSs   a given SV,   SV, but   all non-EDR   non-EDR               all EDR Local   all EDR Local   EDR Local   respond   but all respond   respond   Local SMSs   Local SMSs   All Pooled           SMSs respond   SMSs respond   SMSs respond   successfully to   successfully to   successfully to   fail all Pooled   respond   SVs in the           successfully   successfully   successfully   all SVs   another SV   another SV   SVs   successfully   Block   Block     1      4                       4                                     Old    Old   2      4                               4                             Old    Old   3      4                                       4                     Old    Old   4      4                                               4             Old    Old   5      4                                                       4     Old    Old   6              4               4                                     Old    Old   7              4                       4                             Old    Old   8              4                               4                     Old    Old   9              4                                       4             Old    Old   10              4                                               4     Old    Old   11                      4       4                                     Old    Old   12                      4               4                             Old    Old   13                      4                       4                     Act/Old    Old   14                      4                               4             Old    Old   15                      4                                       4     Act    Act     Requirement Table 3-3, RR3-137.4 — Block Deletion  As a summary of the table, the Block’s status will be set on Deletion to:     •   Active, if ALL EDR and non-EDR Local SMSs respond unsuccessfully, or retries are exhausted.      •   Old, for all other cases.                                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-89    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-138.1   Number Pooling Block Holder Information — Synchronization of Block Failed SP List and Subscription Version Failed SP List    NPAC SMS shall ensure that the Block Failed SP List and the Subscription Versions Failed SP Lists for Block broadcasts to EDR Local SMSs and Subscription Versions broadcasts to non-EDR Local SMSs, are synchronized, by performing the following: (Previously B-166.1)     •   The Block Failed SP List for the Block and Subscription Versions Failed SP Lists for the Subscription Versions shall cross-reference one another and contain the results of the broadcast of the Block to the EDR Local SMSs, and the broadcast of the Subscription Versions to the non-EDR Local SMSs.      •   The Subscription Versions Failed SP Lists for the Subscription Versions shall be set, based on the results of the Block broadcasts to all EDR Local SMSs and the Subscription Version broadcasts to all non-EDR Local SMSs, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted, for Activations, Modifications, and Deletions.      •   The Block Failed SP List for the Block shall be set, based on the results of the Block broadcasts to all EDR Local SMSs and the Subscription Version broadcasts to all non-EDR Local SMSs, and a response has been received by all EDR and non-EDR Local SMSs or retries have been exhausted.      •   The Block Failed SP List for the Block shall be based on the summary of all Subscription Versions with LNP Type of POOL within the 1K Block.      •   The Block Failed SP List for the Block shall reflect the information contained in Table RR3-138.2.                                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-90    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-138.2   Number Pooling Block Holder Information — Synchronization of Block Failed SP List and Subscription Version Failed SP List for Block Creation, Modification, or Deletion    NPAC SMS shall set the Block Failed SP List of a Block for updates, based on the data contained in Table RR3-138.2. (Previously B-166.2)                                                                                  Table RR3-138.2 Failed SP List       EDR Local SMS   Non-EDR Local SMS                                               some but not                                                           all non-EDR                                                           Local SMSs   all non-EDR                                                       respond   Local SMSs                                               all non-EDR   successfully to   fail a given   some but not   none of the                       some but not   none of the   Local SMSs   a given SV,   SV, but   all non-EDR   non-EDR               all EDR Local   all EDR Local   EDR Local   respond   but all respond   respond   Local SMSs   Local SMSs   All Pooled           SMSs respond   SMSs respond   SMSs respond   successfully to   successfully to   successfully to   fail all Pooled   respond   SVs in the           successfully   successfully   successfully   all SVs   another SV   another SV   SVs   successfully   Block   Block     1      4                       4                                     ZFSL    ZFSL   2      4                               4                             Z/S FSL    SFSL   3      4                                       4                     SFSL    SFSL   4      4                                               4             SFSL    SFSL   5      4                                                       4     SFSL    SFSL   6              4               4                                     SFSL    SFSL   7              4                       4                             SFSL    SFSL   8              4                               4                     SFSL    SFSL   9              4                                       4             SFSL    SFSL   10              4                                               4     SFSL    SFSL   11                      4       4                                     SFSL    SFSL   12                      4               4                             SFSL    SFSL   13                      4                       4                     S/A FSL    SFSL   14                      4                               4             SFSL    SFSL   15                      4                                       4     AFSL    AFSL     Requirement Table 3-4, RR3-138.2 — Failed SP List  Key for Table RR3-138.2 ZFSL = Zero Failed SP List (no SPs in the list) Z/S FSL = Zero/Some Failed SP List (mix of both Zero Failed SP List and Some Failed SP List) SFSL = Some but not all Failed SP List (some but not all SPs in the list) S/A FSL = Some/All Failed SP List (mix of both Some Failed SP List and All Failed SP List) AFSL = All Failed SP List (all SPs in the list)                                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-91    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-139   Number Pooling Block Holder Information – Synchronization of Block Failed SP List and Subscription Version Failed SP List for the last failed Subscription Version in the 1K Block    NPAC SMS shall remove a non-EDR Service Provider from the Block Failed SP List when the Service Provider is no longer on the Subscription Version Failed SP List for ALL subscription versions in the 1K Block. (Previously B-167)          RR3-140   Number Pooling Block Holder Information – Synchronization of Block Failed SP List and Subscription Version Failed SP List for the Block    NPAC SMS shall remove an EDR Service Provider from ALL subscription versions’ Failed SP List when the Service Provider is no longer on the Block Failed SP List. (Previously B-168)          RR3-141.1   Number Pooling Block Holder Information – Unique Error Message for Partial Failure or Failed Status Update to a Block for Block Activation Requests Initiated by NPAC Personnel    NPAC SMS shall generate a unique alarmable error message when a Block’s status is initially set to either Partial Failure or Failed, for Block Activation requests initiated by NPAC Personnel. (Previously B-169.1.1)          RR3-141.3   Number Pooling Block Holder Information – Unique Error Message for Active Status With a Failed SP List Update to a Block    NPAC SMS shall generate a unique alarmable error message when a Block’s status is updated to Active with a Failed SP List, for each occurrence, for Block Modification requests initiated by NPAC Personnel. (Previously B-169.2)          RR3-141.4   Number Pooling Block Holder Information – Unique Error Message for Old Status With a Failed SP List Update to a Block    NPAC SMS shall generate a unique alarmable error message when a Block’s status is updated to Old with a Failed SP List, for Block Deletion requests that were initiated through the NPA-NXX-X deletion by NPAC Personnel. (Previously B-169.3)          RR3-142.1   Number Pooling Block Holder Information – Block Broadcast Monitoring Mechanism    NPAC SMS shall provide a mechanism to send a recurring page to NPAC Personnel, based on a configurable interval, when a unique alarmable error message is generated as defined in RR3-141.1, RR3-141.3, or RR3-141.4. (Previously B-169.6)  Note: The configurable interval will be set by M&P.           RR3-142.2   Number Pooling Block Holder Information – Block Broadcast Monitoring Mechanism Completion    NPAC SMS shall provide a mechanism to stop the recurring page to NPAC Personnel, whenever the Block’s status is set to Active AND the Block Failed SP List is empty, or, the Block’s status is set to Old AND the Block Failed SP List is empty. (Previously B-169.7)          RR3-143   Number Pool Block Holder Information – Filters for Blocks    NPAC SMS shall apply NPA-NXX Filters to Block broadcasts to the Local SMS(s). (Previously B-560)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-92    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            3.12.3   Block Holder, Addition            RR3-144   Addition of Number Pooling Block Holder Information    NPAC SMS shall allow NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to request the creation of a Number Pooling Block. (Previously B-170)          RR3-145   Addition of Number Pool Block Holder Information – Rejected from LSMS    NPAC SMS shall reject a request to create a Block by a Service Provider via the NPAC SMS to Local SMS Interface, and will return an error message to the LSMS. (Previously B-175)          RR3-146   Addition of Number Pooling Block Holder Information – Required Data    NPAC SMS shall require NPAC personnel or Service Provider via the SOA to NPAC SMS Interface to specify the Block Holder SPID, the NPA-NXX-X, and the initial routing information, as defined in the Number Pooling Block Holder Information. (Previously B-180)          RR3-147   Addition of Number Pooling Block Holder Information – Check for pending-like SVs for NPAC Personnel    NPAC SMS shall reject the request and issue a unique alarmable error message to the NPAC personnel at the time of Block Creation for an NPAC initiated request, from the NPAC Administrative Interface, if there are any TNs within the 1K Block, that contain an SV, with a status of pending/conflict/cancel-pending/failed, and where a currently active SV does NOT exist, for the given TN. (Previously B-190)          RR3-148   Addition of Number Pooling Block Holder Information – Error Message to SOA for pending-like SVs    NPAC SMS shall reject the request and issue an error message to the SOA at the time of Block Creation from the SOA via the SOA to NPAC SMS Interface, if there are any TNs within the 1K Block, that contain an SV, for a given TN in the 1K Block, with a status of pending/conflict/cancel-pending/failed, and where a currently active SV does NOT exist, for the given TN. (Previously B-210)          RR3-149   Addition of Number Pooling Block Holder Information – Field-level Data Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, is valid according to the formats specified in the Subscription Version Data Model upon Block creation for a Number Pool: (Previously B-250, reference NANC 399)  NPA-NXX-X Holder SPID NPA-NXX-X LRN Class DPC Class SSN LIDB DPC LIDB SSN CNAM DPC CNAM SSN ISVM DPC                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-93    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration    ISVM SSN WSMSC DPC (if supported by the Block Holder SOA) WSMSC SSN (if supported by the Block Holder SOA) Number Pool Block SV Type (if supported by the Block Holder SOA) Alternative SPID (if supported by the Block Holder SOA)          RR3-150   Addition of Number Pooling Block Holder Information – Broadcast of Block Data    NPAC SMS shall, upon successfully creating a Block, set the Block’s status to sending, and broadcast an addition of a Block, to EDR Local SMSs, via the NPAC SMS to Local SMS Interface. (Previously B-260)          RR3-151   Addition of Number Pooling Block Holder Information – Activation Broadcast Complete Timestamp Update    NPAC SMS shall update the Activation Broadcast Complete Timestamp of the Block upon completion of the broadcast, and the FIRST successful response, for either an EDR or non-EDR Local SMS. (Previously B-265)          RR3-152   Addition of Number Pooling Block Holder Information – Status Update    NPAC SMS shall update the status of the Block upon completion of the Activation broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.2. (Previously B-270)          RR3-153   Addition of Number Pooling Block Holder Information – Failed SP List Update    NPAC SMS shall update the Block Failed SP List upon completion of the Activation broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1, and RR3-138.2. (Previously B-275)          RR3-496   Activate Number Pool Block — Send Number Pool Block SV Type Data to Local SMSs    NPAC SMS shall, for a Service Provider that supports SV Type data, send the Number Pool Block SV Type attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 15)          RR3-497   Activate Number Pool Block — Send Alternative SPID to Local SMSs    NPAC SMS shall, for a Service Provider that supports Alternative SPID, send the Alternative SPID attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 16)          3.12.4   Block Holder, Modification                    NPAC SMS shall allow NPAC Personnel to modify the SOA Origination Indicator on the NPAC Block record, via the NPAC Administrative Interface. (Previously B-315)                                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    3-94    North American Numbering Council (NANC) Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC Data Administration            RR3-155   Block’s SOA Origination Indicator — Suppress Broadcast    NPAC SMS shall suppress the broadcast to a Local SMS, of a modification to a Block’s SOA Origination Indicator. (Previously B-317)  RR3-156 Block’s SOA Origination Indicator — Suppress Creation When False  NPAC SMS shall suppress the creation of a Block modification notification, when the Block’s SOA Origination Indicator is modified to FALSE. (Previously B-318)          RR3-157   Modification of Number Pooling Block Holder Information — Routing Data    NPAC SMS shall allow NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to modify the block holder default routing information (LRN, DPC(s), and SSN(s)), Number Pool Block SV Type (if supported by the Block Holder SOA), and, Alternative SPID (if supported by the Block Holder SOA), for a 1K Block as stored in the NPAC SMS. (Previously B-320, reference NANC 399)          RR3-158   Modification of Number Pool Block Holder Information — Rejected from LSMS    NPAC SMS shall reject a request to modify a Block by a Service Provider via the NPAC SMS to Local SMS Interface, and will return an error message to the LSMS. (Previously B-325)          RR3-159   Modification of Number Pooling Block Holder Information — SPID Validation    NPAC SMS shall allow a Service Provider via the SOA to NPAC SMS Interface or Service Provider via the NPAC SOA Low-tech Interface, to modify Block data for Blocks where the Block Holder SPID matches the Service Provider making the request. (Previously B-330)          RR3-160   Modification of Number Pooling Block Holder Information — Selection Criteria    NPAC SMS shall allow a Service Provider via the SOA to NPAC SMS Interface, to modify Block data by specifying either Block ID, or NPA-NXX-X value and status, in the request. (Previously B-332)          RR3-161   Modification of Number Pooling Block Holder Information — Current status and Failed SP List    NPAC SMS shall reject and issue an error message to NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, when modifying block holder data, for a 1K Block as stored in the NPAC SMS, and the Block’s current status is not active, or the Block has at least one Service Provider in the Failed SP List. (Previously B-335)           RR3-162   Modification of Number Pooling Block Holder Information — Sending Status Update    NPAC SMS shall, upon processing a valid request to modify a Block, update the status of the Block, at the start of the broadcast of a Block modification to the Local SMSs, from an active status to a sending status. (Previously B-340)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-95    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-163   Modification of Number Pooling Block Holder Information — Broadcast of Block Data    NPAC SMS shall, upon successfully modifying a Block and setting the Block’s status to sending, broadcast a modification of a Block to EDR Local SMSs, via the NPAC SMS to Local SMS Interface. (Previously B-350)          RR3-164   Modification of Number Pooling Block Holder Information — Modify Broadcast Complete Timestamp Update    NPAC SMS shall update the Modify Broadcast Complete Timestamp of the Block upon completion of the broadcast, and the FIRST successful response, for either an EDR or non-EDR Local SMS. (Previously B-355)          RR3-165   Modification of Number Pooling Block Holder Information —Status Update    NPAC SMS shall update the status of the Block upon completion of the Modification broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.3. (Previously B-360)          RR3-166   Modification of Number Pooling Block Holder Information — Failed SP List Update    NPAC SMS shall update the Block Failed SP List upon completion of the broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1, and 3-138.2. (Previously B-370)          RR3-167   Modification of Number Pooling Block Holder Information — Creation of Old Block    DELETED          RR3-168   Modification of Number Pooling Block Holder Information — Old Block No Broadcast    DELETED  3.12.5 Block Holder, Deletion          RR3-169   Deletion of Number Pool Block Holder Information — NPAC    NPAC SMS shall not allow NPAC Personnel to request a delete of a Block in the NPAC SMS.  Note: This is initiated at the NPA-NXX-X level, and is part of a multi-step “cascading delete” process. (Previously B-400)          RR3-170   Deletion of Number Pool Block Holder Information — SOA    NPAC SMS shall reject a request to delete a Block by a Service Provider via the SOA to NPAC SMS interface, and will return an error message to the SOA. (Previously B-410)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-96    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-171   Deletion of Number Pool Block Holder Information — Rejected from LSMS    NPAC SMS shall reject a request to delete a Block by a Service Provider via the NPAC SMS to Local SMS Interface, and will return an error message to the LSMS. (Previously B-412)          RR3-172   Deletion of Number Pool Block Holder Information — LTI    NPAC SMS shall not allow Service Provider Personnel to request a delete of a Block in the NPAC SMS via the NPAC SOA Low-tech Interface. (Previously B-415)          RR3-173   Deletion of Number Pooling NPA-NXX-X Holder Information — Sending Status Update to Block    NPAC SMS shall, upon processing a valid request to delete an NPA-NXX-X, update the status of the Block at the start of the broadcast to the Local SMSs, from an active status to a sending status. (Previously B-430)          RR3-174   Deletion of Number Pool NPA-NXX-X Holder Information — Broadcast of Block Data    NPAC SMS shall, upon setting the Block’s status to sending, broadcast a delete of a Block, to EDR LSMSs, via the NPAC SMS to Local SMS Interface. (Previously B-440)          RR3-175   Deletion of Number Pooling Block Holder Information — Disconnect Complete Timestamp Update    NPAC SMS shall update the Disconnect Complete Timestamp of the Block upon completion of the broadcast, and the FIRST successful response, for either an EDR or non-EDR Local SMS. (Previously B-445)          RR3-176   Deletion of Number Pooling NPA-NXX-X Holder Information — Status Update to Block    NPAC SMS shall update the status of the Block upon completion of the Deletion broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.4. (Previously B-450)          RR3-177   Deletion of Number Pooling NPA-NXX-X Holder Information — Failed SP List Update    NPAC SMS shall update the Block Failed SP List upon completion of the broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1, and RR3-138.2. (Previously B-480)          RR3-178   Deletion of Number Pooling NPA-NXX-X Holder Information — Creation of Old Block    DELETED          RR3-179   Deletion of Number Pooling NPA-NXX-X Holder Information — Old Block No Broadcast    DELETED                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-97    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration    3.12.6 Block Holder, Query          RR3-180   Query of Number Pool Block Holder Information — NPAC Personnel    NPAC SMS shall allow NPAC Personnel to query the block holder information for all data as listed in the Block Holder Information Data Model, for a 1K Block as stored in the NPAC SMS. (Previously B-555)          RR3-181   Query of Number Pool Block Holder Information — Service Provider Personnel    NPAC SMS shall allow a Service Provider SOA via the SOA to NPAC SMS Interface, Service Provider Local SMS via the NPAC SMS to Local SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to query Block Holder Information, regardless of the value in the requesting Service Provider’s EDR Indicator. (Previously B-556)          RR3-182   Query of Number Pool Filtered Block Holder Information — Query Block    NPAC SMS shall return, to the NPAC Personnel or requesting Service Provider, all Block data supported by the requestor that match the query selection criteria. (Previously B-557)  3.12.7 Block Holder, Default Routing Restoration          RR3-183   Number Pool Block Holder Information Use of Number Pool Default Routing Information — Existing Block    The NPAC SMS shall use the default routing restoration information in the Number Pooling Block Holder Information as the block holder default routing, when a ported pooled number is disconnected or port to original port is activated, and returns the TN(s) to the block, once the Block exists, except for Old with or without a Failed SP List. (Previously B-570)          RR3-184   Number Pool Block Holder Information Use of Number Pool Notification of TN Re-assignment — During De-Pooling    The NPAC SMS shall send a notification to the Code Holder, and suppress the notification to the Block Holder, when a ported pooled number is disconnected, for TN(s) in the block, when the Block is being de-pooled, and the most recent block contains a status of Old, with a Failed SP List. (Previously B-571)  Note: The notifications characteristics for a disconnect of a ported pooled number, during de-pooling of a Block, with a Block that contains a status of Old with a Failed SP List, is additional functionality that defines Code Holder responsibility and notification messages. In essence, even though the de-pooled Block (i.e., contains a status of Old with a Failed SP List) is post-effective date, it has the behavior of a Block that has NOT been pooled and is in a pre-effective date stage. Also, the customer disconnect date notification is going to the Code Holder, but the TN cannot be re-assigned in their inventory.                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-98    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration    3.12.8 Block Holder, Re-Send          RR3-185   Re-Send of Number Pool Block Holder Information — Filters for Blocks    NPAC SMS shall apply NPA-NXX Filters to Block re-sends to the Local SMS(s). (Previously B-574)          RR3-186.1   Re-Send of Number Pooling Block Holder Information — NPAC Personnel OpGUI Single Block    NPAC SMS shall allow NPAC Personnel to re-send Block Information, one Block at a time, via the NPAC Administrative Interface. (B-575.1)          RR3-186.2   Re-Send of Number Pooling Block Holder Information — NPAC Personnel OpGUI One or All Service Providers    NPAC SMS shall allow NPAC Personnel to re-send Block Information, to a single Service Provider or all Service Providers in the Block Failed SP List, via the NPAC Administrative Interface. (Previously B-575.2)          RR3-187   Re-Send of Number Pooling Block Holder Information — Use of EDR Indicator for Re-Send data    NPAC SMS shall use the value in the Service Provider’s EDR Indicator to determine the type of data to re-send to the Service Provider, when a re-send request is initiated. (Previously B-576)          RR3-188    Re-Send of Number Pooling Block Holder Information — Re-Send to EDR Local SMS    NPAC SMS shall re-send Block Information to an EDR Local SMS, by re-sending the previously failed Block Object, via the NPAC SMS to Local SMS Interface. (Previously B-577)          RR3-189   Re-Send of Number Pooling Block Holder Information — Re-Send to non-EDR Local SMS    NPAC SMS shall re-send Block Information to a non-EDR Local SMS, by re-sending the previously failed Subscription Version(s), via the NPAC SMS to Local SMS Interface. (Previously B-578)          RR3-190   Re-Send of Number Pooling Block Holder Information — Failed Block Status Set to Sending    NPAC SMS shall update the status of the failed Block, specified in the re-send request, at the start of the re-send to the Local SMSs, from a failed status to a sending status. (Previously B-580)          RR3-191   Re-Send of Number Pooling Block Holder Information — Partial Failure Block Status Set to Sending    NPAC SMS shall update the status of the partial failure Block, specified in the re-send request, at the start of the re-send to the Local SMSs, from a partial failure status to a sending status. (Previously B-590)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-99    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-192   Re-Send of Number Pooling Block Holder Information — Sending Status Update to Active Block    NPAC SMS shall update the status of the active Block, with a Failed SP List, specified in the re-send request, at the start of the re-send to the Local SMSs, from an active status to a sending status. (Previously B-600)          RR3-193   Re-Send of Number Pooling Block Holder Information — Sending Status Update to Old Block    NPAC SMS shall update the status of the old Block, with a Failed SP List, specified in the re-send request, at the start of the re-send to the Local SMSs, from an old status to a sending status. (Previously B-610)          RR3-194   Re-Send of Number Pool Block Holder Information — Broadcast of Block Data    NPAC SMS shall, upon setting the Block’s status to sending, broadcast a re-send of a Block, to EDR LSMSs, via the NPAC SMS to Local SMS Interface. (Previously B-620)          RR3-195   Re-Send of Number Pooling Block Holder Information — Update to Failed SP List    NPAC SMS shall update the Block Failed SP List of the Block and the Subscription Version Failed SP List of each Subscription Version with LNP Type of POOL, by removing the previously failed Local SMS, upon a successful re-send to a previously failed Local SMS. (Previously B-630)          RR3-196   Re-Send of Number Pooling Block Holder Information —Status Update to Block after Re-Send    NPAC SMS shall update the status of the Block, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS or if retries have been exhausted, from a sending status, as defined in RR3-137.1, RR3-137.2, RR3-137.3, and RR3-137.4. (Previously B-635)          RR3-197   Re-Send of Number Pooling Block Holder Information — Failed SP List Update    NPAC SMS shall update the Block Failed SP List, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS or if retries have been exhausted, as defined in RR3-138.1, and RR3-138.2. (Previously B-636)          RR3-472   Number Pool Block Failed SP List — Exclusion of a Service Provider from Resend    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to request that a Service Provider be excluded from the Number Pool Block Failed SP List when resending a number pool block and the associated subscription version(s) of LNP type POOL, and not broadcast to the Service Provider that is excluded. (previously NANC 300, Req 1)          RR3-473   Number Pool Block Failed SP List — Logging of an Excluded Service Provider    NPAC SMS shall log the following information when a Service Provider is excluded from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface: date, time, excluded SPID, Blockholder SPID, NPA-NXX-X, Number Pool Block ID. (previously NANC 300, Req 2)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-100    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration    3.12.9 Block Holder, Bulk Data Downloads  This section has MOVED to section 3.12.5 Block Holder, Bulk Data Downloads. Requirement numbers remain static.                RR3-198    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-199    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-200.1    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-200.2    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-200.3    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-201.1    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-201.2    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-202    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-203    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-204)    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-205    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-206    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.           RR3-207    MOVED to section 3.12.5 Block Holder, Bulk Data Downloads.       3.13 Linked Action Replies  The following section defines tunable parameters that enable Linked Action Replies to be sent to Service Provider systems that support this functionality, during recovery. The actual Linked Reply functionality is discussed specifically within the Recovery section of this document.          RR3-336   NPAC Customer SOA Linked Replies Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving Service Provider, Network and Notification Recovery Responses as Linked Replies to their SOA, via the SOA to NPAC SMS Interface. (Previously NANC 187 Req 1)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-101    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-337   NPAC Customer SOA Linked Replies Indicator — Default    NPAC SMS shall default the SOA Linked Replies Indicator to FALSE. (Previously NANC 187 Req 2)          RR3-338   NPAC Customer SOA Linked Replies Indicator — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the SOA Linked Replies Indicator on the NPAC Customer record. (Previously NANC 187 Req 3)          RR3-339   NPAC Customer Local SMS Linked Replies Indicator    NPAC SMS shall provide a mechanism to indicate whether a Service Provider supports receiving Service Provider, Network, Subscription, and Notification Recovery Responses as Linked Replies to their Local SMS, via the NPAC SMS to Local SMS Interface. (Previously NANC 187 Req 6)          RR3-340   NPAC Customer Local SMS Linked Replies Indicator — Default    NPAC SMS shall default the Local SMS Linked Replies Indicator to FALSE. (Previously NANC 187 Req 7)          RR3-341   NPAC Customer Local SMS Linked Replies Indicator — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Local SMS Linked Replies Indicator on the NPAC Customer record. (Previously NANC 187 Req 8)          RR3-342   Service Provider and Network Data Linked Replies Blocking Factor — Tunable Parameter    NPAC SMS shall provide a Service Provider and Network Data Linked Replies Blocking Factor tunable parameter which is defined as the number of objects in a single linked reply sent in response to a service provider or network data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 12)          RR3-343   Service Provider and Network Data Linked Replies Blocking Factor — Tunable Parameter Default    NPAC SMS shall default the Service Provider and Network Data Linked Replies Blocking Factor tunable parameter to fifty (50) objects. (Previously NANC 187 Req 13)          RR3-344   Service Provider and Network Data Linked Replies Blocking Factor — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider and Network Data Linked Replies Blocking Factor tunable parameter. (Previously NANC 187 Req 14)          RR3-345   Subscription Data Linked Replies Blocking Factor — Tunable Parameter    NPAC SMS shall provide a Subscription Data Linked Replies Blocking Factor tunable parameter which is defined as the number of objects in a single linked reply sent in response to a subscription data recovery request sent by a LSMS, when the LSMS supports Linked Replies. (Previously NANC 187 Req 17)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-102    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-346   Subscription Data Linked Replies Blocking Factor — Tunable Parameter Default    NPAC SMS shall default the Subscription Data Linked Replies Blocking Factor tunable parameter to fifty (50) objects. (Previously NANC 187 Req 18)          RR3-347   Subscription Data Linked Replies Blocking Factor — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Subscription Data Linked Replies Blocking Factor tunable parameter. (Previously NANC 187 Req 19)          RR3-348   Notification Data Linked Replies Blocking Factor — Tunable Parameter    NPAC SMS shall provide a Notification Data Linked Replies Blocking Factor tunable parameter which is defined as the number of notifications in a single linked reply sent in response to a notification data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 21)          RR3-349   Notification Data Linked Replies Blocking Factor — Tunable Parameter Default    NPAC SMS shall default the Notification Data Linked Replies Blocking Factor tunable parameter to fifty (50) notifications. (Previously NANC 187 Req 22)          RR3-350   Notification Data Linked Replies Blocking Factor — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Notification Data Linked Replies Blocking Factor tunable parameter. (Previously NANC 187 Req 23)          RR3-430   Number Pool Block Data Linked Replies Blocking Factor — Tunable Parameter    NPAC SMS shall provide a Number Pool Block Data Linked Replies Blocking Factor tunable parameter which is defined as the number of objects in a single linked reply sent in response to a number pool block data recovery request sent by a LSMS, when the LSMS supports Linked Replies. (Previously related to NANC 187)          RR3-431   Number Pool Block Data Linked Replies Blocking Factor — Tunable Parameter Default    NPAC SMS shall default the Number Pool Block Data Linked Replies Blocking Factor tunable parameter to fifty (50) objects. (Previously related to NANC 187)          RR3-432   Number Pool Block Data Linked Replies Blocking Factor — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Number Pool Block Data Linked Replies Blocking Factor tunable parameter. (Previously related to NANC 187).          RR3-351   Service Provider and Network Data Maximum Linked Recovered Objects — Tunable Parameter    NPAC SMS shall provide a Service Provider and Network Data Maximum Linked Recovered Objects tunable parameter which is defined as the maximum number of objects sent in response to service provider or network data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 26)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-103    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-352   Service Provider and Network Data Maximum Linked Recovered Objects — Tunable Parameter Default    NPAC SMS shall default the Service Provider and Network Data Maximum Linked Recovered Objects tunable parameter to ten thousand (10,000) objects. (Previously NANC 187 Req 27)          RR3-353   Service Provider and Network Data Maximum Linked Recovered Objects — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider and Network Data Maximum Linked Recovered Objects tunable parameter. (Previously NANC 187 Req 28)          RR3-354   Subscription Data Maximum Linked Recovered Objects — Tunable Parameter    NPAC SMS shall provide a Subscription Data Maximum Linked Recovered Objects tunable parameter which is defined as the maximum number of objects sent in response to a subscription data recovery request sent by an LSMS, when the LSMS supports Linked Replies. (Previously NANC 187 Req 31)          RR3-355   Subscription Data Maximum Linked Recovered Objects — Tunable Parameter Default    NPAC SMS shall default the Subscription Data Maximum Linked Recovered Objects tunable parameter to ten thousand (10,000) objects. (Previously NANC 187 Req 32)          RR3-356   Subscription Data Maximum Linked Recovered Objects — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Subscription Data Maximum Linked Recovered Objects tunable parameter. (Previously NANC 187 Req 33)          RR3-357   Notification Data Maximum Linked Recovered Notifications — Tunable Parameter    NPAC SMS shall provide a Notification Data Maximum Linked Recovered Notifications tunable parameter which is defined as the maximum number of notifications sent in response to a notification data recovery request sent by a SOA/LSMS, when the SOA/LSMS supports Linked Replies. (Previously NANC 187 Req 35)          RR3-358   Notification Data Maximum Linked Recovered Notifications — Tunable Parameter Default    NPAC SMS shall default the Notification Data Maximum Linked Recovered Notifications tunable parameter to two thousand (2,000) notifications. (Previously NANC 187 Req 36)          RR3-359   Notification Data Maximum Linked Recovered Notifications — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Notification Data Maximum Linked Recovered Notifications tunable parameter. (Previously NANC 187 Req 37)          RR3-433   Number Pool Block Data Maximum Linked Recovered Objects — Tunable Parameter    NPAC SMS shall provide a Number Pool Block Data Maximum Linked Recovered Objects tunable parameter which is defined as the maximum number of objects sent in response to a number pool block recovery request sent by an LSMS, when the LSMS supports Linked Replies. (Previously related to NANC 187)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-104    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-434   Number Pool Block Data Maximum Linked Recovered Objects — Tunable Parameter Default    NPAC SMS shall default the Number Pool Block Data Maximum Linked Recovered Objects tunable parameter to ten thousand (10,000) objects. (Previously related to NANC 187).          RR3-435   Number Pool Block Data Maximum Linked Recovered Objects — Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Number Pool Block Data Maximum Linked Recovered Objects tunable parameter. (Previously related to NANC 187)    3.14 GTT Validation Processing by the NPAC SMS  This section describes how the NPAC SMS performs a variety of GTT validation for Subscription Versions and Number Pool Blocks in an effort to support SS7 signaling guidelines for Local Number Portability. Some GTT validation occurs based on regional tunables that reflect inter-Service Provider service level agreements, while other validations occur globally regardless of any tunable setting.  3.14.1 Sub System Number (SSN) Edit Flag Indicator  The following section defines tunable parameters that allow the NPAC SMS to impose edits and prevent Subscription Version and Number Pool Block processing that contain GTT data that cannot be processed by certain Service Providers based on regional agreements. These indicators are set and applied regionally. This section also identifies how the NPAC SMS applies GTT validation to Subscription Version and Number Pool Block processing based on the indicator settings.          RR3-360   DPC/SSN Edits — CLASS SSN Edit Flag Indicator    NPAC SMS shall provide a CLASS SSN Edit Flag Indicator, which is defined as an indicator on whether or not CLASS DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 1)          RR3-361   DPC/SSN Edits — LIDB SSN Edit Flag Indicator    NPAC SMS shall provide a LIDB SSN Edit Flag Indicator, which is defined as an indicator on whether or not LIDB DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 2)          RR3-362   DPC/SSN Edits — CNAM SSN Edit Flag Indicator    NPAC SMS shall provide a CNAM SSN Edit Flag Indicator, which is defined as an indicator on whether or not CNAM DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 3)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-105    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-363   DPC/SSN Edits — ISVM SSN Edit Flag Indicator    NPAC SMS shall provide a ISVM SSN Edit Flag Indicator, which is defined as an indicator on whether or not ISVM DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 4)          RR3-364   DPC/SSN Edits — WSMSC SSN Edit Flag Indicator    NPAC SMS shall provide a WSMSC SSN Edit Flag Indicator, which is defined as an indicator on whether or not WSMSC DPC/SSN consistency edits will be enforced by the NPAC SMS, upon Subscription Version or Number Pool Block Creation, Modification, or mass update. (Previously NANC 291 Req 5)          RR3-365   DPC/SSN Edits — CLASS SSN Edit Flag Indicator — OpGUI Modification    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the CLASS SSN Edit Flag Indicator. (Previously NANC 291 Req 11)          RR3-366   DPC/SSN Edits — LIDB SSN Edit Flag Indicator — OpGUI Modification    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the LIDB SSN Edit Flag Indicator. (Previously NANC 291 Req 12)          RR3-367   DPC/SSN Edits — CNAM SSN Edit Flag Indicator — OpGUI Modification    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the CNAM SSN Edit Flag Indicator. (Previously NANC 291 Req 13)          RR3-368   DPC/SSN Edits — ISVM SSN Edit Flag Indicator — OpGUI Modification    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the ISVM SSN Edit Flag Indicator. (Previously NANC 291 Req 14)          RR3-369   DPC/SSN Edits — WSMSC SSN Edit Flag Indicator — OpGUI Modification    NPAC SMS shall allow the NPAC Personnel, via the NPAC Administrative Interface, to modify the WSMSC SSN Edit Flag Indicator. (Previously NANC 291 Req 15)          RR3-370   DPC/SSN Edits — CLASS SSN Edit Flag Indicator Default    NPAC SMS shall default the CLASS SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 16)          RR3-371   DPC/SSN Edits — LIDB SSN Edit Flag Indicator Default    NPAC SMS shall default the LIDB SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 17)          RR3-372   DPC/SSN Edits — CNAM SSN Edit Flag Indicator Default    NPAC SMS shall default the CNAM SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 18)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-106    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-373   DPC/SSN Edits — ISVM SSN Edit Flag Indicator Default    NPAC SMS shall default the ISVM SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 19)          RR3-374   DPC/SSN Edits — WSMSC SSN Edit Flag Indicator Default    NPAC SMS shall default the WSMSC SSN Edit Flag Indicator to TRUE. (Previously NANC 291 Req 20)          RR3-375   DPC/SSN Edits — CLASS SSN Rejection for Non-Zero Value    NPAC SMS shall, based on the CLASS SSN Edit Flag Indicator for CLASS service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the CLASS Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding CLASS Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 6)          RR3-376   DPC/SSN Edits — LIDB SSN Rejection for Non-Zero Value    NPAC SMS shall, based on the LIDB SSN Edit Flag Indicator for LIDB service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the LIDB Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding LIDB Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 7)          RR3-377   DPC/SSN Edits — CNAM SSN Rejection for Non-Zero Value    NPAC SMS shall, based on the CNAM SSN Edit Flag Indicator for CNAM service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the CNAM Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding CNAM Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 8)          RR3-378   DPC/SSN Edits — ISVM SSN Rejection for Non-Zero Value    NPAC SMS shall, based on the ISVM SSN Edit Flag Indicator for ISVM service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the ISVM Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding ISVM Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 9)          RR3-379   DPC/SSN Edits — WSMSC SSN Rejection for Non-Zero Value    NPAC SMS shall, based on the WSMSC SSN Edit Flag Indicator for WSMSC service when the value is TRUE, reject a Subscription Version or Number Pool Block Creation, Modification of any data, Activation, or mass update of any data, when the WSMSC Destination Point Code (DPC) for that specific service contains a value (network 001-255, cluster 000-255, member 000-255), and the corresponding WSMSC Sub-System Number (SSN) is not a zero (000) value. (Previously NANC 291 Req 10)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-107    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration    3.14.2 Global GTT Validations  The following section describes how the NPAC SMS validates GTT contained within Subscription Version and Number Pooling requests. These validations occur outside of any tunable setting on the NPAC SMS.          RR3-380   Subscription Version — Verify CLASS SSN when CLASS DPC is populated    NPAC SMS shall verify the CLASS Sub-System Number (SSN) contains a value between 000-255 when the corresponding CLASS Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 1)          RR3-381   Subscription Version — Verify LIDB SSN when LIDB DPC is populated    NPAC SMS shall verify the LIDB Sub-System Number (SSN) contains a value between 000-255 when the corresponding LIDB Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 2)          RR3-382   Subscription Version — Verify CNAM SSN when CNAM DPC is populated    NPAC SMS shall verify the CNAM Sub-System Number (SSN) contains a value between 000-255 when the corresponding CNAM Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 3)          RR3-383   Subscription Version — Verify ISVM SSN when ISVM DPC is populated    NPAC SMS shall verify the ISVM Sub-System Number (SSN) contains a value between 000-255 when the corresponding ISVM Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 4)          RR3-384   Subscription Version — Verify WSMSC SSN when WSMSC DPC is populated    NPAC SMS shall verify the WSMSC Sub-System Number (SSN) contains a value between 000-255 when the corresponding WSMSC Destination Point Code (DPC) is populated with values for network value between 001-255, for cluster value between 000-255, and for member value between 000-255, from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 5)          RR3-385   Subscription Version — Verify CLASS DPC when CLASS SSN is populated    NPAC SMS shall verify the CLASS Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CLASS Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 6)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-108    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-386   Subscription Version — Verify LIDB DPC when LIDB SSN is populated    NPAC SMS shall verify the LIDB Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding LIDB Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 7)          RR3-387   Subscription Version — Verify CNAM DPC when CNAM SSN is populated    NPAC SMS shall verify the CNAM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CNAM Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 8)          RR3-388   Subscription Version — Verify ISVM DPC when ISVM SSN is populated    NPAC SMS shall verify the ISVM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding ISVM Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 9)          RR3-389   Subscription Version — Verify WSMSC DPC when WSMSC SSN is populated    NPAC SMS shall verify the WSMSC Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding WSMSC Sub-System Number (SSN) is populated with a value (000-255), from the new Service Provider in a Subscription Version creation, modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 10)          RR3-390   Number Pool Block — Verify CLASS SSN when CLASS DPC is populated    NPAC SMS shall verify the CLASS Sub-System Number (SSN) contains a value (000-255) when the corresponding CLASS Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 11)          RR3-391   Number Pool Block — Verify LIDB SSN when LIDB DPC is populated    NPAC SMS shall verify the LIDB Sub-System Number (SSN) contains a value (000-255) when the corresponding LIDB Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 12)          RR3-392   Number Pool Block — Verify CNAM SSN when CNAM DPC is populated    NPAC SMS shall verify the CNAM Sub-System Number (SSN) contains a value (000-255) when the corresponding CNAM Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 13)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-109    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-393   Number Pool Block — Verify ISVM SSN when ISVM DPC is populated    NPAC SMS shall verify the ISVM Sub-System Number (SSN) contains a value (000-255) when the corresponding ISVM Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 14)          RR3-394   Number Pool Block — Verify WSMSC SSN when WSMSC DPC is populated    NPAC SMS shall verify the WSMSC Sub-System Number (SSN) contains a value (000-255) when the corresponding WSMSC Destination Point Code (DPC) is populated with values (network 001-255, cluster 000-255, member 000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 15)          RR3-395   Number Pool Block — Verify CLASS DPC when CLASS SSN is populated    NPAC SMS shall verify the CLASS Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CLASS Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 16)          RR3-396   Number Pool Block — Verify LIDB DPC when LIDB SSN is populated    NPAC SMS shall verify the LIDB Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding LIDB Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 17)          RR3-397   Number Pool Block — Verify CNAM DPC when CNAM SSN is populated    NPAC SMS shall verify the CNAM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding CNAM Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 18)          RR3-398   Number Pool Block — Verify ISVM DPC when ISVM SSN is populated    NPAC SMS shall verify the ISVM Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding ISVM Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 19)          RR3-399   Number Pool Block — Verify WSMSC DPC when WSMSC SSN is populated    NPAC SMS shall verify the WSMSC Destination Point Code (DPC) contains values (network 001-255, cluster 000-255, member 000-255) when the corresponding WSMSC Sub-System Number (SSN) is populated with a value (000-255), from the Block Holder Service Provider in a Block creation, modification, or mass update for Number Pooling. (Previously NANC 191 Req 20)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-110    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-400   DPC/SSN Edits — CLASS validation failure    NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for CLASS fails validation. (Previously NANC 191 Req 21)          RR3-401   DPC/SSN Edits — LIDB validation failure    NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for LIDB fails validation. (Previously NANC 191 Req 22)          RR3-402   DPC/SSN Edits — CNAM validation failure    NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for CNAM fails validation. (Previously NANC 191 Req 23)          RR3-403   DPC/SSN Edits — ISVM validation failure    NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for ISVM fails validation. (Previously NANC 191 Req 24)          RR3-404   DPC/SSN Edits — WSMSC validation failure    NPAC SMS shall send back an error to the requesting Service Provider if a Subscription Version or Number Pool Block DPC/SSN consistency check for WSMSC fails validation. (Previously NANC 191 Req 25)          RR3-405   DPC/SSN Edits — CLASS DPC and SSN Required Data for Modification    NPAC SMS shall require values from the requesting Service Provider for both CLASS DPC and CLASS SSN to be sent to the NPAC SMS when modifying CLASS service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 26)          RR3-406   DPC/SSN Edits — LIDB DPC and SSN Required Data for Modification    NPAC SMS shall require values from the requesting Service Provider for both LIDB DPC and LIDB SSN to be sent to the NPAC SMS when modifying LIDB service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 27)          RR3-407   DPC/SSN Edits — CNAM DPC and SSN Required Data for Modification    NPAC SMS shall require values from the requesting Service Provider for both CNAM DPC and CNAM SSN to be sent to the NPAC SMS when modifying CNAM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 28)          RR3-408   DPC/SSN Edits — ISVM DPC and SSN Required Data for Modification    NPAC SMS shall require values from the requesting Service Provider for both ISVM DPC and ISVM SSN to be sent to the NPAC SMS when modifying ISVM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 29)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-111    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-409   DPC/SSN Edits — WSMSC DPC and SSN Required Data for Modification    NPAC SMS shall require values from the requesting Service Provider for both WSMSC DPC and WSMSC SSN to be sent to the NPAC SMS when modifying WSMSC service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 30)          RR3-410   DPC/SSN Edits — CLASS DPC and SSN Required Data for Mass Update    NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both CLASS DPC and CLASS SSN to be provided when mass updating CLASS service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 31)          RR3-411   DPC/SSN Edits — LIDB DPC and SSN Required Data for Mass Update    NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both LIDB DPC and LIDB SSN to be provided when mass updating LIDB service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 32)          RR3-412   DPC/SSN Edits — CNAM DPC and SSN Required Data for Mass Update    NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both CNAM DPC and CNAM SSN to be provided when mass updating CNAM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 33)          RR3-413   DPC/SSN Edits — ISVM DPC and SSN Required Data for Mass Update    NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both ISVM DPC and ISVM SSN to be provided when mass updating ISVM service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 34)          RR3-414   DPC/SSN Edits — WSMSC DPC and SSN Required Data for Mass Update    NPAC SMS shall require values from the NPAC Personnel for the requesting Service Provider for both WSMSC DPC and WSMSC SSN to be provided when mass updating WSMSC service for a Subscription Version or Number Pool Block, even if only one value is being modified. (Previously NANC 191 Req 35)          RR3-415   Subscription Version — Verify All Routing Data When Modifying Non-GTT Data    NPAC SMS shall when modifying non-GTT data, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 36)          RR3-416   Subscription Version — Verify All Routing Data When Modifying CLASS Data    NPAC SMS shall when modifying CLASS DPC or CLASS SSN, reject the modify request for any DPC/SSN value edit inconsistencies for LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 37)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-112    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-417   Subscription Version — Verify All Routing Data When Modifying LIDB Data    NPAC SMS shall when modifying LIDB DPC or LIDB SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 38)          RR3-418   Subscription Version — Verify All Routing Data When Modifying CNAM Data    NPAC SMS shall when modifying CNAM DPC or CNAM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, ISVM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 39)          RR3-419   Subscription Version — Verify All Routing Data When Modifying ISVM Data    NPAC SMS shall when modifying ISVM DPC or ISVM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or WSMSC, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 40)          RR3-420   Subscription Version — Verify All Routing Data When Modifying WSMSC Data    NPAC SMS shall when modifying WSMSC DPC or WSMSC SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or ISVM, from the new/current Service Provider in a Subscription Version modification, or mass update for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 41)          RR3-421   Number Pool Block — Verify All Routing Data When Modifying Non-GTT Data    NPAC SMS shall when modifying non-GTT data, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 42)          RR3-422   Number Pool Block — Verify All Routing Data When Modifying CLASS Data    NPAC SMS shall when modifying CLASS DPC or CLASS SSN, reject the modify request for any DPC/SSN value edit inconsistencies for LIDB, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 43)          RR3-423   Number Pool Block — Verify All Routing Data When Modifying LIDB Data    NPAC SMS shall when modifying LIDB DPC or LIDB SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, CNAM, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 44)                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-113    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             NPAC Data Administration            RR3-424   Number Pool Block — Verify All Routing Data When Modifying CNAM Data    NPAC SMS shall when modifying CNAM DPC or CNAM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, ISVM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 45)          RR3-425   Number Pool Block — Verify All Routing Data When Modifying ISVM Data    NPAC SMS shall when modifying ISVM DPC or ISVM SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or WSMSC, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 46)          RR3-426   Number Pool Block — Verify All Routing Data When Modifying WSMSC Data    NPAC SMS shall when modifying WSMSC DPC or WSMSC SSN, reject the modify request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, or ISVM, from the new/current Service Provider in a Number Pool Block modification, or mass update for a Number Pool Block. (Previously NANC 191 Req 47)          RR3-427   Subscription Version — Verify All Routing Data When Activating a Subscription Version    NPAC SMS shall when activating a Subscription Version, reject the activate request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new Service Provider in an activation for an Inter-Service Provider Port or Intra-Service Provider Port. (Previously NANC 191 Req 48)          RR3-428   Number Pool Block — Verify All Routing Data When Activating a Number Pool Block    NPAC SMS shall when scheduling a Block Create Event or activating a Number Pool Block, reject the scheduling or activate request for any DPC/SSN value edit inconsistencies for CLASS, LIDB, CNAM, ISVM, or WSMSC, from the new Service Provider in scheduling or activation for a Number Pool Block. (Previously NANC 191 Req 49)          RR3-429   DPC/SSN Edits — Errors on DPC and SSN Required Data for Mass Update    NPAC SMS shall log an entry to be used for the mass update exception report when any of the required DPC/SSN data edits are violated when mass updating a Subscription Version or Number Pool Block, and continue processing the mass update request. (Previously NANC 191 Req 50)  Note: For example in a case where 2000 SVs are being mass updated and 100 encountered DPC/SSN edit errors, the NPAC will perform the mass update by updating the 1900 SVs that are valid, and logging the remaining 100 SVs to be picked up the mass update exception report.                        Release 3.3: Ó 1997 — 2006 NeuStar, Inc.    3-114    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Service Provider Data Administration             4.   Service Provider Data Administration            4.1   Service Provider Data Administration and Management    Service Provider Data Administration functions allow NPAC personnel to receive and record data needed to identify authorized LNP Service Providers. The Service Provider data indicates the LNP Service Providers and includes location, contact name, security, routing, and network interface information.  Service Provider Administration supports functionality to manage Service Provider data. There can be only one instance of Service Provider data for a specific LNP Service Provider.          AR1-1   Service Provider ID    All NPAC Customers will obtain a unique Service Provider ID from a proper source.          4.1.1   User Functionality            R4-1   Create Service Providers    The NPAC SMS shall allow NPAC Personnel to add a Service Provider.          R4-2   Modify Service Providers    NPAC SMS shall allow modification of Service Provider data via the NPAC SMS to Local SMS interface or the SOA to NPAC SMS interface. Service Providers can only modify their own data.          R4-3   Delete Service Providers    NPAC SMS shall allow NPAC personnel to delete a Service Provider.          R4-4   View of Service Provider Data    NPAC SMS shall allow NPAC personnel to view Service Provider data.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             R4-5.1   View List of Service Provider Subscriptions    NPAC SMS shall allow NPAC personnel to view a list of Subscription Versions associated with the Service Provider.          R4-5.2   Authorized Service Providers View Their Own Data    NPAC SMS shall allow authorized Service Provider personnel to view their own Service Provider data via the SOA to NPAC SMS interface, the NPAC SMS to Local SMS interface, and the NPAC SOA Low-tech Interface.          RX4-2   Authorized Service Providers Modify Their Own Data    NPAC SMS shall allow authorized Service Provider personnel to modify their own Service Provider data.          RR4-4.1   Broadcast NPAC Customer Names    NPAC SMS shall broadcast all additions, modifications, and deletions of NPAC Customer names via the NPAC SMS to Local SMS interface and/or SOA to NPAC SMS interface.          4.1.2   System Functionality    This section describes NPAC SMS functionality required to support the NPAC personnel requests described in the above section. The following specifies user requests and lists the NPAC SMS functionality needed to support those requests.          4.1.2.1   Service Provider Data Creation    NPAC personnel can request that Service Provider data be created in the NPAC SMS. The functionality described below enables a new instance of Service Provider data for a Service Provider to be created, provided that no other Service Provider data exists for the Service Provider.          R4-6   New Service Provider ID    NPAC SMS shall require the following to be entered to identify the Service Provider, when NPAC personnel are creating a new Service Provider:  Service Provider ID — the alphanumeric identifier of the Service Provider. This ID must be unique.          R4-7.1   Examine for Duplicate Service Provider ID    NPAC SMS shall check to see if there is an existing Service Provider with the same Service Provider ID.          R4-7.2   Error notification of Duplicate Service Provider    NPAC SMS shall inform the user that the Service Provider data already exists for the Service Provider, if it does exist, and that the new Service Provider data cannot be created.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             R4-8   Service Provider Data Elements    NPAC SMS shall require the following data if there is no existing Service Provider data: (reference NANC 399)     1.   Service Provider name, address, phone number, and contact organization.      2.   NPAC customer type.      3.   Service Provider allowable functions.      4.   Service Provider Network Address of NPAC SMS to Local SMS interface.      5.   Service Provider Network Address of SOA to NPAC SMS interface.      6.   Service Provider Security Contact. Contact data is security data when Contact Type is “SE.”      7.   Service Provider Repair contact name and phone number. The default Service Provider Repair Contact and phone number shall be the same as the Service Provider contact and phone number, if the Service Provider Repair Contact information is left blank.      8.   Service Provider billing name, address, phone number, and billing contact for NPAC SMS billing. The default for the Service Provider Billing data shall be the same as the Service Provider data, if the Service Provider Billing information is left blank.      9.   Service Provider Download Indicator      10.   Service Provider Maximum Query      11.   NPAC New Functionality Support      12.   Port In Timer Type      13.   Port Out Timer Type      14.   Business Hour/Days      15.   NPAC Customer SOA NPA-NXX-X Indicator      16.   NPAC Customer LSMS NPA-NXX-X Indicator      17.   LSMS EDR Indicator      18.   SOA Notification Priority for each SOA notification. Separate values may be set for Status Attribute Value Change notifications based on whether the Service Provider is acting as the Old Service Provider or as the New Service Provider for the port as indicated in Appendix C, Table C-7 – SOA Notification Priority Tunables.      19.   TN Range Notification Indicator      20.   No New SP Concurrence Notification Indicator      21.   Service Provider Type      22.   Service Provider Type SOA Indicator                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration        23.   Service Provider Type LSMS Indicator      24.   Service Provider SOA SWIM Recovery Indicator      25.   Service Provider LSMS SWIM Recovery Indicator      26.   NPAC SMS-to-SOA Application Level Heartbeat Indicator      27.   NPAC SMS-to-LSMS Application Level Heartbeat Indicator      28.   SOA Action Application Level Errors Indicator      29.   LSMS Action Application Level Errors Indicator      30.   SOA Non-Action Application Level Errors Indicator      31.   LSMS Non-Action Application Level Errors Indicator      32.   SOA Notification Channel Service Provider Tunable      33.   Subscription Version TN Attribute Flag Indicator      34.   Number Pool Block NPA-NXX-X Attribute Flag Indicator      35.   Cancel-Pending-to-Conflict Cause Code Indicator      36.   Service Provider SOA SV Query Indicator      37.   Service Provider LSMS SV Query Indicator      38.   NPAC Customer SOA SV Type Indicator      39.   NPAC Customer SOA Alternative SPID Indicator      40.   NPAC Customer LSMS SV Type Indicator      41.   NPAC Customer LSMS Alternative SPID Indicator    The following data is optional:     •   Service Provider Contact Type: SOA Contact, Local SMS, Web, Network Communications, Conflict Resolution, Operations, and User Administration Contact Address Information.      •   NPAC Customer Associated Service Provider Information            R4-9   Service Provider data validation    NPAC SMS shall validate that all required Service Provider data has been received, after the Service Provider data has been collected.          R4-10   Notification of successful add for new Service Provider    NPAC SMS shall notify NPAC personnel upon successful creation of the new Service Provider.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             R4-11   Failure notification of Service Provider creation    NPAC SMS shall issue an appropriate error message upon unsuccessful creation of the new Service Provider.          RR4-9   Service Provider Type SOA Indicator    NPAC SMS shall provide a Service Provider Type SOA Indicator tunable parameter, which defines whether a SOA supports the Service Provider Type attribute. (previously NANC 357, Req 1)          RR4-10   Service Provider Type SOA Indicator Default    NPAC SMS shall default the Service Provider Type SOA Indicator tunable parameter to FALSE. (previously NANC 357, Req 2)          RR4-11   Service Provider Type SOA Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Type SOA Indicator tunable parameter. (previously NANC 357, Req 3)          RR4-12   Service Provider Type LSMS Indicator    NPAC SMS shall provide a Service Provider Type LSMS Indicator tunable parameter which defines whether an LSMS supports the Service Provider Type attribute. (previously NANC 357, Req 4          RR4-13   Service Provider Type LSMS Indicator Default    NPAC SMS shall default the Service Provider Type LSMS Indicator tunable parameter to FALSE. (previously NANC 357, Req 5)          RR4-14   Service Provider Type LSMS Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Type LSMS Indicator tunable parameter. (previously NANC 357, Req 6)          RR4-15   Service Provider Type Attribute Modification Restriction    NPAC SMS shall only allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Type attribute. (previously NANC 357, Req 7)          4.1.2.2   Service Provider Data Modification    NPAC personnel and the SOA to NPAC SMS interface and the NPAC to Local SMS interface can request that Service Provider data be modified in the NPAC SMS. The functionality described below enables the user to modify data for the Service Provider.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             R4-13   Service Provider Key selection for modifying Service Provider data    NPAC SMS shall require one of the following data items to identify the Service Provider data to be modified:  Service Provider ID  or  Service Provider Name  The Service Provider ID is required over the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.          R4-14   Error notification of invalid Service Provider ID or Name during Modify    NPAC SMS shall issue an appropriate error message to the user if the Service Provider data to be modified does not exist.          R4-15.1   Modify restrictions on Service Provider data — Service Providers    NPAC SMS shall allow Service Provider data to be modified or added to the Service Provider data with the exception of the data listed in Table 3-2 NPAC Customer Data Model.          R4-15.2   Modify restrictions on Service Provider data — NPAC Operations Personnel    NPAC SMS shall allow NPAC Operations personnel to modify the data in Table 3-2 NPAC Customer Data Model, with the exception of the NPAC Customer ID.          R4-16   Re-validation of Service Provider data after Modify    NPAC SMS shall revalidate that all required Service Provider data is present when a user attempts to submit modified Service Provider data.          R4-17   Modify Validation Error Message    NPAC SMS shall issue an appropriate error message to the user if the Service Provider data fails validation on a modify.          4.1.2.3   Delete Service Provider Data    NPAC personnel can request that the Service Provider data be deleted. Deleted Service Provider data will be written to a history file. The functionality described below enables a user to delete data for the Service Provider.          R4-20   Service Provider key for delete    NPAC SMS shall require the Service Provider ID and/or Service Provider name from the user to identify the Service Provider data to be deleted.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             R4-21   Error Message for Delete key search    NPAC SMS shall generate an error message and send it to the request originator, if the Service Provider data does not exist, or if is has already been deleted and exists only in a history file. NPAC SMS will not proceed further with the deletion request.          R4-22.1   No Subscription Versions during Service Provider Delete    NPAC SMS shall perform the deletion of the Service Provider data, notify the user that the deletion request was successful, if there are no affected Subscription Versions, and write the Service Provider data to a history file.          R4-22.2   Subscription during Service Provider Delete    NPAC SMS shall notify the user that the request to delete the Service Provider data cannot be completed until the affected individual Subscription Versions are modified, if affected Subscription Versions are found.          R4-22.3   Service Provider subscription restrictions during Network Data Delete.    NPAC SMS shall determine if there are any Subscription Versions being affected by the NPA-NXX and/or LRN data being deleted.          4.1.3   Service Provider Queries    The query functionality discussed in this section will give users the ability to view Service Provider and Subscription data. A user may not be able to modify a particular data item because they do not have the proper security permissions, therefore the data is made available via NPAC SMS for read-only purposes.          4.1.3.1   User Functionality R4-24.1 | Display of Service Provider ID and related subscription data     R4-24.1   Display of Service Provider ID and related subscription data    NPAC SMS shall allow NPAC personnel to view all Subscription Versions associated with a Service Provider ID and/or Service Provider Name.          R4-24.2   Display of LRN and related subscription data    NPAC SMS shall allow NPAC personnel to view all Subscription Versions associated with an LRN.          R4-24.3   Display of NPA-NXX and related subscription data    NPAC SMS shall allow NPAC personnel to view all Subscription Versions associated with an NPA-NXX.          4.1.3.2    System Functionality    The following specifies NPAC SMS functionality needed to support the user requests described above.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             4.1.3.2.1   Service Provider Query            R4-25   Service Provider as Key for queries    NPAC SMS shall require the Service Provider ID and/or the Service Provider Name for queries regarding Service Provider data.          R4-26.1   Error message for unknown Service Provider during a query    NPAC SMS shall provide the request originator with a message indicating that there was no data in the NPAC SMS that matched the search keys for a Service Provider query, if no match was found.          R4-26.2   Results returned to Service Provider during a query    NPAC SMS shall return all Service Provider data associated with the Service Provider ID and/or Service Provider Name, as listed in Tables 3-2, 3-3, 3-4, and 3-5, if the Service Provider data matches the query criteria. Service Providers are only allowed to query their own data.          R4-27   Service Provider Query Types    NPAC SMS shall receive the Service Provider ID, a request to view subscription data, and optionally the subscription data status types to be returned (e.g., active only, active or pending) for queries regarding subscription data for a specific Service Provider.          R4-28   Service Provider Information Message during query    NPAC SMS shall provide the request originator with a message indicating that there was no data in NPAC SMS that matched the search keys, if NPAC SMS does not have subscription data as specified by the request originator.          RR4-16   Service Provider Data Information Service Provider Query — Support for Service Provider Type Data    NPAC SMS shall apply the Service Provider Type tunable support of the requesting Service Provider, in a query of Service Provider data. (previously NANC 357, Req 9)             4.2   Additional Requirements            RN4-1   Service Provider Network Data Addition/Deletion    NPAC SMS shall allow Service Providers to add/delete the NPA-NXX and/or LRN data via the NPAC SMS to Local SMS interface and SOA to NPAC SMS interface provided the changes do not cause mass updates to the Subscription Versions.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Service Provider Data Administration             RR4-1   Removal of Service Provider with Respect to LRNs    NPAC SMS shall allow removal of a Service Provider by NPAC personnel only if all associated LRNs are removed, and no Subscription Versions are associated with the LRN.          RR4-2   Removal of Service Provider with Respect to NPA-NXXs    NPAC SMS shall allow removal of a Service Provider by NPAC personnel only if all associated NPA-NXXs are removed, and no Subscription Versions are associated with the NPA-NXX.          RR4-3.1   Removal of NPA-NXX — Subscription Version Check    NPAC SMS shall allow removal of an NPA-NXX by NPAC personnel only if no Subscription Versions, except for Old without a Failed SP List or Canceled Subscription Versions, exist for the NPA-NXX.          RR4-3.2   Removal of NPA-NXX — NPA-NXX-X Check    NPAC SMS shall allow the removal of an NPA-NXX by NPAC personnel only if Number Pooling NPA-NXX-X Information, does not exist for the NPA-NXX.          RR4-4.2.1   Removal of LRN — Subscription Version Check    NPAC SMS shall allow the removal of an LRN by NPAC personnel only if no Subscription Versions, except for Old without a Failed SP List or Canceled Subscription Versions, exist and use the LRN.          RR4-4.2.2   Removal of LRN — Block Check    NPAC SMS shall allow the removal of an LRN by NPAC personnel only if Number Pooling Block Information, except for Old with NO Failed SP List, do not exist and do not use the LRN.          RR4-5   Duplicate NPA-NXX Validation    NPAC SMS shall validate upon request to add an NPA-NXX for a service provider, that the NPA-NXX does not exist for any service provider in the region.          RR4-6   Duplicate NPA-NXX Validation — Error Processing    NPAC SMS shall upon finding that an NPA-NXX already exists for a service provider in a region, reject a request to add an NPA-NXX for a service provider and report an error to the user.          RR4-7   Duplicate LRN Validation    NPAC SMS shall validate upon request to add an LRN for a service provider, that the LRN does not exist for any service provider in the region.          RR4-8   Duplicate LRN Validation — Error Processing    NPAC SMS shall upon finding that an LRN already exists for a service provider in a region, reject a request to add an LRN for a service provider and report an error to the user.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    4-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             5.   Subscription Management            5.1   Subscription Version Management    Subscription Management functions allow NPAC personnel and SOA to NPAC SMS interface users to specify data needed for ported numbers. The subscription data indicates how local number portability should operate to meet subscribers’ needs. These functions will be accessible to authorized service providers via an interface (i.e., the SOA to NPAC SMS interface) from their operations systems to the NPAC SMS and will also be accessible to (and performed by) NPAC personnel.  Subscription Management supports functionality to manage multiple versions of subscription data. See Section 5.1.1, Subscription Version Management, for more details on the different states of a version.          RN5-1   Subscription Version Status — Only One Per Subscription    NPAC SMS shall allow only one pending, cancel pending, conflict, disconnect pending, failed or partial failure Subscription Version per subscription.          RN5-2   Subscription Version Status — Only One Active Version    NPAC SMS shall allow only one active Subscription Version per subscription.          RN5-3   Subscription Version Status — Multiple Old/Canceled    NPAC SMS shall allow multiple old and/or canceled Subscription Versions per subscription.          RR5-113   TN Range Notification Information — Service Provider TN Range Notification Indicator Sending of TN Range Notifications    NPAC SMS shall send TN Range Notifications, via the SOA to NPAC SMS Interface, if the Service Provider’s TN Range Notification Indicator is TRUE. (Formerly NANC 179 Req 4)          RR5-114   TN Range Notification Information — Service Provider TN Range Notification Indicator Suppression of TN Range Notifications    NPAC SMS shall suppress TN Range Notifications and send individual TN Notifications, via the SOA to NPAC SMS Interface, if the Service Provider’s TN Range Notification Indicator is FALSE. (Formerly NANC 179 Req 5)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             AR5-3   Changing of TN Range Notification Indicator while Notifications are Queued    In the event that the TN Range Notification Indicator is changed from TRUE to FALSE any notifications for multiple TNs that were already created and are in queue will be sent in the range format and in the event that the TN Range Notification Indicator is changed from FALSE to TRUE any notifications for multiple TNs that were already created and are in queue will be sent in the single format.          RR5-115   TN Range Notification Information — Single TN Range Notifications    NPAC SMS shall send a single TN Range Notification when the same feature data applies to all TNs in the range. (Formerly NANC 179 Req 6)          RR5-116   TN Range Notification Information — Breakup of TN Range Notifications    NPAC SMS shall send more than one TN Range Notification when the same feature data does NOT apply to all TNs in the range, by breaking up the TN Range and sending TN Range Notifications such that the same feature data applies to all TNs in the smaller broken up TN Ranges. (Formerly NANC 179 Req 7)          RR5-173   TN Range Notification Information — Breakup of TN Range Notifications    NPAC SMS shall send more than one TN Range Notification when a subsequent request is received for a TN range that was different than the original create TN range by breaking up the TN Range and sending single TN Range Notifications.  Note: An example of a different subsequent request is an original create range of 5 TNs, followed by an activate of a single TN. This leads to the NPAC breaking up the range into singles upon receipt of the first request that doesn’t match the original creat range request.          5.1.1   Subscription Version Management    Subscription Version management provides functionality to manage multiple time-sensitive views of subscription data. This section addresses version management for LNP and the user and system functionality needed for subscription administration. In this context a version may be defined as time-sensitive subscription data.  At any given time, a Subscription Version in the SMS can have one of several statuses (e.g., active, old) and may change status depending on results of different SMS processes (e.g., modification, activation). This section describes the different statuses that a version can have and the SMS processes that can change the status. This section also discusses functionality and data that is needed for Subscription Management.          5.1.1.1   Version Status    [Graphic Omitted: Version Status Interaction Diagram]  Figure 1 — Subscription Version Status Interaction Diagram                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     Subscription Version Status Interaction Descriptions                      #   Interaction Name   Type   Description     1    Conflict to Cancel    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version in conflict directly to canceled after it has been in conflict for a tunable number of calendar days.                            SOA to NPAC SMS Interface or NPAC SOA Low-tech or Administrative Interface    The old Service Provider User (or NPAC personnel acting on behalf of the Service Provider) sends a cancellation request for a Subscription Version created by that Service Provider with a status of conflict that has not been concurred by the other new Service Provider.                   2    Conflict to Cancel Pending    NPAC SOA Low-tech or Administrative Interface    User cancels a Subscription Version in conflict or cancels a Subscription Version that was created by or concurred to by both Service Providers.                            SOA to NPAC SMS Interface    User sends a cancellation request for a Subscription Version that was created by or concurred to by both Service Providers.                   3    Cancel Pending to Conflict    NPAC SOA Low-tech or Administrative Interface    User sets a Subscription Version with a status of cancel pending to conflict.                            NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version with a status of cancel pending to conflict if cancel pending acknowledgment has not been received from the new Service Provider within a tunable timeframe.                   4    Conflict to Pending    NPAC Administrative Interface – NPAC Personnel and SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface – Old Service Provider    User removes a Subscription Version from conflict.                            SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface — New Service Provider    New Service Provider User removes a Subscription Version from conflict. This action can only occur if a tunable number of hours have elapsed since the Subscription Version was placed in conflict.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     Subscription Version Status Interaction Descriptions                      #   Interaction Name   Type   Description     5    Pending to Conflict    NPAC Administrative Interface – NPAC Personnel    1.    User sets a Subscription Version with a status of pending to conflict.  2.    User creates a Subscription Version for an existing pending Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.                            SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface – Old Service Provider    Old Service Provider sends a Subscription Version creation or modification request for a Subscription Version with a status of pending, which revokes the old Service Provider’s authorization for transfer of service. This action can only be taken once, and must be taken a tunable number of hours prior to the new Service Provider due date.                   6    Pending to Cancel    NPAC Administrative Interface – NPAC Personnel    User cancels a Subscription Version with a status of pending that has not been concurred by both service providers.                            SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface    Service Provider User sends a cancellation request for a Subscription Version created by that Service Provider with a status of pending that has not been concurred by the other Service Provider.                            NPAC SMS Internal    1.    NPAC SMS automatically sets a pending Subscription Version to cancel after authorization for the transfer of service has not been received from the new Service Provider within a tunable timeframe.                 2.    NPAC SMS automatically sets a pending Subscription Version to cancel if an activation request is not received a tunable amount of time after new Service Provider due date.                   7    Pending to Cancel Pending    NPAC Administrative Interface — NPAC Personnel    User cancels a Subscription Version with a status of pending that has been created/concurred by both Service Providers.                            SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface    Service Provider User sends a cancellation request for a Subscription Version with a status of pending that has been concurred by the other Service Provider.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     Subscription Version Status Interaction Descriptions                      #   Interaction Name   Type   Description     8    Cancel Pending to Cancel    NPAC SMS Internal    NPAC SMS automatically sets a cancel pending Subscription Version to canceled after receiving cancel pending acknowledgment from the concurring Service Provider, or the final cancellation concurrence window has expired without cancel concurrence from the old Service Provider.                   9    Creation - Set to Conflict    NPAC Administrative Interface – NPAC Personnel    User creates a Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.                            SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface – Old Service Provider    User sends an old Service Provider Subscription Version creation request and does not provide authorization for the transfer of service.                   10    Creation - Set to Pending    NPAC Administrative Interface – NPAC Personnel    User creates a Subscription Version for either the new or old Service Provider. If the create is for the old Service Provider and authorization for the transfer of service is not provided, refer to # 9, Creation — Set to Conflict, NPAC SOA Low-tech Interface.                            SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface    User sends a Subscription Version creation request for either the new or old Service Provider. If the create is for the old Service Provider, and authorization for the transfer of service is not provided, refer to # 9, Creation — Set to Conflict, SOA to NPAC SMS LOW-TECH INTERFACE.                   11    Disconnect Pending to Sending    NPAC SMS Internal    NPAC SMS automatically sets a deferred disconnect pending Subscription Version to sending after the effective release date is reached.                   12    Cancel Pending to Pending    SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface    Service Provider User sends an un-do cancel-pending request for a Subscription Version with a status of cancel-pending for which the same Service Provider previously issued a cancel request.                   13    Pending to Sending    NPAC Administrative Interface — NPAC Personnel    User activates a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     Subscription Version Status Interaction Descriptions                      #   Interaction Name   Type   Description              SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface — New Service Provider    New Service Provider User sends an activation message for a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.                   14    Sending to Failed    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from sending to failed after all Local SMSs fail Subscription Version activation after the tunable retry period expires.                   15    Failed to Sending    NPAC Administrative Interface – NPAC Personnel    User re-sends a failed Subscription Version.                   16    Partially Failed to Sending    NPAC Administrative Interface – NPAC Personnel    User re-sends a partial failure Subscription Version.                   17    Sending to Partially Failed    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from sending to partial failure after one or more, but not all, of the Local SMSs fail the Subscription Version activation after the tunable retry period expires.                   18    Sending to Old    NPAC SMS Internal    NPAC SMS automatically sets a sending Subscription Version to old after a disconnect or “porting to original” port to all Local SMSs successfully completes. Disconnects that fail on one or more, but not all, Local SMSs will also be set to old.                   19    Sending to Active    NPAC SMS Internal    1.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version activation is successful in all of the Local SMSs.                2.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version modification is successfully broadcast to any of the Local SMSs after all have responded.                3.    NPAC SMS automatically sets a sending Subscription Version to active after a failure to all Local SMSs on a disconnect.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     Subscription Version Status Interaction Descriptions                      #   Interaction Name   Type   Description     20    Active to Sending    NPAC Administrative Interface – NPAC Personnel    User disconnects an active Subscription Version and does not supply an effective release date, User modifies an active Subscription Version or resends a failed disconnect or modify.                            SOA to NPAC SMS Interface to NPAC SOA Low-tech Interface — Current Service Provider    User sends a disconnect request for an active Subscription Version and does not supply an effective release date, or User modifies an active Subscription Version.                   21    Active to Old    NPAC SMS Internal    NPAC SMS automatically sets the currently active Subscription Version to old once a currently active subscription version is superseded by a pending subscription version, due to the fact that the current version is set to old when an activate occurs. The new pending version is set to sending and then to active, partially failed, or old. On a disconnect the sending state occurs before the old.                   22    Disconnect Pending to Active    NPAC Administrative Interface – NPAC Personnel    User cancels a Subscription Version with a disconnect pending status.                            SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface – New Service Provider    User sends a cancellation request for a disconnect pending Subscription Version.                   23    Active to Disconnect Pending    NPAC Administrative Interface — NPAC Personnel    User disconnects an active Subscription Version and supplies a future effective release date.                            SOA to NPAC SMS Interface and NPAC SOA Low-tech Interface- Current Service Provider    User sends a disconnect request for an active Subscription Version and supplies a future effective release date.                   24    Old to Sending    NPA Operations Interface – NPAC Personnel    User re-sends a partial failure of a disconnect or partial failure or failure of a port-to-original Subscription Version.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     Subscription Version Status Interaction Descriptions                      #   Interaction Name   Type   Description     25    Old to Old    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from old to old after one or more previously failed Local SMSs successfully disconnect a Subscription Version, as a result of an audit or LSMS resync. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   26    Partially Failed to Active    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from partial failure to active after all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS resync. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   27    Partially Failed to Partially Failed    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS resync. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.     Table 5-1 Subscription Version Status Interaction Descriptions          R5-1.1   Subscription Version Statuses    NPAC SMS Subscription Version instances shall at any given time have one of the following statuses:     •   Active — Version is currently active in the network.            NOTE:   There may be another pre- active version in the system that will eventually supersede this version. Examples: 1) Pending version for the active subscription exists 2) Sending version for the active subscription exists.       •   Canceled — A pending or conflict version was canceled prior to activation in the network.       •   Cancel Pending — Version is awaiting cancellation acknowledgment from the concurring Service Providers, at which time the version will be set to canceled.       •   Conflict — Version is in conflict (i.e., a dispute exists between the two Service Providers), awaiting resolution.       •   Disconnect Pending — Version is awaiting the effective release date, at which time the version will be set to sending and the disconnect request will be sent to all Local SMSs.       •   Failed — Version failed activation in ALL of the Local SMSs in the network.       •   Old — Version was previously active in the network and either was superseded by another active version or was disconnected.       •   Partial Failure — Version failed activation in one or more, but not all, Local SMSs in the network.                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management        •   Pending — Version is either pending activation (approval had been received from both Service Providers) or pending creation/approval from one or the other Service Provider.       •   Sending — Version is currently being sent to all of the Local SMSs in the network.            R5-2.1   Old Subscription Retention — Tunable Parameter    NPAC SMS shall provide an Old Subscription Retention tunable parameter which is defined as the length of time that old Subscription Versions shall be retained and accessible through a query request.          R5-2.2   Old Subscription Retention — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Old Subscription Retention tunable.          R5-2.3   Old Subscription Retention — Tunable Parameter Default    NPAC SMS shall default the Old Subscription Retention tunable parameter to 18 calendar months.          R5-3.1   Cancel-Pending Subscription Retention — Tunable Parameter    NPAC SMS shall provide a Cancel-Pending Subscription Retention tunable parameter which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of pending shall be retained and accessible through a query request.          R5-3.2   Cancel-Pending Subscription Retention — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Pending Subscription Retention tunable parameter.          R5-3.3   Cancel-Pending Subscription Retention — Tunable Parameter Default    NPAC SMS shall default the Cancel-Pending Subscription Retention tunable parameter to 90 calendar days.          R5-3.4   Cancel-Conflict Subscription Retention — Tunable Parameter    NPAC SMS shall provide a Cancel-Conflict Subscription Retention tunable parameter which is defined as the length of time that canceled Subscription Versions with a pre-cancellation status of conflict shall be retained and accessible through a query request.          R5-3.5   Cancel-Conflict Subscription Retention — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Cancel-Conflict Subscription Retention tunable parameter.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             R5-3.6   Cancel-Conflict Subscription Retention — Tunable Parameter Default    NPAC SMS shall default the Cancel-Conflict Subscription Retention tunable parameter to 30 calendar days.          RR5-1.1   Pending Subscription Retention — Tunable Parameter    NPAC SMS shall provide a Pending Subscription Retention tunable parameter, which is defined as the length of time that a pending Subscription Version shall remain in the system prior to cancellation.          RR5-1.2   Pending Subscription Retention — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Pending Subscription Retention tunable parameter.          RR5-1.3   Pending Subscription Retention — Tunable Parameter Default    NPAC SMS shall default the Pending Subscription Retention tunable parameter to 90 calendar days.          RR5-1.4   Pending Subscription Retention — Tunable Parameter Expiration    NPAC SMS shall cancel a Subscription Version by setting the subscription version to cancel after a pending Subscription Version has existed in the system for a Pending Subscription Retention number of calendar days subsequent to new Service Provider Due Date, or old Service Provider Due Date if the new Service Provider Due Date has not been received by the NPAC SMS.          R5-5   Subscription Versions Creation for TN Ranges    NPAC SMS shall create individual Subscription Versions when a Subscription Version creation request is received for a TN range.          R5-6   Subscription Administration Transaction Logging    NPAC SMS shall log all subscription administration transactions. The log entries shall include:     •   Activity Type: create, modify, activate, query, all status types, and all acknowledgments.       •   Service Provider ID       •   Initial Version Status       •   New Version Status (if applicable)       •   User ID and/or Login       •   Local Number Portability Type       •   Date       •   Time       •   Ported Telephone Number       •   Status Flag — successful or failed       •   Subscription Version ID (when assigned)                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             5.1.2   Subscription Administration Requirements            5.1.2.1   User Functionality    Authorized users can invoke the following functionality in the NPAC SMS to administer subscription data:          R5-7   Creating a Subscription Version    NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to create a Subscription Version.          RR5-55   Create Pending Provider Port — NPAC Personnel or Service Provider After Block Activation    NPAC SMS shall allow NPAC personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to create inter-service provider ports or intra-service provider ports for a TN within the 1K Block, when the currently active Subscription Version(s) is LNP Type POOL, and the Block’s status is active, with an empty Failed SP List. (Previously SV-195)          R5-8.1   Modifying a Subscription Version    NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to modify a Subscription Version.          R5-9   Activating a Subscription version    NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to activate a Subscription Version.          R5-10.1   Setting a Subscription Version to Conflict    NPAC SMS shall allow NPAC personnel to set a Subscription Version to conflict.          R5-10.2   Subscription Version Conflict Status Rule    NPAC SMS shall prohibit a Subscription Version in conflict from being activated.          R5-11   Disconnecting a Subscription Version    NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to disconnect a Subscription Version.          R5-12   Canceling a Subscription Version    NPAC SMS shall allow NPAC personnel and the SOA to NPAC SMS interface to cancel a Subscription Version.          R5-13   Querying a Subscription Version    NPAC SMS shall allow NPAC personnel, Local SMS/ SOA to NPAC SMS interface to query for a Subscription Version.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             5.1.2.2   System Functionality    This section describes NPAC SMS functionality required to support NPAC personnel and SOA to NPAC SMS interface user requests defined in the above section.  Additionally, NPAC SMS functionality will perform operations which are not invoked by a direct user request. Some examples of this are: monitor a Subscription Version to determine whether the old and the new facilities-based Service Providers have authorized the transfer of service for a ported number, issue appropriate notifications to Service Providers, and change the status of a Subscription Version based on tunable parameters.          5.1.2.2.1   Subscription Version Creation    This section provides the requirements for the Subscription Version Create functionality, which is executed upon the user requesting to create a Subscription Version.          RR5-3   Create Subscription Version — Notify NPA-NXX First Usage    NPAC SMS shall notify all accepting Local SMSs and SOAs of the NPA-NXX, effective date, and owning Service Provider when an NPA-NXX is being ported for the first time immediately after creation validation of a Subscription Version.          RR5-53   Create Subscription Version — Notify NPA-NXX First Usage of a New NPA-NXX involved in an NPA Split    NPAC SMS shall notify all accepting Local SMSs and SOAs of the NPA-NXX, effective date, and owning Service Provider when a new NPA-NXX involved in an NPA Split, is being ported for the first time, after the start of permissive dialing, immediately after creation validation of a Subscription Version, only in cases where no SV or NPA-NXX-X activity had previously taken place in the Old NPA-NXX.          RR5-120   Validation of LATA ID for Subscription Version Creates    NPAC shall reject Subscription Version Create Requests if the NPA-NXX of the TN and the NPA-NXX of the LRN have different LATA IDs. (Previously NANC 319 Req 6)          RR5-130   Create “Porting to Original” Subscription Version — New Service Provider ID and Code Holder Match    NPAC SMS shall validate that the new Service Provider Id is the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block) in a “Port to Original” subscription version request for both Inter- and Intra-Service Provider ports.          RR5-162   Addition of Subscription Version Due Date — Validation    NPAC SMS shall verify that the Due Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and equal to or greater than the current date, when adding a Subscription Version. (previously NANC 394, Req 6)  Note: For an Inter-Service Provider port, the due date may be a past date when it is the 2nd create for the subscription version (see requirement RR5-119).          5.1.2.2.1.1   Subscription Version Creation — Inter-Service Provider Ports                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-12    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management     This section provides the Subscription Version Creation requirements for performing an Inter-Service Provider port of a TN. There are two types of Inter-Service Provider ports: A port of a TN to a new Service Provider from the Old, or a “porting to original” port. A “porting to original” port implies that all porting data will be removed from the Local SMSs and the TN will revert to the default routing, which ultimately results in the TN returning to the original “donor” Service Provider.  The primary differences in functionality between these two types of Inter-Service Provider ports is that for a “porting to original” port, the routing data is not supplied and upon activation, a delete request is broadcast to the Local SMSs instead of a create request.  Both port types of Inter-Service Provider ports require authorization for the transfer of service from the new Service Provider.          R5-14   Create Subscription Version — Old Service Provider Input Data    NPAC SMS shall accept the following data from the NPAC personnel or old Service Provider upon Subscription Version creation for an Inter-Service Provider port:     •   Local Number Portability Type -Port Type.       •   Ported Telephone Number(s) — this entry can be a single TN or a continuous range of TNs that identifies a subscription or a group of Subscription Versions that share the same attributes.       •   Due Date — date on which transfer of service from old facilities-based Service Provider to new facilities-based Service Provider is initially planned to occur.       •   New facilities-based Service Provider ID — the identifier of the new facilities-based Service Provider.       •   Old facilities-based Service Provider ID — the identifier of the old facilities-based Service Provider.       •   Authorization from old facilities-based Service Provider — indication that the transfer of service is authorized by the ported-from Service Provider.       •   Status Change Cause Code — indication of reason for denial of authorized by the Old Service Provider.            R5-15.1   Create “Inter-Service Provider Port” Subscription Version — New Service Provider Input Data    NPAC SMS shall require the following data from NPAC personnel or the new Service Provider upon Subscription Version creation for an Inter-Service Provider port when NOT “porting to original”: (reference NANC 399)     •   Local Number Portability Type — Port Type. This field must be set to “LSPP” for Inter-Service Provider ports.       •   Ported Telephone Number(s) — this entry can be a single TN or a continuous range of TNs that identifies a subscription or a group of Subscription Versions that share the same attributes.       •   Due Date — date on which transfer of service from old facilities-based Service Provider to new facilities-based Service Provider is initially planned to occur.       •   New Facilities-based Service Provider ID — the identifier of the new facilities-based Service Provider.       •   Old Facilities-based Service Provider ID — the identifier of the old facilities-based Service Provider.       •   Location Routing Number (LRN) — the identifier of the ported-to switch.       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-13    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management        •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC (if supported by the Service Provider SOA)       •   WSMSC SSN (if supported by the Service Provider SOA)       •   Porting to Original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “FALSE” for this type of Inter-Service Provider port.       •   SV Type (if supported by the Service Provider SOA)            R5-15.2   Create “Inter-Service Provider porting to original” Subscription Version — New Service Provider Input Data    NPAC SMS shall require the following data from NPAC personnel or the new Service Provider upon Subscription Version creation for an Inter-Service Provider “porting to original” port:     •   Local Number Portability Type — Port Type. This field must be set to “LSPP” for “Inter-Service Provider porting to original” ports.       •   Ported Telephone Number(s) — this entry can be a single TN or a continuous range of TNs that identifies a subscription or a group of Subscription Versions that share the same attributes.       •   Due Date — date on which transfer of service from old facilities-based Service Provider to new facilities-based Service Provider is initially planned to occur.       •   New Facilities-based Service Provider ID — the identifier of the new facilities-based Service Provider, also the NPA-NXX code holder or Block Holder if this TN is part of a Number Pool Block.       •   Old Facilities-based Service Provider ID — the identifier of the old facilities-based Service Provider.       •   Porting to original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “TRUE” for “Inter-Service Provider porting to original” ports, and set to “FALSE” for other Inter-Service Provider ports.            R5-16   Create Subscription Version — New Service Provider Optional input data    NPAC SMS shall accept the following optional fields from NPAC personnel or the new Service Provider upon Subscription Version creation for an Inter-Service Provider port: (reference NANC 399)     •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   Alternative SPID (if supported by the Service Provider SOA)            R5-18.1   Create Subscription Version — Field-level Data Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-6 upon Subscription Version creation for an Inter-Service Provider port: (reference NANC 399)     •   LNP Type      •   Ported TN(s)                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-14    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management        •   Old Service Provider Due Date      •   New Service Provider Due Date      •   Old Service Provider ID      •   New Service Provider ID      •   Authorization from old facilities-based Service Provider      •   Status Change Cause Code      •   LRN      •   Class DPC      •   Class SSN      •   LIDB DPC      •   LIDB SSN      •   CNAM DPC      •   CNAM SSN      •   ISVM DPC      •   ISVM SSN      •   WSMSC DPC      •   WSMSC SSN      •   Porting to Original      •   Billing Service Provider ID      •   End-User Location — Value      •   End-User Location — Type      •   SV Type (if supported by the Service Provider SOA)      •   Alternative SPID (if supported by the Service Provider SOA)            R5-18.2   Create Subscription Version — Due Date Consistency Validation    NPAC SMS shall verify the old and new Service Provider due dates are the same upon initial Subscription Version creation for an Inter-Service Provider port.          R5-18.3   Create Subscription Version — Due Date Validation    DELETED          RR5-131   Create “Inter-Service Provider Port” Subscription Version — Due Date Validation For First Port    DELETED          RR5-132   Create “Inter-Service Provider Port” Subscription Version — Due Date Validation For Subsequent Port Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window    DELETED          R5-18.4   Create Subscription Version — Ported TN NPA-NXX Validation    NPAC SMS shall verify that the NPA-NXX to be ported exists as an NPA-NXX in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider port.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-15    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             RR5-44   Create Subscription Version — Due Date Validation for NPA-NXX effective date    DELETED          RR5-119   Subscription Version — Due Date Validation for Second/Concurrence Create Message for a Subscription Version Inter-Service Provider Port    NPAC SMS shall allow the due date to be a past date upon Subscription Version concurrence (2nd create for this Subscription Version) for an Inter-Service Provider port. (Formerly NANC 294 Req 1)          R5-18.5   Create Subscription Version — Service Provider ID Validation    NPAC SMS shall verify that the old and new Service Provider IDs exist in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider port.          R5-18.6   Create Subscription Version — LRN Validation    NPAC SMS shall verify that an input LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version creation for an Inter-Service Provider port.          R5-18.7   Create Subscription Version — Originating Service Provider Validation    NPAC SMS shall verify that the originating user is identified as the new or old Service Provider on the incoming Subscription Version upon Subscription Version creation for an Inter-Service Provider port.          R5-18.8   Create Subscription Version — Duplicate Authorization Validation    NPAC SMS shall verify that authorization for transfer of service for a given Service Provider does not already exist when a Service Provider creates a Subscription Version for an Inter-Service Provider port.          R5-18.9   Create Subscription Version — Service Provider ID Validation    NPAC SMS shall verify that the incoming New and Old Service Provider IDs match the IDs in the current pending version, if one exists, upon Subscription Version creation for an Inter-Service Provider port.          R5-18.10   Create Subscription Version — Status Change Cause Code Validation    NPAC SMS shall require and only allow the Status Change Cause Code to be set when the Old Service Provider authorization is set to false.          R5-19.1   Create Subscription Version — Old Service Provider ID Validation    NPAC SMS shall verify that the old Service Provider ID on the version being created is equal to the new Service Provider ID on the active Subscription Version, if an active version exists upon Subscription Version creation for an Inter-Service Provider port.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-16    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             R5-19.2   Create Subscription Version — Old Service Provider ID Validation — No Active Subscription Version    NPAC SMS shall validate that the old Service Provider in the create message is the Service Provider to which the TN’s NPA-NXX is assigned (as stored in the NPAC SMS service provider data tables) if there is currently no active Subscription Version for the TN in the NPAC SMS.          R5-19.3   Create Subscription Version — Timer Type Selection    NPAC SMS shall if the old and new service provider timer types match set the subscription version timer type to that timer type.          R5-19.4   Create Subscription Version — Timer Type Selection — Mismatch    NPAC SMS shall if the old and new service provider timer types do not match set the subscription version timer type to the longer timer type of the port out type for the old service provider and the port in type of the new service provider.          R5-19.5   Create Subscription Version — Business Hours and Days Selection    NPAC SMS shall if the old and new service provider business hours and days match set the subscription version business type to the business type for the business hours and days supported.          R5-19.6   Create Subscription Version — Business Hours and Days Selection — Mismatch    NPAC SMS shall if the old and new service provider business hours and days do not match set the subscription version business type to the shorter business hours and days.          R5-20.1   Create Subscription Version — Validation Failure Notification    NPAC SMS shall send an appropriate error message to the originating NPAC personnel or SOA to NPAC SMS interface user if any of the validations fail upon Subscription Version creation for an Inter-Service Provider port.          R5-20.2   Create Subscription Version — Validation Failure — No Update    NPAC SMS shall not apply the incoming data to an existing subscription if any of the validations fail upon Subscription Version creation for an Inter-Service Provider port.          R5-20.3   Create Subscription Version — Validation Failure — No Create    NPAC SMS shall not create a new Subscription Version, if a version does not exist, if any of the validations fail upon Subscription Version creation for an Inter-Service Provider port.          R5-20.4   Create Subscription Version — Validation Success — Update Existing    NPAC SMS shall apply the incoming data to an existing Subscription Version if all validations pass upon Subscription Version creation for an Inter-Service Provider or port.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-17    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             R5-20.5   Create Subscription Version — Validation Success — Create New    NPAC SMS shall create a new Subscription Version, if a version does not already exist, if all validations pass at the time of Subscription Version creation for an Inter-Service Provider port.          R5-21.1   Initial Concurrence Window — Tunable Parameter    NPAC SMS shall provide long and short Initial Concurrence Window tunable parameters which are defined as the number of business hours subsequent to the time the Subscription Version was initially created by which both Service Providers can authorize transfer of service if this is an Inter-Service Provider port.          R5-21.2   Initial Concurrence Window — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Initial Concurrence Window tunable parameters.          R5-21.3   Long Initial Concurrence Window — Tunable Parameter Default    NPAC SMS shall default the long Initial Concurrence Window tunable parameter to 9 business hours.          R5-21.4   Short Initial Concurrence Window — Tunable Parameter Default    NPAC SMS shall default the short Initial Concurrence Window tunable parameter to 1 business hour.          R5-21.6   Create Subscription Version — Set to Pending    NPAC SMS shall set a Subscription Version to pending upon successful subscription creation and the Old Service Provider has authorized transfer of service if this is an Old Service Provider create request for an Inter-Service Provider port.          R5-21.7   Create Subscription Version — Notify User Success    NPAC SMS shall notify the old and new Service Providers when a Subscription Version is set to pending upon successful subscription creation for an Inter-Service Provider port.          RR5-2.1   Create Subscription Version — Set to Conflict    NPAC SMS shall set a Subscription Version directly to conflict and set the cause code, if the Subscription Version passed validations, but this is a create request from the Old Service Provider and the Old Service Provider did not authorize transfer of service for an Inter-Service Provider port and specified a cause code.          RR5-2.2   Create Subscription Version — Set Conflict Timestamp    NPAC SMS shall set the conflict timestamp to the current time when a Subscription Version is set to conflict at the time of subscription version creation for an Inter-Service Provider port.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-18    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             RR5-2.3   Create Subscription Version — Conflict Notification    NPAC SMS shall notify the Old and New Service Provider when a Subscription Version is set to conflict at the time of Subscription Version creation for an Inter-Service Provider or port.          RR5-2.4   Cause Code in Conflict Notification — Creation    NPAC SMS shall include the cause code in the conflict notification to the Old and New Service Provider when the Old Service Provider did not authorize transfer of service for an Inter-Service Provider port on creation.          R5-22   Create Subscription Version — Initial Concurrence Window Tunable Parameter Expiration    NPAC SMS shall send a notification to the Service Provider (old or new) who has not yet authorized the transfer of service, when the Initial Concurrence Window tunable parameter for a pending Subscription Version has expired.          R5-23.1   Final Concurrence Window — Tunable Parameter    NPAC SMS shall provide long and short Final Concurrence Window tunable parameters which are defined as the number of business hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers can authorize transfer of subscription service for an Inter-Service Provider port.          R5-23.2   Final Concurrence Window Tunable — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Final Concurrence Window tunable parameters.          R5-23.3   Long Final Concurrence Window Tunable — Tunable Parameter Default    NPAC SMS shall default the long Final Concurrence Window tunable parameter to 9 business hours.          RR5-52   Short Final Concurrence Window Tunable — Tunable Parameter Default    NPAC SMS shall default the short Final Concurrence Window tunable parameter to 1 business hour.          R5-23.4       DELETED          RR5-117   New Service Provider Final Create Window Expiration Notification    NPAC SMS shall upon expiration of the Final Concurrence Window, where a new Service Provider has not sent authorization for the transfer of service, send a notification to both the old Service Provider that supports the Final Create Window Expiration Notification and the new Service Provider that supports the Final Create Window Expiration Notification via the SOA to NPAC SMS Interface, to inform them of the timer expiration. (Formerly NANC 240 Req 1)          RR5-118   New Service Provider Final Create Window Expiration Notification — Sending of Cause Code    NPAC SMS shall only send the Subscription Version Status Change Cause Code in the Final Create Window Expiration Notification when the old Service Provider authorization is FALSE. (Formerly NANC 240 Req 2)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-19    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             RR5-56   Create Inter-Service Provider Port-to-Original Port — NPAC and SOA After NPA-NXX-X Creation    NPAC SMS shall reject an inter-service provider Subscription Version Create message, where there is no active subscription version for the requested TN in the NPAC SMS, or an inter-service provider Port-to-Original Subscription Version Create message, for a TN within the 1K Block, from NPAC Personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, after the Creation of the NPA-NXX-X, and prior to the existence of the Block in the NPAC SMS. (Previously SV-180)          RR5-121   Create Intra-Service Provider Port-to-Original Port — NPAC and SOA After NPA-NXX-X Creation    NPAC SMS shall reject an intra-service provider Port-to-Original Subscription Version Create message for a TN within the 1K Block, from NPAC Personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, after the Creation of the NPA-NXX-X, and prior to the existence of the Block in the NPAC SMS. (Previously NANC 230 Req 2)          RR5-57   Create Intra- or Inter-Service Provider Port-to-Original Subscription Version — After Block Activation    NPAC SMS shall validate that the New Service Provider is the Block Holder, in an intra-service provider port-to-original subscription version create message or inter-service provider port-to-original port for a TN within the 1K Block, once the Block exists in the NPAC SMS. (Previously SV-190)          R5-23.5   Activation without Old Service Provider Authorization    NPAC SMS shall allow a pending Subscription Version to be activated without an old Service Provider authorization for transfer of service.          R5-23.6   Activation without Old Service Provider Authorization — Time restriction    NPAC SMS shall allow activation without Old Service Provider concurrence only after the final concurrence window timer has expired.          RR5-23.3   Old Service Provider Final Concurrence Timer Expiration Notification    NPAC SMS shall upon expiration of the Final Concurrence Timer send a notification to the old service provider via the SOA to NPAC SMS interface to inform them of the timer expiration.          5.1.2.2.1.2   Subscription Version Creation — Intra-Service Provider Port    This section provides the Subscription Version Creation requirements for performing an Intra-Service Provider port of a TN. An Intra-Service Provider port of a TN is when a TN is ported to a new location within the current Service Provider network (i.e., the routing data is modified, but the Service Provider remains the same). A “port to original” for an Intra-Service Provider port should be handled by submission of an Intra-Service Provider “port to original” subscription version request to the NPAC SMS.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-20    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management             RR5-4   Create “Intra-Service Provider Port” Subscription Version — Current Service Provider Input Data    NPAC SMS shall require the following data from the NPAC personnel or the Current (New) Service Provider at the time of Subscription Version Creation for an Intra-Service Provider port when NOT porting to original:     •   LNP Type — port type This field must be set to “LISP for Intra-Service Provider support”.      •   Ported Telephone Number(s) — this entry can be a single TN or a continuous range of TNs that identifies a subscription or group of Subscription Versions that share the same attributes.      •   Due Date — date on which Intra-Service Provider port is planned to occur.      •   New facilities-based Service Provider ID — current Service Provider within which the Intra-Service Provider port will occur.      •   Old facilities-based Service Provider ID — current Service Provider within which the Intra-Service Provider port will occur.      •   Location Routing Number (LRN) — identifier of the ported-to switch      •   Class DPC      •   Class SSN      •   LIDB DPC      •   LIDB SSN      •   CNAM DPC      •   CNAM SSN      •   ISVM DPC      •   ISVM SSN      •   WSMSC DPC (if supported by the Service Provider SOA)      •   WSMSC SSN (if supported by the Service Provider SOA)      •   Porting to Original — flag indicating whether or not this is a ‘porting-to-original” port. This flag must be set to “FALSE” for this type of Intra-Service Provider port.      •   SV Type (if supported by the Service Provider SOA)            RR5-122   Create “Intra-Service Provider porting to original Port” Subscription Version — New Service Provider Input Data    NPAC SMS shall require the following data from NPAC personnel or the new Service Provider upon Subscription Version creation for an Intra-Service Provider “porting to original” port:     •   Local Number Portability Type — Port Type. This field must be set to “LISP” for “Intra-Service Provider porting to original” ports.      •   Ported Telephone Number(s) — this entry can be a single TN or a continuous range of TNs that identifies a subscription or a group of Subscription Versions that share the same attributes.      •   Due Date — date on which Intra-Service Provider port is planned to occur.      •   New Facilities-based Service Provider ID — current Service Provider within which the Intra-Service Provider port will occur.      •   Old Facilities-based Service Provider ID — current Service Provider within which the Intra-Service Provider port will occur.      •   Porting to original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “TRUE” for “Intra-Service Provider porting to original” ports, and set to “FALSE” for other Intra-Service Provider ports.                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-21    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management       •   Old Facilities-based Service Provider ID – current Service Provider within which the Intra-Service Provider port will occur.      •   Porting to original — flag indicating whether or not this is a “porting to original” port. This flag must be set to “TRUE” for “Intra-Service Provider porting to original” ports, and set to “FALSE” for other Intra-Service Provider ports.    (Previously NANC 230 Req 1)          RR5-5   Create “Intra-Service Provider Port” Subscription Version — Current Service Provider Optional Input Data    NPAC SMS shall accept the following optional fields from the NPAC personnel or the Current Service Provider upon a Subscription Version Creation for an Intra-Service Provider port: (reference NANC 399)     •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   Alternative SPID (if supported by the Service Provider SOA)            RR5-6.1   Create “Intra-Service Provider Port” Subscription Version — Field-level Data Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-6 upon Subscription Version creation for an Intra-Service Provider port: (reference NANC 399)     •   LNP Type       •   Ported TN(s)       •   Current Service Provider Due Date       •   Old Service Provider ID       •   New Service Provider ID       •   LRN       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN       •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC (if supported by the Service Provider SOA)       •   WSMSC SSN (if supported by the Service Provider SOA)       •   Porting to Original       •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   SV Type (if supported by the Service Provider SOA)       •   Alternative SPID (if supported by the Service Provider SOA)                     Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-22    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-6.2   Create “Intra-Service Provider Port” Subscription Version — New and Old Service Provider ID Match    NPAC SMS shall validate that the new and old Service Provider IDs are identical to the ID of the requesting user at the time of Subscription Version creation for an Intra-Service Provider port.          RR5-6.3   Create “Intra-Service Provider Port” Subscription Version — Due Date Validation    DELETED          RR5-133   Create “Intra-Service Provider Port” Subscription Version — Due Date Validation For First Port    DELETED          RR5-134   Create “Intra-Service Provider Port” Subscription Version — Due Date Validation For Subsequent Port Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window    DELETED           RR5-6.4   Create “Intra-Service Provider Port” Subscription Version — Ported TN NPA-NXX Validation    NPAC SMS shall verify that the NPA-NXX for the TN to be ported exists as an NPA-NXX in the NPAC SMS system upon Subscription Version creation for an Intra-Service Provider port.          RR5-45   Create “Intra-Service Provider Port” Subscription Version – Due Date Validation for NPA-NXX effective date    DELETED           RR5-6.5   Create “Intra-Service Provider Port” Subscription Version — LRN Validation    NPAC SMS shall verify that the LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version creation for an Intra-Service Provider port.          RR5-6.6   Create “Intra-Service Provider Port” Subscription Version — Duplicate Authorization Validation    NPAC SMS shall verify that the authorization for transfer of service for a given Service Provider does not already exist when a Service Provider creates a Subscription Version for an Intra-Service Provider port.          RR5-6.7   Create “Intra-Service Provider Port” Subscription Version — Old Service Provider ID Validation    NPAC SMS shall verify that the old Service Provider ID on the version being created is equal to the new Service Provider ID on the active Subscription Version, if an active version exists, upon Subscription Version creation for an Intra-Service Provider port.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-23    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-6.8   Create “Intra-Service Provider Port” Subscription Version — No Active Version    NPAC SMS shall allow an Intra-Service Provider port to occur for a telephone number not associated with a current active version.          RR5-6.9   Create “Intra-Service Provider Port” Subscription Version — Old Service Provider ID Validation — No Active Subscription Version    NPAC SMS shall validate that the old Service Provider in the create message is the Service Provider to which the TN’s NPA-NXX is assigned (as stored in the NPAC SMS service provider data tables) if there is currently no active Subscription Version for the TN in the NPAC SMS.          RR5-7.1   Create “Intra-Service Provider Port” Subscription Version — Validation Failure Notification    NPAC SMS shall send an appropriate error message to the originating NPAC personnel or SOA to NPAC SMS Interface if any of the validations fail at the time of Subscription Version creation for an Intra-Service Provider port.          RR5-7.2   Create “Intra-Service Provider Port” Subscription version — Validation Failure — No Create    NPAC SMS shall not create a new Subscription Version if any of the validations fail at the time of Subscription Version creation for an Intra-Service Provider port.          RR5-8   Create “Intra-Service Provider Port” Subscription version — Set to Pending    NPAC SMS shall set a Subscription Version to pending upon successful creation of a Subscription Version for an Intra-Service Provider port.          RR5-9   Create “Intra-Service Provider Port” Subscription version — Notify User of Creation    NPAC SMS shall notify the current Service Provider when a Subscription Version is set to pending upon a successful creation of a Subscription Version for an Intra-Service Provider port.          RR5-58   Create Intra-Service Provider Port – NPAC Personnel After NPA-NXX-X Creation    NPAC SMS shall allow NPAC personnel to create intra-service provider ports for a TN within the 1K Block, after the Creation of the NPA-NXX-X and up to the NPA-NXX-X’s Effective Date, only where the new/old Service Provider is the Code Holder SPID, and a previously active SV does NOT exist in the NPAC SMS. (Previously SV-160)          RR5-59   Create Intra-Service Provider Port – SOA After NPA-NXX-X Creation    NPAC SMS shall reject an intra-service provider Subscription Version Create message for a TN within the 1K Block, from a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, after the Creation of the NPA-NXX-X Information, and a previously active SV does NOT exist in the NPAC SMS. (Previously SV-170)                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-24    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            5.1.2.2.2   Subscription Version Modification    This section provides the requirements for the Subscription Version Modification functionality, which is executed upon the user requesting modify Subscription Version.          RR5-123   Validation of LATA ID for Subscription Version Modifies    NPAC shall reject Subscription Version Modify Requests if the NPA-NXX of the TN and the NPA-NXX of the LRN have different LATA IDs.(Previously NANC 319 Req 7)          R5-25   Modify Subscription Version — Invalid Version Status Notification    NPAC SMS shall return an error to the originating NPAC personnel or NPAC SOA Low-tech Interface users, or SOA to NPAC SMS interface user if the version status is sending, failed, partial failure, canceled, active with a Failed SP List or old upon Subscription Version modification.          5.1.2.2.2.1   Modification of a Pending or Conflict Subscription Version            R5-26   Modify Subscription Version — Version Identification    NPAC SMS shall receive the following data from the originating NPAC personnel or SOA to NPAC SMS interface user to identify a pending or conflict Subscription Version to be modified:  Ported Telephone Number (or a specified range of numbers) and status or Subscription Version ID          R5-27.1   Modify Subscription Version — New Service Provider Data Values    NPAC SMS shall allow the following data to be modified in a pending or conflict Subscription Version for an Inter-Service Provider or Intra-Service Provider port by the new/current Service Provider or NPAC personnel: (reference NANC 399)     •   Location Routing Number (LRN) — the identifier of the ported to switch.       •   Due Date — date on which transfer of service from old facilities-based Service Provider to new facilities-based Service Provider is planned to occur.       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN       •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC (if supported by the Service Provider SOA)       •   WSMSC SSN (if supported by the Service Provider SOA)       •   SV Type (if supported by the Service Provider SOA)       •   Alternative SPID (if supported by the Service Provider SOA)                     Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-25    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-27.2   Modify “porting to original” Subscription Version — New Service Provider Data Values    NPAC SMS shall allow the following data to be modified in a pending, or conflict Subscription Version for a “porting to original” port by the new Service Provider or NPAC personnel:     •   Due Date — New Service Provider date on which “port to original” is planned to occur.            R5-27.3   Modify Subscription Version — Old Service Provider Data Values    NPAC SMS shall allow the following data to be modified in a pending or conflict Subscription Version for an Inter-Service Provider port by the old Service Provider or NPAC personnel:     •   Due Date — date on which transfer of service from old facilities-based Service Provider to new Service Provider is planned to occur.       •   Old Service Provider Authorization       •   Status Change Cause Code            R5-27.4   Old Service Provider authorization Flag Modification to False    NPAC SMS shall allow the old Service Provider to modify the old Service Provider authorization flag to false and set the cause code. As a result the NPAC SMS will set the Subscription Version status to conflict provided the version has not previously been set into conflict by the Old Service Provider for reasons other than cancellation.          R5-28   Modify Subscription Version — New Service Provider Optional input data.    NPAC SMS shall accept the following optional fields from the NPAC personnel or the new Service Provider upon modification of a pending or conflict Subscription version: (reference NANC 399)     •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   Alternative SPID (if supported by the Service Provider SOA)            R5-29.1   Modify Subscription Version — Field-level Data Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-6 upon Subscription Version modification. (reference NANC 399)     •   LNP Type       •   Ported TN(s)       •   Old Service Provider Due Date       •   New Service Provider Due Date       •   Old Service Provider Authorization       •   Status Change Cause Code       •   Old Service Provider ID       •   New Service Provider ID       •   LRN       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN                     Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-26    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management       •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC       •   WSMSC SSN       •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   SV Type (if supported by the Service Provider SOA)       •   Alternative SPID (if supported by the Service Provider SOA)            R5-29.2   Modify Subscription Version — Due Date Validation    DELETED           RR5-135   Modify Subscription Version — Due Date Validation For Port Within the NPA-NXX-X Holder Information Effective Date Window–Tunable Window    DELETED           RR5-163   Modification of Subscription Version Due Date – Validation    NPAC SMS shall verify that the Due Date is equal to, or greater than, the NPA-NXX Live TimeStamp, and equal to or greater than the current date, when modifying a Subscription Version. (previously NANC 394, Req 7)          RR5-54   Modify Subscription Version — Due Date Validation for NPA-NXX Effective Date    DELETED           R5-29.3   Modify Subscription Version — LRN Validation    NPAC SMS shall verify that an input LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version modification.          R5-29.4   Modify Subscription Version — Originating Service Provider Validation    NPAC SMS shall verify that the originating user is identified as the new or old Service Provider on the current Subscription Version, if one exists, upon Subscription Version modification.          R5-29.5   Modify Subscription Version — Status Change Cause Code Validation    NPAC SMS shall require and only allow the Status Change Cause Code to be set when the Old Service Provider authorization is set to false.          R5-30.1   Modify Subscription Version — Validation Failure Notification    NPAC SMS shall send an error message to the originating user if the modified pending or conflict Subscription Version fails validations.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-27    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-30.2   Modify Subscription Version — Validation Error Processing    NPAC SMS shall leave the original version intact upon validation failure of a modified pending or conflict Subscription Version.          R5-31.3   Modify Subscription Version — Successful Modification Notification    NPAC SMS shall send an appropriate message to the old and new Service Providers upon successful modification of a Subscription Version.          RR5-10.1   Modify Subscription Version — Set Conflict Timestamp    NPAC SMS shall set the conflict timestamp to the current time when a Subscription Version is set to conflict upon Subscription Version modification.          RR5-10.2   Modify Subscription Version — Conflict Notification    NPAC SMS shall notify the Old and New Service Provider when a Subscription Version is set to conflict upon Subscription Version modification.          RR5-10.3   Modify Subscription Version — Cause Code in Notification    NPAC SMS shall include the cause code for conflict in the conflict notification to the Old and New Service Provider when a Subscription Version is set to conflict upon Subscription Version modification.          5.1.2.2.2.2   Modification of an Active/Disconnect Pending Subscription Version            RR5-136   Modify Active Subscription Version with a Failed-SP List – Invalid Request Notification    NPAC SMS shall send an appropriate error message to the originating user if the Failed-SP list contains any entries upon a request to modify an “active” subscription version.          RR5-11   Modify Active/Disconnect-Pending Subscription Version — Service Provider Owned    NPAC SMS shall allow only NPAC personnel and the current Service Provider to modify their own active/disconnect-pending Subscription Versions.          R5-35   Modify Active Subscription Version — Version Identification    NPAC SMS shall require the following data from NPAC personnel or SOA to NPAC SMS interface users to identify the active Subscription Version to be modified:  Ported Telephone Numbers (or a specified range of numbers) and status of Active or Subscription Version ID                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-28    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-36   Modify Active Subscription Version — Input Data    NPAC SMS shall allow the following data to be modified for an active Subscription Version: (reference NANC 399)     •   Location Routing Number (LRN) — the identifier of the ported to switch       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN       •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC (if supported by the Service Provider SOA)       •   WSMSC SSN (if supported by the Service Provider SOA)       •   SV Type (if supported by the Service Provider SOA)       •   Alternative SPID (if supported by the Service Provider SOA)            R5-37   Active Subscription Version — New Service Provider Optional input data.    NPAC SMS shall accept the following optional fields from the new Service Provider or NPAC personnel for an active Subscription Version to be modified:     •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   Alternative SPID (if supported by the Service Provider SOA)            R5-38.1   Modify Active Subscription Version — Field-level Data Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-6 upon Subscription Version modification of an active version: (reference NANC 399)     •   LRN       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN       •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC (if supported by the Service Provider SOA)       •   WSMSC SSN (if supported by the Service Provider SOA)       •   Billing Service Provider ID       •   End-User Location — Value       •   End-User Location — Type       •   SV Type (if supported by the Service Provider SOA)       •   Alternative SPID (if supported by the Service Provider SOA)                     Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-29    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-38.2   Modify Active Subscription Version — LRN Validation    NPAC SMS shall verify that an input LRN is associated with the new Service Provider in the NPAC SMS system upon Subscription Version modification of an active version.          RR5-124   Modify Disconnect Pending Subscription Version — Input Data    NPAC SMS shall allow the following data to be modified for a disconnect pending Subscription Version:     •   Customer Disconnect Date       •   Effective Release Date    (Previously NANC 249 Req 1)          RR5-125   Modify Disconnect Pending Subscription Version — Field-level Data Validation    NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-6 upon Subscription Version modification of a disconnect pending version:     •   Customer Disconnect Date       •   Effective Release Date    (Previously NANC 249 Req 2)          RR5-126   Modify Disconnect Pending Subscription Version – Valid Dates for CDD and ERD    NPAC SMS shall allow a Subscription Version Modify Disconnect Pending Request, to contain date/time values in the past for the Customer Disconnect Date and Effective Release Date. (Previously NANC 249 Req 6)          RR5-127   Modify Disconnect Pending Subscription Version — Version Identification    NPAC SMS shall require the following data from NPAC personnel ,NPAC SOA Low-tech Interface users,or SOA to NPAC SMS interface users to identify the disconnect pending Subscription Version to be modified:     •   Ported Telephone Numbers (or a specified range of numbers) and status of Disconnect Pending          or       •   Subscription Version ID    (Previously NANC 249 Req 3)          RR5-128   Modify Disconnect Pending Subscription Version – Rejection for Empty CDD    NPAC SMS shall reject a Subscription Version Modify Disconnect Pending Request, if the new value for the Customer Disconnect Date is not populated. (Previously NANC 249 Req 5)  Note: If changing the Customer Disconnect Date, the date must be populated in the message that is sent to the NPAC. If the SOA is not changing the date, the date must still be sent to the NPAC in the Modify Disconnect Pending Request with the same/current value.  Note: In the case where a SOA is modifying a range of disconnect-pending Subscription Versions that have different CDD or ERD values, all of the Subscription Versions in that range will be updated to the same CDD or ERD value, even though they previously had different values.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-30    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-39.1   Modify Active/Disconnect Pending Subscription Version — Validation Failure Notification    NPAC SMS shall send an appropriate error message to the originating user if the modified active/disconnect pending Subscription Version fails validations.          R5-39.2   Modify Active/Disconnect Pending Subscription Version — Validation Error Processing    NPAC SMS shall leave the original version intact upon validation failure of a modified active/disconnect pending Subscription Version.          RR5-46   Modify Active Subscription Version- Creation of Old Subscription Version    DELETED           RR5-47   Modify Active Subscription Version- Old Subscription Version No Broadcast    DELETED           R5-40.1   Modify Active Subscription Version — Broadcast Date/Time Stamp    NPAC SMS shall record the current date and time as the broadcast date and time stamp upon initiation of broadcasting of the modified active Subscription Version.          R5-40.3   Modify Active Subscription Version — Modification Success User Notification    NPAC SMS shall notify the originating user indicating successful modification of an active Subscription Version.          R5-40.4   Modify Active Subscription Version — Broadcast complete Time Stamp    NPAC SMS shall record the current date and time as the Broadcast Complete Date and Time Stamp, after one Local SMS has successfully acknowledged modifying the new Subscription Version.          R5-41   Activation Of A Modified Subscription Version    NPAC SMS shall proceed with the broadcast modified active subscription process upon successful modification of an active Subscription Version.          RR5-129   Activation Of A Modified Disconnect Pending Subscription Version when ERD is Modified to Current Date    NPAC SMS shall proceed with the broadcast immediate disconnect subscription process upon successful modification of a disconnect pending Subscription Version, only in cases where the Effective Release Date has been modified to the current date/time or previous date/time, in the NPAC SMS. (Previously NANC 249 Req 4)  Note: If the ERD is set to a future date/time, the NPAC SMS will not broadcast any updates at the time of modification. The disconnect broadcast will occur once the future date/time has been reached in the NPAC SMS.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-31    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-41.1   Broadcast Modified Active Subscription — Local SMS Identification    NPAC SMS shall determine which Local SMSs to send the Subscription Version to by identifying all Local SMSs that are accepting Subscription version data downloads for the given NPA-NXX.          RR5-41.2   Broadcast Modified Active Subscription — Send to Local SMSs    NPAC SMS shall send the modified Subscription version via the NPAC SMS to Local SMS Interface to the Local SMSs          RR5-41.3   Broadcast Modified Active Subscription — Set to Sending    NPAC SMS shall set the Subscription Version status to sending upon sending the Subscription version to the Local SMSs.          RR5-41.4   Modify Active Subscription Version — Return Status    NPAC SMS shall upon completion of the broadcast (failed or successful) return the status of the modified active subscription to its previous state.          RR5-41.5   Modify Active Subscription Activation Retry Attempts — Tunable Parameter    NPAC SMS shall use the Subscription Modification Retry Attempts tunable parameter which defines the number of times a new Subscription Version will be sent to a Local SMS which has not acknowledged receipt of the modify request.          RR5-41.6   Modify Active Subscription Activation Retry Interval — Tunable Parameter    NPAC SMS shall use the Subscription Modification Retry Interval tunable parameter, which defines the delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the modify request.          RR5-41.7   Modify Active Subscription Version Failure Retry    NPAC SMS shall resend the modified Subscription Version a Subscription Modification Retry Attempts tunable parameter number of times to a Local SMS that has not acknowledged the receipt of the modification request once the Subscription Activation Retry Interval tunable parameter expires.          RR5-41.8   Modify Active Subscription Version Failure — Status Sending    NPAC SMS shall retain the status for the Subscription Version being modified as sending until the earlier of the Subscription Version retry period has expired for all Local SMSs, or until all Local SMSs have acknowledged the modification.          RR5-41.9   Modify Active Subscription Version Failure — Local SMS Identification    NPAC SMS shall notify the NPAC SMS Administrator of all Local SMSs where a modify has failed, once each Local SMS has successfully responded or failed to respond during the modification retry period.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-32    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-41.10   Subscription Version Activation — Resend to Failed Local SMSs    NPAC SMS shall provide NPAC SMS personnel with the functionality to re-send modify active Subscription Version requests to all failed Local SMSs.          RR5-41.11   Modify Active Subscription Version — Failed Local SMS Notification Current Service Provider    NPAC SMS shall send a list to the Current Service Provider of all Local SMSs that failed modification when a Subscription Version modify active fails.          5.1.2.2.3   Subscription Version Conflict    This section provides the requirements for the functionality to place a Subscription Version in to conflict and remove it from conflict.  NOTE: An old Service Provider can place a subscription version in conflict by setting the authorization flag to “False”, as noted in        requirement R5-27.4          5.1.2.2.3.1   Placing a Subscription Version in Conflict            R5-42   Conflict Subscription Version — Version Identification    NPAC SMS shall require the following data from NPAC personnel or Old Service Provider to identify the Subscription Version to be placed in conflict:  Ported Telephone Number (or a specified range of numbers) or Subscription Version ID          R5-43.1   Conflict Subscription Version — Invalid Status Notification    NPAC SMS shall send an error message to the NPAC personnel or old Service Provider if the version status is not pending or cancel pending upon attempting to set the Subscription Version to conflict.          R5-43.2   Conflict Subscription Version — No Cause Code Notification    NPAC SMS shall send an error message to the SOA if the cause code is not specified upon setting the Subscription Version to conflict.          RR5-42.1   Conflict Subscription Version — Old Service Provider Number Restriction    NPAC SMS shall only allow a subscription version to be placed into conflict by the Old Service provider one time, which includes the changing of the cause code on a subscription version.          RR5-42.2   Conflict Subscription Version — Conflict Restriction Window    NPAC SMS shall provide a Conflict Restriction Tunable which is defined as the time on the business day prior to the New Service Provider due date that a pending Subscription Version can no longer be placed into conflict state by the old Service Provider.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-33    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-50   Conflict Subscription Version — Conflict Restriction Window- Old Service Provider    NPAC SMS shall provide a Conflict Restriction Window that restricts an Old Service Provider from putting a Subscription Version into Conflict.          RR5-51   Conflict Subscription Version – Conflict Restriction Rules for Old Service Provider    NPAC SMS shall restrict a Subscription Version from being placed into Conflict by the Old Service Provider, when the Conflict Restriction Window Tunable Time is reached AND the Final Concurrence Timer (T2) has expired.          AR5-2   Conflict Restriction Window Tunable due date value    The date used for the Conflict Restriction Window Tunable calculation relies on the date value specified in the New Service Provider due date.          RR5-42.3   Conflict Subscription Version — Conflict Restriction Window Tunable    NPAC SMS shall allow the NPAC SMS Administrator to modify the Conflict Restriction Window Tunable parameter.          RR5-42.4   Conflict Subscription Version — Conflict Restriction Window Tunable Default    NPAC SMS shall default the Conflict Restriction Window Tunable parameter to 17:00/18:00 UTC, adjusted for Standard/Daylight time changes.          RR5-42.5   Conflict Subscription Version – Short Timer Usage    NPAC SMS shall not apply the Conflict Restriction Window Tunable to subscription versions being ported using short timers.          R5-44.1   Conflict Subscription Version — Set Status to Conflict    NPAC SMS shall, upon placing a Subscription Version into conflict, set the version status to conflict.          R5-44.2   Conflict Subscription Version — Set Conflict Date and Time    NPAC SMS shall, upon placing a Subscription Version into conflict, record the current date and time as the conflict date and time stamp.          R5-44.3   Conflict Subscription Version — Successful Completion Message    NPAC SMS shall issue an appropriate message to the originating user and the Old and New Service Providers indicating successful completion of the process to place a subscription in conflict.          R5-45.1   Conflict Expiration Window — Tunable Parameter    NPAC SMS shall provide a Conflict Expiration Window tunable parameter which is defined as a number of calendar days a Subscription Version will remain in conflict prior to cancellation.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-34    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-45.2   Conflict Expiration Window — Tunable Parameter Default    NPAC SMS shall default the Conflict Expiration Window tunable parameter to 30 calendar days.          R5-45.3   Conflict Expiration Window — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administration to modify the Conflict Expiration Window tunable parameter.          R5-45.4   Conflict Subscription Version — Set to Cancel    NPAC SMS shall set the status of the Subscription Version to cancel after a Subscription Version has been in conflict for a Conflict Expiration Window tunable parameter number of calendar days.          R5-45.5   Conflict Subscription Version — Set Cancellation Date Timestamp    NPAC SMS shall set a Subscription Version cancellation date timestamp to the current time upon setting a conflict Subscription Version to cancel.          R5-45.6   Conflict Subscription Version — Inform Service Providers of Cancel Status    NPAC SMS shall notify both Service Providers after a Subscription Version status is set to cancel from conflict.          5.1.2.2.3.2   Removing a Subscription Version from Conflict            R5-46   Conflict Resolution Subscription Version — Version Identification    NPAC SMS shall require the following data from the NPAC personnel user, new, or old Service Provider to identify the Subscription Version to be set from conflict to pending:  Ported Telephone Number, (or a specified range of numbers) or Subscription Version ID          R5-47   Conflict Resolution Subscription Version — Invalid Status Notification    NPAC SMS shall send an error message to the originating user if the Subscription Version status is not in conflict upon attempting to set the Subscription Version to pending.          R5-50.1   Conflict Resolution Subscription Version — Set Status    NPAC SMS shall set the version status to pending if the Subscription Version is in conflict upon a request from NPAC personnel, new, or old service providers to set a Subscription Version to pending.          R5-50.2   Conflict Resolution Subscription Version — Status Message    NPAC SMS shall send an appropriate message to the originating user indicating successful completion of the process to set a subscription to pending.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-35    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-12.1   Conflict Resolution Subscription Version — Inform Both Service Providers of Pending Status    NPAC SMS shall inform both Service Providers when the status of a Subscription Version is set to pending for an Inter-Service Provider port.          RR5-12.3   Conflict Resolution New Service Provider Restriction Tunable Parameter    NPAC SMS shall provide long and short Conflict Resolution New Service Provider Restriction tunable parameters which are defined as a number of business hours after the subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the New Service Provider.          RR5-12.4   Long Conflict Resolution New Service Provider Restriction — Tunable Parameter Default    NPAC SMS shall default the long Conflict Resolution New Service Provider Restriction tunable parameter to 6 business hours.          RR5-12.5   Conflict Resolution New Service Provider Restriction Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administration to modify the long and short Conflict Resolution New Service Provider Restriction tunable parameters.          RR5-12.6   Short Conflict Resolution New Service Provider Restriction — Tunable Parameter Default    NPAC SMS shall default the short Conflict Resolution New Service Provider Restriction tunable parameter to 6 business hours.          RR5-14   Conflict Resolution Acknowledgment — Update Conflict Resolution Date and Time Stamp    NPAC SMS shall update the conflict resolution date and time stamp with the current date and time and set the old Service Provider Authorization flag to true when conflict is resolved.          RR5-137   Conflict Resolution Subscription Version – Restriction for Cause Code Values    NPAC SMS shall restrict the resolution of a Subscription Version with a status of conflict and a cause code value of 50 or 51, to only allow resolution by the Old Service Provider. (previously NANC 375, Req 1)          RR5-138   Conflict Resolution Subscription Version –Conflict Resolution New Service Provider Restriction Tunable Application    NPAC SMS shall apply the Conflict Resolution New Service Provider Restriction Tunable only for a Subscription Version with a status of conflict and a cause code value NOT EQUAL TO 50 or 51. (previously NANC 375, Req 2)          RR5-139   Conflict Resolution Subscription Version – Restricted Cause Code Notification    NPAC SMS shall send an error message to the New Service Provider if the Subscription Version status is conflict AND the cause code value is 50 or 51, upon attempting to set the Subscription Version to pending. (previously NANC 375, Req 3)                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-36    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-168   Regional Prevent Conflict Resolution 50/51 Tunable    NPAC SMS shall provide a Regional Prevent Conflict Resolution 50/51 tunable parameter, which is defined as an indicator on whether or not the prevention of conflict resolution for cause codes 50 or 51 by the New Service Provider is supported by the NPAC SMS for a particular NPAC Region. (previously NANC 375, Req 10)          RR5-169   Regional Prevent Conflict Resolution 50/51 Tunable Default    NPAC SMS shall default the Regional Prevent Conflict Resolution 50/51 tunable parameter to TRUE. (previously NANC 375, Req 11)          RR5-170   Regional Prevent Conflict Resolution 50/51 Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Regional Prevent Conflict Resolution 50/51 tunable parameter. (previously NANC 375, Req 12)          5.1.2.2.4   Subscription Version Activation    This section provides the requirements for the Subscription Version Activation functionality, which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to activate a Subscription Version. Requirements related to activation are contained in requirement R5-23.          R5-51.1   Activate Subscription Version — Version Identification    NPAC SMS shall require the following data from the NPAC personnel or new service provider to identify the Subscription Version to be activated:  Ported Telephone Number (or a specified range of numbers) or Subscription Version ID          R5-51.2   Activate Subscription Version — Broadcast Complete Date and Time Stamp    NPAC SMS shall record the current date and time as the Activation Broadcast Complete Date and Time Stamp, as soon as one Local SMS has successfully acknowledged activating the new Subscription Version.          RR5-21   Activate “porting to original” Subscription Version    NPAC SMS shall proceed with the “immediate” disconnect processing when a “porting to original” Subscription Version is activated.          RR5-22   Activate Subscription Version — Set Activation Received Timestamp    NPAC SMS shall set the Activation Received timestamp to the current date and time upon receiving a Subscription Version activation request.          R5-52   Activate Subscription Version — Invalid Status Notification    NPAC SMS shall send an error message to the originating user if the version status is not pending upon Subscription Version activation.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-37    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-53.1   Activate Subscription Version — Validation    NPAC SMS shall verify that a Subscription Version is in a valid pending state by checking that a new Service Provider time stamp exists and that the effective date of the NPA-NXX has been reached.          R5-53.2   Activate Subscription Version Validation Error Message    NPAC SMS shall send an error message to the originating user if the Subscription validation fails.          R5-53.3   Activate Subscription Version — Validate Due Date    NPAC SMS shall verify that a pending Subscription Version is eligible for activation by ensuring that the new Service Provider due date is less than or equal to the current date.          R5-55   Activate Subscription Version — Local SMS Identification    NPAC SMS shall determine which Local SMSs to send the Subscription Version to by identifying all Local SMS that are accepting Subscription Version data downloads for the given NPA-NXX.          R5-57.1   Activate Subscription Version — Send to Local SMSs    NPAC SMS shall send the activated Subscription Version for an activated Inter or Intra-Service Provider port via the NPAC SMS to Local SMS Interface to the Local SMSs.          R5-57.2   Activate Subscription Version — Set to Sending    NPAC SMS shall set the subscription status to sending upon sending the activated Subscription Version to the Local SMSs.          R5-57.3   Activate Subscription Version — Date and Time Stamp    NPAC SMS shall record the current date and time as the broadcast date and time stamp upon initiating sending the activated subscription to the Local SMSs.          R5-58.1   Local SMS Activation message logging    NPAC SMS shall log the activation responses resulting from the activation requests sent to the Local SMSs.          R5-58.2   Local SMS Activation Log Retention Period — Tunable Parameter    NPAC SMS shall provide a Local SMS Activation Log Retention Period tunable parameter which is defined as the number of calendar days Local SMS activation responses will remain in the log.          R5-58.3   Local SMS Activation Log Retention Period — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Local SMS Activation Log Retention Period tunable parameter.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-38    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-58.4   Local SMS Activation Log Retention Period — Tunable Parameter Default    NPAC SMS shall default the Local SMS Activation Log Retention Period tunable parameter to 90 calendar days.          R5-58.5   Local SMS Activation Message Log — Viewing    NPAC SMS shall allow NPAC personnel to view the Local SMS Activation Message log.          R5-59.1   Activate Subscription Version — Set Status of Current to Active    NPAC SMS shall, upon receiving successful activation acknowledgment from all involved Local SMSs, set the sending Subscription Version status to active.          R5-59.2   Activate Subscription Version — Set Status of Previous to Old    NPAC SMS shall upon receiving successful activation acknowledgment from any involved Local SMSs, set the previous active Subscription Version status to old.          R5-60.1   Subscription Activation Retry Attempts — Tunable Parameter    NPAC SMS shall provide a Subscription Activation Retry Attempts tunable parameter which defines the number of times a new Subscription Version will be sent to a Local SMS which has not acknowledged receipt of the activation request.          R5-60.2   Subscription Activation Retry Interval — Tunable Parameter    NPAC SMS shall provide a Subscription Activation Retry Interval tunable parameter, which defines the delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request.          R5-60.3   Subscription Activation Retry Attempts — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Activation Retry Attempts tunable parameter.          R5-60.4   Subscription Activation Retry Interval — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Activation Retry Interval tunable parameter.          R5-60.5   Subscription Activation Retry Attempts — Tunable Parameter Default    NPAC SMS shall default the Subscription Activation Retry Attempts tunable parameter to 3 times.          R5-60.6   Subscription Activation Retry Interval — Tunable Parameter Default    NPAC SMS shall default the Subscription Activation Retry Interval tunable parameter to 2 minutes.                   Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-39    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-60.7   Subscription Version Activation Failure Retry    NPAC SMS shall resend the activated Subscription Version a Subscription Activation Retry Attempts tunable parameter number of times to a Local SMS that has not acknowledged the receipt of the activation request once the Subscription Activation Retry Interval tunable parameter expires.          R5-60.8   Subscription Version Activation Failure — After Retries    NPAC SMS shall consider the Subscription Version activation for a given Local SMS failed once the applicable Activation Retry tunable parameter number of retries has been exhausted for that Local SMS.          R5-60.9   Subscription Version Activation Failure — Status Sending    NPAC SMS shall retain the status for the Subscription Version being activated as sending until the Subscription Version retry period expires for all Local SMSs, or until all Local SMSs have acknowledged the activation.          R5-60.10   Subscription Version Activation Failure — Local SMS Identification    NPAC SMS shall notify the NPAC SMS Administrator of all Local SMSs where new activation failed, once each Local SMS has successfully responded or failed to respond during the activation retry period.          R5-60.11   Subscription Version Activation Failure — Set Status to Partial Failure    NPAC SMS shall set the Subscription Version status to partial failure if the activation resulting from an subscription version activation request failed in one or more, but not all, of the Local SMSs.          R5-60.12   Subscription Version Partial Activation Failure — Set Status of Previous to Old    NPAC SMS shall set the status of a previous active version to old when a Subscription Version activation succeeds for at least one of the Local SMSs.          R5-61.1   Subscription Version Activation — Set Status to Failure    NPAC SMS shall set the status of the Subscription Version to failed if the Subscription Version fails activation resulting from an subscription version activation request in all the Local SMSs to which it was sent.          R5-61.2   Subscription Version Activation Subscription Version — Failure Notification    NPAC SMS shall notify the NPAC System Administrator when a Subscription Version fails activation at all of the Local SMSs.          R5-61.3   Subscription Version Activation — Resend to Failed Local SMSs    NPAC SMS shall provide NPAC SMS personnel with the functionality to re-send activate Subscription Version requests to all failed Local SMSs.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-40    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-22.1   Subscription Version Activation — Failed Local SMS Notification — Both Service Providers    NPAC SMS shall send a list to the Old and New Service Providers of all Local SMSs that failed activation when a Subscription Version is set to failed or partial failure subsequent to Subscription Version activation for an Inter-Service Provider port.          RR5-22.2   Subscription Version Activation — Failed Local SMS Notification — Current Service Provider    NPAC SMS shall send a list to the current Service Provider of all Local SMSs that failed activation when a Subscription Version is set to failed or partial failure subsequent to Subscription Version activation for an Intra-Service Provider port.          RR5-60   Activate Intra-Service Provider Port – After NPA-NXX-X Creation and Prior to the Existence of the Block    NPAC SMS shall allow NPAC personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to activate intra-service provider ports for a TN within the 1K Block, where there is no active Subscription Version in the NPAC SMS. (Previously SV-200)          RR5-61   Activate Port-to-Original Subscription Version – Broadcast of Subscription Data Creation    The NPAC SMS shall broadcast a new Subscription Version Create to a non-EDR Local SMS, upon activating a port-to-original Subscription Version, where the TN is within the range of a 1K Block, once the Block exists in the NPAC SMS. (Previously SV-210)          RR5-62   Activate Port-to-Original Subscription Version – Broadcast of Subscription Data Deletion    The NPAC SMS shall broadcast a Subscription Version Delete to an EDR Local SMS, upon activating a port-to-original Subscription Version, where the TN is within the range of a 1K Block, once the Block exists in the NPAC SMS. (Previously SV-220)          RR5-171   Activate Subscription Version — Send SV Type Data to Local SMSs    NPAC SMS shall, for a Service Provider that supports SV Type, send the SV Type attribute for an activated Inter or Intra-Service Provider Subscription Version port via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 13)          RR5-172   Activate Subscription Version — Send Alternative SPID to Local SMSs    NPAC SMS shall, for a Service Provider that supports Alternative SPID, send the Alternative SPID attribute for an activated Inter or Intra-Service Provider Subscription Version port via the NPAC SMS to Local SMS Interface to the Local SMSs. (previously NANC 399, Req 14)          5.1.2.2.5   Subscription Version Disconnect    This section provides the requirements for the Subscription Version Disconnect functionality, which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to have a Subscription Version disconnected.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-41    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-62   Disconnect Subscription Version — Version Identification    NPAC SMS shall receive the following data from the NPAC personnel or current Service Provider to identify an active Subscription Version to be disconnected:  Ported Telephone Numbers (or a specified range of numbers) or Subscription Version ID          RR5-23.1   Disconnect Subscription Version — Required Input Data    NPAC SMS shall require the following input data upon a Subscription Version disconnect:     •   Customer Disconnect Date — Date upon which the customer’s service is disconnected.            RR5-23.2   Disconnect Subscription Version — Optional Input Data    NPAC SMS shall accept the following optional input data upon a Subscription Version disconnect:     •   Effective Release Date — Future date upon which the disconnect should be broadcast to all Local SMSs.            RN5-10   Disconnect Subscription Version — Invocation by Current Service Provider    NPAC SMS shall allow only NPAC personnel or the Current Service Provider to invoke the functionality to disconnect a Subscription Version.          R5-63   Disconnect Subscription Version — Invalid Status Notification    NPAC SMS shall send an appropriate error message to the originating user that the Subscription Version is not active in the network and cannot be disconnected or set to disconnect pending if there is no Subscription Version with a status of active.          R5-64.1   Disconnect Subscription Version — Cancel Other Version Notification    NPAC SMS shall notify the originating user that the active Subscription Version cannot be disconnected if a version of that subscription version with a status other than canceled or old exists.          RR5-48   Disconnect Pending Subscription Version- Creation of Old Subscription Version    DELETED          RR5-49   Disconnect Pending Subscription Version- Old Subscription Version No Broadcast    DELETED          RR5-24   Disconnect Subscription Version -Set to Disconnect Pending    NPAC SMS shall set the status of a Subscription Version to disconnect pending upon a Subscription Version disconnect request when an effective release date is specified.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-42    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-25.1   Disconnect Subscription Version — Disconnect Pending Status Notification    NPAC SMS shall inform the current Service Provider when the status of a Subscription Version is set to Disconnect Pending.          RR5-25.2   Disconnect Subscription Version — Customer Disconnect Date Notification    NPAC SMS shall notify the new Service Provider (donor) of the Subscription Version Customer Disconnect Date and Effective Release Date immediately prior to broadcasting a Subscription Version disconnect.          R5-65.1   Disconnect Subscription Version -Immediate Broadcast    NPAC SMS shall immediately proceed with the broadcasting of the disconnect after the Customer Disconnect Date notification is sent if no Effective Release Date was specified with the request.          R5-65.2   Disconnect Subscription Version — Deferred Broadcast    NPAC SMS shall proceed with the broadcasting of the disconnect when the specified Effective Release Date is reached if an Effective Release Date was specified with the request.          R5-65.4   Disconnect Subscription Version — Broadcast Interface Message to Local SMSs    NPAC SMS shall broadcast the disconnect Subscription Version message to the Local SMSs that are accepting Subscription Version data downloads for the given NPA-NXX via the NPAC SMS to Local SMS Interface.          R5-65.5   Disconnect Subscription Version — Disconnect Broadcast Date and Time Stamp    NPAC SMS shall record the current date and time as the disconnect broadcast date and time stamp upon sending of disconnect messages to the Local SMSs.          R5-65.6   Disconnect Subscription Version — Set to Sending    NPAC SMS shall set a Subscription Version status to sending upon sending the disconnect messages to the Local SMSs.          R5-66.2   Disconnect Subscription Version Complete — Set Disconnect Complete Date    NPAC SMS shall update the Disconnect Complete timestamp of the previously active Subscription Version upon completion of the broadcast, and the FIRST successful response from a Local SMS.          R5-66.3   Disconnect Subscription Version Complete — Set Disconnect to Old    NPAC SMS shall set the disconnect Subscription Version to old if a successful response from at least one Local SMS is returned.          R5-66.4   Disconnect Subscription Version Complete – Status Update of SV    NPAC SMS shall update the status of the disconnect Subscription Version upon completion of the Deletion broadcast, and a response from ALL Local SMSs, or retries are exhausted.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-43    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-67.1   Disconnect Subscription Version — Set Status to Active    NPAC SMS shall set the status of the disconnect Subscription Version to active if the disconnect fails in all the Local SMSs to which it was sent.          R5-67.2   Disconnect Pending Subscription Version — Failure Notification    NPAC SMS shall notify the NPAC SMS System Administrator when a disconnect Subscription Version fails in all of the Local SMSs.          R5-67.3   Disconnect Subscription Version — Resend Disconnect Requests to All Local SMSs    NPAC SMS shall provide authorized NPAC SMS personnel with the functionality to resend all failed disconnect requests to the Local SMSs.          R5-68.1   Disconnect Subscription Version — Subscription Disconnect Retry Attempts — Tunable Parameter    NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Disconnect Retry Attempts tunable parameter, which is defined as the number of times the NPAC SMS will resend a disconnect message to an unresponsive Local SMS.          R5-68.2   Disconnect Pending Subscription Version — Subscription Disconnect Retry Attempts — Tunable Parameter Default    NPAC SMS shall default the Subscription Disconnect Retry Attempts tunable parameter to 3 times.          R5-68.3   Disconnect Subscription Version — Subscription Disconnect Retry Interval - Tunable Parameter    NPAC SMS shall allow the NPAC SMS Administrator to modify the Subscription Disconnect Retry Interval tunable parameter, which is defined as the amount of time that shall elapse between disconnect retries.          R5-68.4   Disconnect Subscription Version — Subscription Disconnect Retry Interval — Tunable Parameter Default    NPAC SMS shall default the Subscription Disconnect Retry Interval tunable parameter to 2 minutes.          R5-68.5   Disconnect Subscription Version — Retry Processing    NPAC SMS shall resend a Subscription Version disconnect message a Subscription Disconnect Retry Attempts tunable parameter number of times to a Local SMS that has not acknowledged the receipt of a disconnect once the Subscription Disconnect Retry Interval tunable parameter expires.          R5-68.6   Disconnect Subscription Version — Sending Status during Retries    NPAC SMS shall retain the status for the Subscription Version being disconnected as sending until the Subscription Disconnect Retry Attempts tunable parameter period expires for all Local SMSs, or until all Local SMSs have acknowledged the disconnect.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-44    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-68.7   Disconnect Subscription Version — Retry Failed    NPAC SMS shall consider the disconnect Subscription Version request to have failed at a specific Local SMS after the Subscription Disconnect Retry Attempts tunable parameter count for the specific Local SMS has been exhausted.          R5-68.8   Disconnect Subscription Version — Failure Notification after Retries Complete    NPAC SMS shall send a list of the Local SMSs where the disconnect request failed to the NPAC SMS System Administrator after every local SMS has either succeeded or failed with the disconnect.          R5-68.9   Disconnect Subscription Version — Set to Old    NPAC SMS shall set the disconnect Subscription Version status to old if the disconnect request failed at one or more, but not all, of the Local SMSs.          R5-68.10   Disconnect Subscription Version — Resend Disconnect Requests to Failed Local SMSs    NPAC SMS shall provide authorized NPAC SMS personnel with the functionality to resend disconnect requests to all Local SMSs that failed to register the disconnect request.          RR5-63   Disconnect Subscription Version or Port-To-Original – Pooled Number Block Default Routing Restoration    The NPAC SMS shall reinstate the Block default routing, block holder Service Provider Id and the LNP Type to POOL for a subscription version upon a disconnect for a ported TN, or an activate for a Port-To-Original TN, belonging to the 1K Block, once the Block exists in the NPAC SMS, except for a status of Old, with or without a Block Failed SP List. (Previously SV-390)          RR5-64   Disconnect Subscription Version — Customer Disconnect Date Notification for Pooled Number    NPAC SMS shall notify the Block Holder of the Subscription Version Customer Disconnect Date and Effective Release Date, for a ported pooled Subscription Version that is being disconnected, prior to reinstating the default routing. (Previously SV-400)          RR5-65   Disconnect Subscription Version – Broadcast of Subscription Data Creation    The NPAC SMS shall broadcast a new Subscription Version Create to a non-EDR Local SMS, upon a disconnect of a ported pooled Subscription Version, where the TN is within the 1K Block. (Previously SV-410)          RR5-66   Disconnect Subscription Version – Broadcast of Subscription Data Deletion    The NPAC SMS shall broadcast a Subscription Version Delete to an EDR Local SMS, upon a disconnect of a ported pooled Subscription Version, where the TN is within the 1K Block. (Previously SV-420)          RR5-67.1   Disconnect Subscription Version – Updates to the Status for Disconnect    NPAC SMS shall update the Status of the individual subscription version(s) broadcast to the EDR Local SMSs, and the individual subscription version(s) broadcast to the non-EDR Local SMSs, upon completion of the disconnect broadcast to ALL EDR and non-EDR Local SMSs. (Previously SV-422.1)                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-45    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-67.2   Disconnect Subscription Version – Setting of the Status for Disconnected SV    NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being disconnected to: (Previously SV-422.2)     •   Active, if ALL EDR and non-EDR Local SMSs, fail the broadcast.       •   Old, for all other cases.            RR5-67.3   Disconnect Subscription Version – Setting of the Status for Newly Created SV    NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being created to reinstate default routing to: (Previously SV-422.3)     •   Active, if all EDR and non-EDR Local SMSs, respond successfully to the broadcast.       •   Failed, if all EDR and non-EDR Local SMSs, fail the broadcast, or retries are exhausted.       •   Partial Failure, for all other cases.            RR5-68.1   Disconnect Subscription Version – Updates to the Status for Port-to-Original    NPAC SMS shall update the Status of the individual subscription version(s) broadcast to the EDR Local SMSs, the individual subscription version(s) broadcast to the non-EDR Local SMSs, and the individual subscription version(s) representing the port-to-original request, upon completion of the Port-To-Original broadcast to ALL EDR and non-EDR Local SMSs. (Previously SV-423.1)          RR5-68.2   Disconnect Subscription Version – Setting of the Status for Port-to-Original SV    NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being ported-to-original to: (Previously SV-423.2)     •   Old, if ALL EDR and non-EDR Local SMSs, respond successfully to the broadcast.       •   Failed, if ALL EDR and non-EDR Local SMSs, fail the broadcast, or retries are exhausted.       •   Partial Failure, for all other cases.            RR5-68.3   Disconnect Subscription Version – Setting of the Status for Port-to-Original SV that was active prior to the PTO activation request    NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the previously active Subscription Version being disconnected due to the port-to-original request to: (Previously SV-423.3)     •   Active, if ALL EDR and non-EDR Local SMSs, fail the broadcast.       •   Old, for all other cases.            RR5-68.4   Disconnect Subscription Version – Setting of the Status for Port-to-Original for Newly Created SV    NPAC SMS shall, upon broadcasting the delete of the Subscription Version to EDR Local SMSs, and create of Subscription Version to non-EDR Local SMSs, set the status of the Subscription Version being created to reinstate default routing for the port-to-original request to: (Previously SV-423.4)                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-46    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management       •   Active, if all EDR and non-EDR Local SMSs, respond successfully to the broadcast.       •   Failed, if all EDR and non-EDR Local SMSs, fail the broadcast, or retries are exhausted.       •   Partial Failure, for all other cases.            RR5-69   Disconnect Subscription Version – Updates to the Failed SP List for Disconnect    NPAC SMS shall update the Subscription Version Failed SP List of the individual subscription version(s) that were broadcast to the EDR Local SMSs with the discrepant Local SMS(s) , upon completion of the broadcast of the delete of the Subscription Version(s) to EDR Local SMSs, and the create of the Subscription Version(s) to non-EDR Local SMSs. (Previously SV-425)  Note: The NPAC SMS will roll up the Subscription Version Failed SP List so that the SV that was active prior to the disconnect request (SV1) contains the Failed SP List for both SV1 and SV2, as defined in the IIS Flows for Disconnect of a Ported Pooled Number.          RR5-70   Disconnect Subscription Version – Updates to the Failed SP List for Port-To-Original    NPAC SMS shall update the Subscription Version Failed SP List of the individual subscription version(s) that were sent up in the Port-to-Original Activate request by the SOA with the discrepant Local SMS(s), upon completion of the broadcast of the delete of the Subscription Version(s) to EDR Local SMSs, and the create of the Subscription Version(s) to non-EDR Local SMSs. (Previously SV-426)  Note: The NPAC SMS will roll up the Subscription Version Failed SP List so that the SV that was active prior to the port-to-original activate request (SV2) contains the Failed SP List for both SV1 and SV3, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number.          5.1.2.2.6   Subscription Version Cancellation    This section provides the requirements for the Subscription Version Cancellation functionality (including “un-do” of a ‘cancel-pending’ Subscription Version), which is executed upon the NPAC personnel or SOA to NPAC SMS interface user requesting to cancel a Subscription Version.          RR5-26.1   Cancel Subscription Version — Inform Both Service Providers of Cancel Pending Status    NPAC SMS shall inform both old and new Service Providers when the status of a Subscription Version is set to cancel pending for an Inter-Service Provider port.          R5-69   Cancel Subscription Version — Version Identification    NPAC SMS shall receive the following data from the NPAC personnel to identify a Subscription Version to be canceled:  Ported Telephone Number (or a specified range of numbers) or Subscription Version ID                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-47    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-70   Cancel Subscription Version — Invalid Status Notification    NPAC SMS shall send an appropriate error message to the originating user if the status is not pending, conflict, or disconnect pending.          RR5-27   Cancel Subscription Version — Validate Service Provider    NPAC SMS shall send an appropriate error message to the originating user if the originating user is neither the New nor the Old Service Provider in the existing Subscription Version upon Subscription Version cancellation.          R5-71.2   Cancel Subscription Version — Set Cancellation Date and Time Stamp    NPAC SMS shall set the Subscription Version cancellation date and time to current upon setting the Subscription Version status to canceled.          R5-71.3   Cancel Subscription Version- Set to Cancel Old Service Provider only    NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the old Service Provider if the New Service Provider has not sent a subscription version create.          R5-71.4   Cancel Subscription Version- Set to Cancel New Service Provider only    NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the New Service Provider if the Old Service Provider has not sent an subscription version create.          R5-71.5   Cancel Subscription version- Error on Cancellation    NPAC SMS shall return an error if a Service Provider sends a cancellation for a subscription version that has not been created by that Service Provider.          R5-71.6   Cancel Subscription Version- Set Pending subscription version to Cancel Pending Status Inter-Service Provider port    NPAC SMS shall set the subscription version status to Cancel Pending upon receiving a cancellation from either the Old or New Service Provider for a subscription version with a pending status (both Service Providers have done a create) for an Inter-Service Provider or Port to original port.          R5-71.8   Cancel Subscription Version- Set Conflict Subscription to Cancel New Service Provider only    NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the new Service Provider on a subscription in conflict that was previously in cancel pending and for which only the old service provider has sent a cancellation acknowledgment.          R5-71.9   Cancel Subscription Version — Rejection of Old Service Provider Conflict Cancellation    NPAC SMS shall return an error to the Old Service Provider if they attempt to cancel a Subscription Version that is in conflict due to lack of New Service Provider cancellation concurrence on a subscription version that was previously in cancel pending state.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-48    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-71.10   Cancel Subscription Version- Set Disconnect Pending subscription version to Active    NPAC SMS shall set the subscription version status to Active upon receiving a cancellation for a subscription version with a status of disconnect pending.          R5-71.11   Cancel Subscription Version- Set to Cancel Status — Intra-Service Provider port    NPAC SMS shall set the subscription version status to cancel upon receiving a cancellation from the current Service Provider for an Intra-Service Provider port.          RR5-28.1   Cancel Subscription Version — Set to Cancel After Service Provider Acknowledge    NPAC SMS shall set the Subscription Version status to cancel upon receiving cancellation pending acknowledgment from the Service Provider that did not initiate the cancellation for an Inter-Service Provider port.          RR5-29.1   Cancel Subscription Version — Inform Both Service Providers of Cancel Status    NPAC SMS shall notify both old and new Service Providers after a Subscription Version’s status is set to canceled for an Inter-Service Provider port.          RR5-29.2   Cancel Subscription Version — Inform Current Service Provider of Cancel Status    NPAC SMS shall notify the current Service Provider after a Subscription Version’s status is set to canceled for an Intra-Service Provider port.          RR5-30   Cancel Subscription Version Acknowledgment — Update Old Service Provider Date and Time Stamp    NPAC SMS shall update the old Service Provider cancellation date and time stamp with the current date and time when the cancellation acknowledgment is received from the old Service Provider.          RR5-31   Cancel Subscription Version Acknowledgment — Update New Service Provider Date and Time Stamp    NPAC SMS shall update the new Service Provider cancellation date and time stamp with the current date and time when the cancellation acknowledgment is received from the new Service Provider.          RR5-32.1   Cancellation-Initial Concurrence Window — Tunable Parameter    NPAC SMS shall provide long and short Cancellation-Initial Concurrence Window tunable parameters, which are defined as the number of business hours after the version is set to Cancel Pending by which the non-originating Service Provider is expected to acknowledge the pending cancellation.          RR5-32.2   Cancellation-Initial Concurrence Window — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Cancellation-Initial Concurrence Window tunable parameters.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-49    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-32.3   Long Cancellation-Initial Concurrence Window — Tunable Parameter Default    NPAC SMS shall default the long Cancellation-Initial Concurrence Window tunable parameter to 9 business hours.          RR5-32.4   Short Cancellation-Initial Concurrence Window — Tunable Parameter Default    NPAC SMS shall default the short Cancellation-Initial Concurrence Window tunable parameter to 9 business hours.          RR5-33.1   Cancellation-Final Concurrence Window — Tunable Parameter    NPAC SMS shall provide long and short Cancellation-Final Concurrence Window tunable parameters which are defined as the number of business hours after the second cancel pending notification is sent by which both Service Providers are expected to acknowledge the pending cancellation.          RR5-33.2   Cancellation-Final Concurrence Window Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the long and short Cancellation-Final Concurrence Window tunable parameters.          RR5-33.3   Long Cancellation-Final Concurrence Window — Tunable Parameter Default    NPAC SMS shall default the long Cancellation-Final Concurrence Window tunable parameter to 9 business hours.          RR5-33.4   Short Cancellation-Final Concurrence Window — Tunable Parameter Default    NPAC SMS shall default the short Cancellation-Final Concurrence Window tunable parameter to 9 business hours.          RR5-34   Cancellation-Initial Concurrence Window — Tunable Parameter Expiration    NPAC SMS shall send a notification to the Service Provider (new or old) who has not yet acknowledged the cancel pending status when the Cancellation-Initial Concurrence Window tunable parameter expires.          RR5-35.1   Cancellation-Final Concurrence Window — Tunable Parameter Expiration New Service Provider    NPAC SMS shall set the Subscription Version status to conflict when the NPAC SMS has not received the cancellation acknowledgment from the new Service Provider and the Cancellation-Final Concurrence Window tunable parameter has expired.          RR5-35.2   Cancellation-Final Concurrence Window — Tunable Parameter Expiration Old Service Provider    NPAC SMS shall set the Subscription Version status to cancel and set the cause code to “NPAC SMS automatic cancellation” when the NPAC SMS has not received the cancellation acknowledgment from the Old Service Provider and the Cancellation-Final Concurrence Window tunable parameter has expired.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-50    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-36.1   Cancel Subscription Version – Cause Code for New SP Timer Expiration    NPAC SMS shall set the cause code to “NPAC SMS Automatic Conflict from Cancellation” after setting the Subscription Version status to conflict from cancel-pending when the new Service Provider has not acknowledged the cancellation and after the Cancellation-Final Concurrence Window has expired. (previously NANC 138, Req 1)          RR5-36.2   Cancel Subscription Version — Inform Service Providers of Conflict Status    NPAC SMS shall notify the old and new Service Providers upon setting a cancel-pending Subscription Version to conflict after the expiration of the Initial and Final Cancellation Concurrence Window tunables.  Note: If the cause code value is set to “NPAC SMS Automatic Conflict from Cancellation”, and the Service Provider does NOT support this cause code, the existing message will be unchanged.          RR5-140   Cancel-Pending-to-Conflict Cause Code Indicator    NPAC SMS shall provide a Cancel-Pending-to-Conflict Cause Code Indicator tunable parameter which defines whether a SOA supports a Conflict message that uses the Cancel-Pending-to-Conflict Cause Code. (previously NANC 138, Req 1.5)          RR5-141   Cancel-Pending-to-Conflict Cause Code Indicator Default    NPAC SMS shall default the Service Provider SOA Cancel-Pending-to-Conflict Cause Code Indicator tunable parameter to FALSE. (previously NANC 138, Req 2)          RR5-142   Cancel-Pending-to-Conflict Cause Code Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Cancel-Pending-to-Conflict Cause Code Indicator tunable parameter. (previously NANC 138, Req 3)          RR5-165   Regional Automatic Conflict Cause Code Tunable    NPAC SMS shall provide a Regional Automatic Conflict tunable parameter, which is defined as an indicator on whether or not the automatic conflict cause code functionality is supported by the NPAC SMS for a particular NPAC Region. (previously NANC 138, Req 4)          RR5-166   Regional Automatic Conflict Cause Code Tunable Default    NPAC SMS shall default the Regional Automatic Conflict Cause Code tunable parameter to TRUE. (previously NANC 138, Req 5)          RR5-167   Regional Automatic Conflict Cause Code Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Regional Automatic Conflict Cause Code tunable parameter. (previously NANC 138, Req 6)                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-51    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            5.1.2.2.6.1   Un-do a “Cancel-Pending” Subscription            RR5-143   Un-Do a Cancel-Pending Subscription Version – Notification    NPAC SMS shall inform both Old and New Service Providers when the status of a Subscription Version is set from cancel-pending back to pending for an Inter-Service Provider port. (previously NANC 388, Req 1)          RR5-144   Un-Do a Cancel-Pending Subscription Version – Request Data    NPAC SMS shall receive the following data from the Old or New Service Provider to identify a Subscription Version to have a cancel request retracted:     o   Ported TN (or a specified range of numbers)       o   Subscription Version ID       o   Version Status (if TN or TN range is specified, should be cancel-pending)       o   New Version Status (can be only pending)    (previously NANC 388, Req 2)          RR5-164   Un-Do a Cancel-Pending Subscription Version – New Status Specified Error    NPAC SMS shall send an appropriate error message to the originating user that requests a cancellation retraction for a subscription version, if the new version status specified in the request is not pending. (previously NANC 388, Req 2.5)          RR5-145   Un-Do a Cancel-Pending Subscription Version – Version Status Error    NPAC SMS shall send an appropriate error message to the originating user that requests a cancellation retraction for a subscription version, if the current version status is not cancel-pending. (previously NANC 388, Req 3)          RR5-146   Un-Do a Cancel-Pending Subscription Version – SP Error    DELETED           RR5-147   Un-Do a Cancel-Pending Subscription Version – Timestamp    NPAC SMS shall set the Subscription Version modification date and time to current upon setting the Subscription Version status back to pending. (previously NANC 388, Req 5)          RR5-148   Un-Do a Cancel-Pending Subscription Version – Missing Create Error    DELETED                  Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-52    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-149   Un-Do a Cancel-Pending Subscription Version – Missing Cancel Error    NPAC SMS shall return an error if a Service Provider sends a cancellation retraction for a subscription version that has not been cancelled by that Service Provider. (previously NANC 388, Req 7)          RR5-150   Un-Do a Cancel-Pending Subscription Version – Status Change    NPAC SMS shall set the subscription version status to Pending upon receiving a cancellation retraction from either the Old or New Service Provider for a subscription version with a cancel-pending status (both Service Providers have done a create) for an Inter-Service Provider or Port to original port. (previously NANC 388, Req 8)          5.1.2.2.7   Subscription Version Resend    This section provides the requirements for the Subscription Version resend functionality, which is executed upon the NPAC personnel requesting to resend a Subscription Version.          RR5-38.1.1   Resend Subscription Version — Identify Subscription Version    NPAC SMS shall receive the following data from NPAC personnel to identify a subscription version that contains a Failed SP List with one or more SPIDS, to be resent:  Ported Telephone Number or Subscription Version ID          RR5-38.1.2   Resend Subscription Version – Identify Multiple Subscription Versions    NPAC SMS shall require NPAC personnel to specify a TN Range (NPA-NXX-xxxx through yyyy, where yyyy is greater than xxxx) to identify multiple subscription versions that contain a Failed SP List with one or more SPIDS, to be resent.          RR5-38.2   Resend Subscription Version — Input Data    NPAC SMS shall require the following input data from NPAC personnel upon a Subscription Version resend:     •   List of “failed” Local SMSs to resend to.            RR5-38.3   Resend Subscription Version — Error Message    NPAC SMS shall send an error message to the originating user upon Subscription Version resend if the version does not have a list of failed LSMSs associated with the subscription’s last operation.          RR5-38.4   Resend Subscription Version — Activation Request    NPAC SMS shall resend a Subscription Version activation request, if the Subscription Version previously failed activation, to the designated list of failed Local SMSs via the NPAC SMS to Local SMS Interface upon a Subscription Version resend request.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-53    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-38.5   Resend Subscription Version — Disconnect Request    NPAC SMS shall resend a Subscription Version disconnect request, if the Subscription Version previously failed disconnect, to the designated list of failed Local SMSs via the NPAC SMS to Local SMS Interface upon a Subscription Version resend request.          RR5-38.6   Resend Subscription Version — Failed or Partial Failure    NPAC SMS shall set a failed or partial failure Subscription Version to sending subsequent to resending to the Local SMSs via the NPAC SMS to Local SMS Interface.          RR5-38.7   Resend Subscription Version — Standard Activation Processing    NPAC SMS shall proceed with the standard activation processing subsequent to resending a Subscription Version activation request to the Local SMSs via the NPAC SMS to Local SMS Interface.          RR5-38.8   Resend Subscription Version — Standard Disconnect Processing    NPAC SMS shall proceed with the standard disconnect processing subsequent to resending a Subscription Version disconnect request to the Local SMSs via the NPAC SMS to Local SMS Interface.          RR5-38.9   Resend Subscription Version – Modify Active Request    NPAC SMS shall resend a Subscription Version modify active request, if an active Subscription Version previously failed modification, to the designated list of failed Local SMSs via the NPAC SMS to Local SMS Interface upon a Subscription Version resend request.          RR5-38.10   Resend Subscription Version — Standard Modify Active Processing    NPAC SMS shall proceed with the standard modify active processing subsequent to resending a Subscription Version modify request to the Local SMSs via the NPAC SMS to Local SMS Interface.          RR5-71   Re-Send of Number Pooling Subscription Version Information – NPAC Personnel OpGUI    NPAC SMS shall prevent NPAC Personnel from re-sending a Subscription Version with LNP Type of POOL, via the NPAC Administrative Interface. (Previously SV-451)  Note: The re-send of SVs with LNP Type of POOL to non-EDR Local SMSs shall be initiated from the Block Re-send on the NPAC Administrative GUI.          RR5-72   Re-Send of Number Pooling Subscription Version Information – Subscription Versions sent to discrepant non-EDR Local SMS    NPAC SMS shall re-send Subscription Versions to a discrepant non-EDR Local SMS via the NPAC SMS to Local SMS Interface, when a re-send request is initiated to a Block. (Previously SV-452)                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-54    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-73   Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Failed Subscription Versions for Block Activation    NPAC SMS shall update the status of the failed Subscription Versions with LNP Type of POOL in the 1K Block, at the start of the re-send to the Local SMSs, from a failed status to a sending status. (Previously SV-460)          RR5-74   Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Partial failure Subscription Versions for Block Activation    NPAC SMS shall update the status of the partial failure Subscription Versions with LNP Type of POOL in the 1K Block, at the start of the re-send to the Local SMSs, from a partial failure status to a sending status. (Previously SV-470)          RR5-75   Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Active Subscription Version for Block Modification or Deletion    NPAC SMS shall update the status of the active Subscription Version with LNP Type of POOL in the 1K Block, with a Failed SP List, at the start of the re-send to the Local SMSs, from an active status to a sending status. (Previously SV-480)          RR5-76   Re-Send of Number Pooling Subscription Version Information – Sending Status Update to Old Subscription Version for Block Deletion    NPAC SMS shall update the status of the old Subscription Version with LNP Type of POOL in the 1K Block, with a Failed SP List, at the start of the re-send to the Local SMSs, from an old status to a sending status. (Previously SV-490)          RR5-77   Re-Send of Number Pooling Subscription Version Information – Update to Failed SP List    NPAC SMS shall update the Subscription Version Failed SP List of the Subscription Version(s) with LNP Type of POOL in the 1K Block, by removing the previously failed Local SMS, upon a successful re-send to a previously failed Local SMS. (Previously SV-510)          RR5-78   Re-Send of Number Pooling Subscription Version Information –Status Update to Subscription Version after Re-Send    NPAC SMS shall update the status of the Subscription Version(s) and the Block, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS or if retries have been exhausted, from a sending status, as defined in RR3-137.1, RR3-137.2 RR3-137.3, and RR3-137.4. (Previously SV-515)          RR5-79   Re-Send of Number Pooling Subscription Version Information –Failed SP List Update to Subscription Version after Re-Send    NPAC SMS shall update the Subscription Version Failed SP List of the Subscription Version(s) with LNP Type of POOL in the 1K Block, specified in the re-send request for a Block Creation, Modification, or Deletion, at the completion of the re-send to the Local SMS, and a response from the Local SMS, or if retries have been exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-516)                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-55    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-80   Re-Send of Subscription Version Information – Disconnect or Port-To-Original of a TN within a Pooled 1K Block    NPAC SMS shall examine a Service Provider’s EDR Indicator, at the time of re-send, to determine the message to re-send, for a disconnect or a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block. (Previously SV-518)          RR5-81.1   Re-Send of Subscription Version Information – Disconnect TN within a Pooled 1K Block to EDR Local SMS    NPAC SMS shall, for a re-send of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Delete request of the Subscription Version that was active prior to the disconnect broadcast to a discrepant EDR Local SMS. (Previously SV-519.1)  Note: The NPAC SMS will re-send an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the disconnect request (SV2), as defined in the IIS Flows for Disconnect of a Ported Pooled Number.          RR5-81.2   Re-Send of Subscription Version Information – Disconnect TN within a Pooled 1K Block to non-EDR Local SMS    NPAC SMS shall, for a re-send of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Create request of the Subscription Version that was created to restore default routing to a discrepant non-EDR Local SMS. (Previously SV-519.2)  Note: The NPAC SMS will re-send an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV2) that was created to restore default routing (SV1), although the Failed SP List resides on SV1, as defined in the IIS Flows for Disconnect of a Ported Pooled Number.          RR5-82.1   Re-Send of Subscription Version Information –Port-To-Original TN within a Pooled 1K Block to EDR Local SMS    NPAC SMS shall, for a re-send of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast to a discrepant EDR Local SMS. (Previously SV-520.1)  Note: The NPAC SMS will re-send an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number.          RR5-82.2   Re-Send of Subscription Version Information –Port-To-Original TN within a Pooled 1K Block to non-EDR Local SMS    NPAC SMS shall, for a re-send of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, re-broadcast the Create request of the Subscription Version that was created to restore default routing, and shall NOT re-broadcast the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast to a discrepant non-EDR Local SMS. (Previously SV-520.2)  Note: The NPAC SMS will re-send an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV3) that was created to restore default routing, and will NOT re-send an M-DELETE of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number.                 Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-56    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                        Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-151   Subscription Version Failed SP List – Exclusion of a Service Provider from Resend    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to request that a Service Provider be excluded from the Subscription Version Failed SP List when resending an Inter-Service Provider port or Intra-Service Provider port Version, and not broadcast to the Service Provider that is excluded. (previously NANC 227/254 Req 1)          RR5-152   Subscription Version Failed SP List – Logging of an Excluded Service Provider    NPAC SMS shall log the following information when a Service Provider is excluded from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface: date, time, excluded SPID, current SPID, TN, SV-ID. (previously NANC 227/254 Req 2)          5.1.3   Subscription Queries    This section provides the requirements for the Subscription Version Query functionality, which is executed upon the user requesting a query of a Subscription Version (R5-13).          5.1.3.1   User Functionality            R5-72   Query Subscription Version — Request    NPAC SMS shall allow NPAC personnel, SOA to NPAC SMS interface users, and NPAC SMS to Local SMS interface users to query data maintained by the NPAC SMS for a Subscription and all its Versions.          5.1.3.2   System Functionality    The following requirements specify the NPAC SMS query functionality defined above.          R5-73   Query Subscription Version — Version Identification                  NPAC SMS shall receive the following data to identify a Subscription Version to be queried:        Ported Telephone Numbers and status (optional)        or        Subscription Version ID             R5-74.1   Query Subscription Version — Status Supplied    NPAC SMS shall only retrieve Subscription Versions with a specific status when the user supplies a specific Subscription Version status as part of the query criteria.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-57    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            R5-74.2   Query Subscription Version — Return All Subscription Versions for Ported TN    NPAC SMS shall return all Subscription Versions associated with a ported TN that the requester is eligible to view if the originating user has not provided a Subscription Version status as part of the query criteria.          R5-74.3   Query Subscription Version — Output Data — SOA    NPAC SMS shall return the following output data for a Subscription Version query request initiated by NPAC personnel or a SOA to NPAC SMS interface user: (reference NANC 399)     •   Subscription Version ID      •   Subscription Version Status      •   Local Number Portability Type      •   Ported Telephone Number      •   Old facilities-based Service Provider Due Date      •   New facilities-based Service Provider Due Date      •   New facilities-based Service Provider ID      •   Old facilities-based Service Provider ID      •   Authorization from old facilities-based Service Provider      •   Status Change Cause Code      •   Location Routing Number (LRN)      •   Class DPC      •   Class SSN      •   LIDB DPC      •   LIDB SSN      •   CNAM DPC      •   CNAM SSN      •   ISVM DPC      •   ISVM SSN      •   WSMSC DPC (for SOAs that support WSMSC data)      •   WSMSC SSN (for SOAs that support WSMSC data)      •   Billing Service Provider ID      •   End-User Location Value      •   End User Location Type      •   Customer Disconnect Date      •   Effective Release Date      •   Disconnect Complete Time Stamp      •   Conflict Time Stamp      •   Broadcast Time Stamp      •   Activation Time Stamp      •   Cancellation Time Stamp (Status Modified to Canceled Time Stamp)      •   New Service Provider Creation Time Stamp      •   Old Service Provider Authorization Time Stamp      •   Pre-cancellation Status      •   Old Service Provider Cancellation Time Stamp      •   New Service Provider Cancellation Time Stamp      •   Old Time Stamp (Status Modified to Old Time Stamp)      •   New Service Provider Conflict Resolution Time Stamp      •   Old Service Provider Conflict Resolution Time Stamp      •   Create Time Stamp      •   Modified Time Stamp      •   Porting to Original                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-58    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management       •   Download Reason       •   Timer Type (for SOAs that support Timer Type)       •   Business Hours Type (for SOAs that support Business Hours)       •   List of all Local SMSs that failed activation, modification, or disconnect.       •   SV Type (if supported by the Service Provider SOA)       •   Alternative SPID (if supported by the Service Provider SOA)            R5-74.4   Query Subscription Version — Output Data — LSMS    NPAC SMS shall return the following output data for a Subscription Version query request initiated over the NPAC SMS to Local SMS interface: (reference NANC 399)     •   Subscription Version ID       •   Subscription Version Status       •   Local Number Portability Type       •   Ported Telephone Number       •   Old facilities-based Service Provider Due Date       •   New facilities-based Service Provider Due Date       •   New facilities-based Service Provider ID       •   Old facilities-based Service Provider ID       •   Authorization from old facilities-based Service Provider       •   Status Change Cause Code       •   Location Routing Number (LRN)       •   New facilities-based Service Provider ID       •   Activation Time Stamp       •   Customer Disconnect Date       •   Class DPC       •   Class SSN       •   LIDB DPC       •   LIDB SSN       •   CNAM DPC       •   CNAM SSN       •   ISVM DPC       •   ISVM SSN       •   WSMSC DPC (for Local SMSs that support WSMSC data)       •   WSMSC SSN (for Local SMSs that support WSMSC data)       •   Billing Service Provider ID       •   End-User Location Value       •   End-User Location Type       •   Customer Disconnect Date       •   Effective Release Date       •   Disconnect Complete Time Stamp       •   Conflict Time Stamp       •   Broadcast Time Stamp       •   Activation Time Stamp       •   Cancellation Time Stamp (Status Modified to Canceled Time Stamp)       •   New Service Provider Creation Time Stamp      •   Old Service Provider Authorization Time Stamp      •   Pre-cancellation Status      •   Old Service Provider Cancellation Time Stamp      •   New Service Provider Cancellation Time Stamp                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-59    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management          •   Old Time Stamp (Status Modified to Old Time Stamp)      •   New Service Provider Conflict Resolution Time Stamp      •   Old Service Provider Conflict Resolution Time Stamp      •   Create Time Stamp      •   Modified Time Stamp      •   Porting To Original      •   Billing Service Provider ID      •   Local Number Portability Type      •   Download Reason      •   Timer Type (for SOAs that support Timer Type)      •   Business Hours Type (for SOAs that support Business Hours)      •   List of all Local SMSs that failed activation, modification, or disconnect.      •   SV Type (if supported by the Service Provider LSMS)      •   Alternative SPID (if supported by the Service Provider LSMS)            RR5-153   Subscription Version Query – Sort Order    NPAC SMS shall return Subscription Versions as a result of a Subscription Version query, sorted in TN (primary, ascending) and SV-ID (secondary, ascending) order. (previously NANC 285, Req 3)          R5-75   Query Subscription Version -No Data Found    NPAC SMS shall send the originating user an appropriate message indicating that there was no data found if no Subscription Versions were found for a query.          RN5-4   Query Subscription Version — Retrieve Data, Modification Not Allowed    NPAC SMS shall allow NPAC personnel or SOA to NPAC SMS interface users to retrieve subscription data that they cannot modify.          RN5-5   Query Subscription Version — Retrieve Data Based on Single Ported TN Only    NPAC SMS shall allow authorized NPAC personnel, SOA to NPAC SMS interface users, or NPAC SMS to Local SMS interface users to submit query requests for Subscription Version data based on a single ported TN only.          RN5-6   Query Subscription Version — View for Any Ported TN    NPAC SMS shall allow old and new Service Providers or NPAC personnel to view a Subscription Version for any ported TN.          RR5-39   Query Subscription Version — View Old, Partial Failure, Disconnect Pending, Canceled or Active Only    NPAC SMS shall allow NPAC Customers who are neither the old nor the new Service Provider to view only those Subscription Versions for a ported TN with a status of active, partial-failure, disconnect-pending, canceled or old.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-60    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-174   NPAC SMS shall return all Subscription Versions    NPAC SMS shall return all Subscription Versions regardless of Subscription Version status for queries initiated via the NPAC SOA Low-tech Interface. (previously R4-30.2)          RR5-175   Service Provider subscription query    NPAC SMS shall return all active Subscription Versions associated with the Service Provider which satisfy the selection criteria, up to a tunable parameter number of Subscription Versions for queries initiated via the NPAC SMS to Local SMS interface. (previously R4-30.1)          RR5-40   Query Subscription Version — Online Records Only    NPAC SMS shall only allow Subscription Version queries of online subscription Versions that have not been archived.          RR5-83   Query Subscription Version – LNP Type of POOL    NPAC SMS shall return Subscription Versions with LNP Type of POOL that match the query selection criteria, on query requests by NPAC personnel, SOA via the SOA to NPAC SMS Interface, Local SMS via the NPAC SMS to Local SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, regardless of the value in the requesting Service Provider’s EDR Indicator. (Previously SV-440)          RR5-154   Subscription Version Query – Maximum Subscription Version Query by the SOA    NPAC SMS shall return the Maximum Subscription Query tunable value of Subscription Versions to a SOA, via the SOA to NPAC SMS Interface, when the user requests a Subscription Version query and the number of Subscription Version records that meet the query criteria exceed the Maximum Subscription Query tunable value and the service provider’s SOA SV Query Indicator is set to True. (previously NANC 285, Req 1)          RR5-155   Subscription Version Query – Maximum Subscription Version Query by the LSMS    NPAC SMS shall return the Maximum Subscription Query tunable value of Subscription Versions to a Local SMS, via the NPAC SMS to Local SMS Interface, when the user requests a Subscription Version query and the number of Subscription Version records that meet the query criteria exceed the Maximum Subscription Query tunable value and the service provider’s LSMS SV Query Indicator is set to True. (previously NANC 285, Req 2)          RR5-176   Count of subscription information during a query    NPAC SMS shall return a “complexity limitation” error and the count of subscription records returned by a query, if more than a tunable parameter number of Subscription Versions are found, and the service provider’s SOA SV Query Indicator or LSMS Query Indicator is set to False (respective to the SOA or LSMS interface over which they are originating the subscription version query request). (previously R4-30.6)          RR5-177   Service Provider subscription query options    NPAC SMS shall receive the attributes to be searched on for queries regarding Subscription Versions associated with the Service Provider. Allowable attributes are the following data elements from Table 3-6 Subscription Version Data Model: (previously R4-29)     •   Subscription Version ID                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-61    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management       •   Subscription Version Status      •   Local Number Portability Type      •   Ported Telephone Number      •   Old facilities-based Service Provider Due Date      •   New facilities-based Service Provider Due Date      •   New facilities-based Service Provider ID      •   Authorization from old facilities-based Service Provider      •   Local Routing Number (LRN)      •   Class DPC      •   Class SSN      •   LIDB DPC      •   LIDB SSN      •   CNAM DPC      •   CNAM SSN      •   ISVM DPC      •   ISVM SSN      •   WSMSC DPC      •   WSMSC SSN      •   Billing Service Provider ID      •   End User Location Value      •   End User Location Type      •   Customer Disconnect Date      •   Effective Release Date      •   Disconnect Complete Time Stamp      •   Conflict Time Stamp      •   Activation Time Stamp      •   Cancellation Time Stamp (Status Modified to Cancel Time Stamp)      •   New Service Provider Creation Time Stamp      •   Old Service Provider Authorization Time Stamp      •   Pre-cancellation Status      •   Old Service Provider Cancellation Time Stamp      •   New Service Provider Cancellation Time Stamp      •   Old Time Stamp (Status Modified to Old Time Stamp)      •   New Service Provider Conflict Resolution Time Stamp      •   Create Time Stamp      •   Modify Time Stamp      •   Porting To Original      •   Status Change Cause Code      •   Timer Type      •   Business Hour Type            RR5-178   Error Message for Service Provider subscription query    NPAC SMS shall provide the request originator with a message indicating that there was no data in NPAC SMS that matched the search keys, if NPAC SMS does not have Subscription Versions as specified by the request originator. (previously R4-30.8)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-62    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-156   Service Provider SOA SV Query Indicator    NPAC SMS shall provide a Service Provider SOA SV Query Indicator tunable parameter which defines whether a SOA supports enhanced SV Query functionality over the SOA-to-NPAC SMS Interface. (previously NANC 285, Req 7)  Note: For Service Providers that do NOT support enhanced SOA SV Query functionality, the NPAC will continue to send a complexityLimitation error message, when the number of SVs in a response exceed the Maximum Subscription Query tunable value.          RR5-157   Service Provider SOA SV Query Indicator Default    NPAC SMS shall default the Service Provider SOA SV Query Indicator tunable parameter to FALSE. (previously NANC 285, Req 8)          RR5-158   Service Provider SOA SV Query Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SV Query Indicator tunable parameter. (previously NANC 285, Req 9)          RR5-159   Service Provider LSMS SV Query Indicator    NPAC SMS shall provide a Service Provider LSMS SV Query Indicator tunable parameter which defines whether a LSMS supports enhanced SV Query functionality over the NPAC SMS-to-Local SMS Interface. (NANC 285, Req 10)  Note: For Service Providers that do NOT support enhanced LSMS SV Query functionality, the NPAC will continue to send a complexityLimitation error message, when the number of SVs in a response exceed the Maximum Subscription Query tunable value.          RR5-160   Service Provider LSMS SV Query Indicator Default    NPAC SMS shall default the Service Provider LSMS SV Query Indicator tunable parameter to FALSE. (NANC 285, Req 11)          RR5-161   Service Provider LSMS SV Query Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SV Query Indicator tunable parameter. (NANC 285, Req 12)          5.1.4   Subscription Version Processing for National Number Pooling    This section details the functional requirements for user interaction (either NPAC Personnel or Service Provider Personnel via their SOA and/or LSMS to NPAC SMS interface) with the NPAC SMS to appropriately operate in the National Number Pooling Environment.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-63    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            5.1.4.1   Subscription Version, General    The following requirements outline the basic NPAC SMS processing requirements for subscription versions in a National Number Pooling environment.          RR5-84   Number Pooling Subscription Version Information – Reject Messages    NPAC SMS shall reject a message from NPAC personnel, a Service Provider SOA via the SOA to NPAC SMS Interface, a Service Provider LSMS via the NPAC SMS to Local SMS Interface, or a Service Provider via the NPAC SOA Low-tech Interface, to Create, Modify, Cancel, Set to Conflict, Activate, or Disconnect, a Subscription Version with an LNP Type of POOL. (Previously SV-1)          RR5-85   Number Pooling Subscription Version Information – Suppression of Notifications    NPAC SMS shall suppress status change and attribute value change notifications to the old and new/current service provider SOA systems for Subscription Versions with LNP Type of POOL. (Previously SV-2)  Note: This includes creation, modification, deletion, re-send, resync, audits, and mass update.          RR5-85.5   Number Pooling Subscription Version Information – Disconnect Notifications to Donor Service Provider    NPAC SMS shall send donor disconnect notifications to the Donor Service Provider (Code Holder) when a Number Pool Block De-pool occurs.          RR5-86   Number Pooling Subscription Version Information – Filters for “Pooled Number” Subscription Versions    NPAC SMS shall apply NPA-NXX Filters to subscription version broadcasts to the Local SMSs, for Subscription Versions with LNP Type of POOL. (Previously SV-3)          RR5-87   Number Pooling Subscription Version Information – Broadcast of Subscription Data    NPAC SMS shall broadcast an addition, modification, or deletion of Subscription Versions, with LNP Type of POOL, to non-EDR LSMSs, via the NPAC SMS to Local SMS Interface, upon successful update of the 1K Block in the NPAC SMS, for Subscription Versions. (Previously SV-4)          RR5-88   Number Pooling Subscription Version Information – Failed SP List Update for Block    NPAC SMS shall consider an EDR Local SMS to be discrepant and shall update the Subscription Version Failed SP List for all Subscription Versions with LNP Type of POOL in the 1K Block, based on an EDR Local SMS failing to process the Block Object, for an addition, modification, deletion, re-send, or mass update. (Previously SV-5)          RR5-89   Number Pooling Subscription Version Information – Data Integrity for Pooled Subscription Versions and Block    NPAC SMS shall maintain data integrity for SPID, LRN and DPC/SSN data, between Subscription Versions with LNP Type of POOL in a 1K Block, and the corresponding Number Pooling Block, in the NPAC SMS. (Previously SV-6)                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    5-64    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            5.1.4.2   Subscription Version, Addition for Number Pooling    The following section outlines the NPAC SMS functional requirements for processing pooled subscription version additions. Subscription versions with LNP Type set to POOL are created when a Number Pool Block is activated.          RR5-90   Addition of Number Pooling Subscription Version Information – Subscription Data    NPAC SMS shall create individual subscription versions, with LNP Type of POOL, for each TN within the 1K Block, that does not already exist with a status of active/partial failure/disconnect pending/old with a Failed SP List/sending, immediately after successfully creating Number Pooling Block Holder Information in the NPAC SMS. (Previously SV-10)          RR5-91   Addition of Number Pooling Subscription Version Information – Create “Pooled Number” Subscription Version    NPAC SMS shall automatically populate the following data upon Subscription Version creation for a Pooled Number port: (Previously SV-20, reference NANC 399)  Version ID — Automatically generated by NPAC SMS. LRN  — Value set to same field in Block. Old Service Provider ID — Value set to owner of NPA-NXX. New Service Provider ID — Value set to NPA-NXX-X Holder SPID field in Block. TN  — Telephone Number associated with this Subscription Version. LNP Type — Value set to “POOL”. Status — Value initially set to “Sending”. CLASS DPC — Value set to same field in Block. CLASS SSN — Value set to same field in Block. LIDB DPC — Value set to same field in Block. LIDB SSN — Value set to same field in Block. CNAM DPC — Value set to same field in Block. CNAM SSN — Value set to same field in Block. ISVM DPC — Value set to same field in Block. ISVM SSN — Value set to same field in Block. WSMSC DPC — Value set to same field in Block. WSMSC SSN — Value set to same field in Block. New Service Provider Due Date — Value set to current date. Old Service Provider Due Date — Value set to current date. Old Service Provider Authorization — Value set to “TRUE”. New Service Provider Create Time Stamp — Value set to current date/time. Old Service Provider Authorization Time Stamp — Value set to current date/time. Activation Request Time Stamp — Value set to current date/time. Activation Broadcast Date — Value set to current date. Activation Broadcast Complete Time Stamp — Value set to current date/time, once the broadcast is complete (Local SMS has responded). Disconnect Request Time Stamp — Value set to all zeros. Disconnect Broadcast Time Stamp — Value set to all zeros. Disconnect Broadcast Time Stamp — Value set to all zeros. Disconnect Complete Time Stamp — Value set to all zeros. Effective Release Date — Value set to all zeros. Customer Disconnect Date — Value set to all zeros. Pre-Cancellation Status — Value set to NULL. Old Service Provider Cancellation Time Stamp — Value set to all zeros. New Service Provider Cancellation Time Stamp — Value set to all zeros. Cancellation Time Stamp — Value set to all zeros.                         Release 3.3:© 1997 — 2006 NeuStar, Inc.    5-65    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management    Old Time Stamp — Value set to all zeros. Conflict Time Stamp — Value set to all zeros. Conflict Resolution Time Stamp — Value set to all zeros. Create Time Stamp — Value set to current date/time. Modified Time Stamp — Value set to current date/time. Porting to Original — Value set to “FALSE”. End User Location Value — Value set to “no value”. End User Location Value Type — Value set to “no value”. Modify Request Time Stamp — Value set to all zeros. Modify Broadcast Time Stamp — Value set to all zeros. Modify Broadcast Complete Time Stamp — Value set to all zeros. Billing ID — Value set to “no value”. Status Change Cause Code — Value set to “no value”. SV Type (Value set to same field as Block) Alternative SPID (Value set to same field as Block)           RR5-92   Addition of Number Pooling Subscription Version Information Create “Pooled Number” Subscription Version – Bypass of Existing Subscription Versions    NPAC SMS shall upon finding an existing subscription version with an active, partial failure, disconnect pending, old with a failed SP list, or sending status for any TNs within the 1K Block, will bypass and not alter that TN/subscription version, log an information message, and continue processing. (Previously SV-30)          RR5-93   Addition of Number Pooling Subscription Version Information Create “Pooled Number” Subscription Version — Set to Sending    NPAC SMS shall set a Subscription Version of LNP Type POOL in the 1K Block, to sending upon successful subscription creation. (Previously SV-70)          RR5-94   Addition of Number Pooling Subscription Version Information – Status Update    NPAC SMS shall update the status of each Subscription Version with LNP Type of POOL for each TN in the 1K Block, upon completion of the broadcast, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted/timers have expired, as defined in RR3-137.1 and RR3-137.2. (Previously SV-90)          RR5-95   Addition of Number Pooling Subscription Version Information – Failed SP List    NPAC SMS shall update the Subscription Version Failed SP List with the discrepant Local SMS of the individual subscription version(s) with LNP Type of POOL, upon completion of the activation broadcast to All EDR and non-EDR Local SMSs, an unsuccessful response from at least one Local SMS, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted/timers have expired, as defined in RR3-138.1 and RR3-138.2. (Previously SV-121)          5.1.4.3   Subscription Version, Block Create Validation of Subscription Versions    The following requirements define validation processing on behalf of the NPAC SMS once a Number Pool Block has been activated.                        Release  3.3: © 1997 — 2006 NeuStar, Inc.    5-66    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-96   Block Create Validation of Subscription Versions – Subscription Version Completion Check    NPAC SMS shall, upon successful completion of a Block Create request, where the Block status is active, verify that 1000 individual TNs exist for the Block, with an LNP Type of either: (Previously SV-131)     •   POOL, where the status is active, or       •   LSPP/LISP, where the status is active/partial failure/disconnect pending.    Note: NPAC shall perform this Block Create Validation Process until all 1000 TNs have been accounted for in the 1K Block.  Note: NPAC shall NOT perform this Block Create Validation Process once all 1000 TNs have been accounted for in the 1K Block.          RR5-97   Block Create Validation of Subscription Versions – First Time Execution of Subscription Version Completion Check    NPAC SMS shall run the Block Create Validation Process within 24 hours of Block Creation where the Block status is active. (Previously SV-132)          RR5-98   Block Create Validation of Subscription Versions – Subscription Version Create for Missing TNs    NPAC SMS shall, upon finding any missing TNs with a status of Old without a Failed SP List, in the 1K Block, upon performing the Subscription Version Completion Check defined in RR5-96, log an information message, create a Subscription Version with LNP Type of POOL in the NPAC SMS using the routing data in the Block, and set the status to sending for the Subscription Version. (Previously SV-133)          RR5-99   Block Create Validation of Subscription Versions – Subscription Version Broadcast to non-EDR Local SMS    NPAC SMS shall, for any missing TNs in the 1K Block defined in RR5-98, broadcast the Subscription Version(s) with LNP Type of POOL, to all non-EDR Local SMSs, via the NPAC SMS to Local SMS Interface. (Previously SV-135)          RR5-100   Block Create Validation of Subscription Versions – Block Status Update    NPAC SMS shall update the status of the Block based on the results of the broadcast of the Subscription Versions to all non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1, RR3-137.2, RR3-137.3, and RR3-137.4. (Previously SV-137)          RR5-101   Block Create Validation of Subscription Versions – Block Failed SP List Update    NPAC SMS shall update the Block Failed SP List of the Block based on the results of the broadcast of the Subscription Versions to all non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-139)          RR5-102   Block Create Validation of Subscription Versions – Subscription Version Logging    NPAC SMS shall upon finding any missing TNs within the 1K Block during the Block Create Validation Process, log an information message, and continue processing. (Previously SV-140)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-67    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            5.1.4.4   Subscription Version, Modification for Number Pooling            RR5-103   Modification of Number Pooling Subscription Version Information – Subscription Data    NPAC SMS shall automatically apply the updates to the attributes of the individual subscription versions with LNP Type of POOL, with a status of active, for each TN within the 1K Block after successfully modifying a Number Pooling Block in the NPAC SMS. (Previously SV-230)          RR5-104   Modification of Number Pooling Subscription Version Information – Status Update to Sending    NPAC SMS shall update the status of the individual subscription versions with LNP Type of POOL, with a status of active, for each TN within the 1K Block, upon the start of the broadcast of a Block Modification to the Local SMSs, from an active status to a sending status, after successfully modifying a Number Pooling Block in the NPAC SMS. (Previously SV-240)          RR5-105   Modification of Number Pooling Subscription Version Information – Status Update    NPAC SMS shall update the status of each Subscription Version with LNP Type of POOL, with a status of active, for each TN in the 1K Block, upon completion of the broadcast, and a response from All EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.3. (Previously SV-270)          RR5-106   Modification of Number Pooling Subscription Version Information – Failed SP List    NPAC SMS shall update the Subscription Version Failed SP List with the discrepant Local SMS of the individual subscription version(s) with LNP Type of POOL, with a status of active, upon completion of the modification broadcast to All EDR and non-EDR Local SMSs, an unsuccessful response from at least one Local SMS, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-280)          5.1.4.5   Subscription Version, Deletion for Number Pooling            RR5-107   Deletion of Number Pooling Subscription Version Information – Sending Status Update to Subscription Versions    NPAC SMS shall, upon processing a valid request to delete an NPA-NXX-X, update the status of the Subscription Versions with LNP Type of POOL in the 1K Block, at the start of the broadcast to all EDR and non-EDR Local SMSs, from an active status to a sending status. (Previously SV-330)          RR5-108   Deletion of Number Pooling Subscription Version Information – Broadcast of Subscription Version Data    NPAC SMS shall, upon setting the Subscription Versions with LNP Type of POOL in the 1K Block status to sending, broadcast a delete of Subscription Versions with LNP Type of POOL in the 1K Block, to non-EDR LSMSs, via the NPAC SMS to Local SMS Interface. (Previously SV-335)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-68    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Subscription Management            RR5-109   Deletion of Number Pooling Subscription Version Information – Status Update to Subscription Versions    NPAC SMS shall update the status of a particular Subscription Version with LNP Type of POOL for each TN in the 1K Block, upon completion of the broadcast, a response for the Block to all EDR Local SMSs and that particular Subscription Version to non-EDR Local SMSs, or retries are exhausted, as defined in RR3-137.1 and RR3-137.4. (Previously SV-350)          RR5-110   Deletion of Number Pooling Subscription Version Information – Failed SP List    NPAC SMS shall update the Subscription Version Failed SP List with the discrepant Local SMS of the individual subscription version(s) with LNP Type of POOL, upon completion of the deletion broadcast to All EDR and non-EDR Local SMSs, an unsuccessful response from at least one Local SMS, and a response from ALL EDR and non-EDR Local SMSs, or retries are exhausted, as defined in RR3-138.1 and RR3-138.2. (Previously SV-365)          5.1.4.6   Subscription Version, Block Delete Validation of Subscription Versions            RR5-111   Block Delete Validation of Subscription Versions – Ensure no Subscription Versions with LNP Type POOL    NPAC SMS shall ensure that upon completion of an NPA-NXX-X delete (de-pool), there are no Subscription Versions of LNP Type POOL, remaining in the 1K Block. (Previously SV-429)  This section MOVED to section 3.12.4 Subscription Version, Bulk Data Downloads. The requirement number changed to reflect the new chapter.  RR5-112 Moved to section 3.12.4 Subscription Version, Bulk Data Downloads. This requirement number changed to RR3-324                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    5-69    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces    6. NPAC SMS Interfaces  Two CMIP-based, mechanized interfaces to the NPAC SMS were defined in the Illinois NPAC RSMS RFP. One interface supports the Service Provider’s Service Order Administration (SOA) systems. This interface is referred to as the SOA to NPAC SMS interface. The second interface supports the Service Provider’s Local Service Management System (LSMS). This interface is referred to as the NPAC SMS to LSMS interface. Both of the interfaces support two-way communications.  6.1 SOA to NPAC SMS Interface  6.2 NPAC SMS to Local SMS Interface  6.3 Interface Transactions  The CMIP protocol provides for six types of transactions over the interface (Reference: ISO 9595 and 9596). They are:     •   Create       •   Delete       •   Set       •   Get       •   M-Action       •   Event Report            R6-22   Manager-agent relationship of interface transactions    NPAC SMS Interoperable Interface shall be designed in terms of CMIP transactions in a manager-agent relationship.  6.4 Interface and Protocol Requirements  While it is expected that dedicated links will be used for the interfaces, switched connections should also be supported. Reliability and availability of the links will be essential and high capacity performance will be needed.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            R6-23   Open interfaces    The SOA to NPAC SMS Interface and the NPAC SMS to Local SMS Interface shall be open, non-proprietary interfaces and will not become the property of any entity.          6.4.1   Protocol Requirements            R6-24   Interface protocol stack    Both of the NPAC SMS interfaces, as defined above, shall be implemented via the following protocol stack:                INTERFACE PROTOCOL STACK    Application    CMISE, ACSE, ROSE           Presentation    ANSI T1.224           Session:    ANSI T1.224           Transport:    TCP, RFC1006           Network:    IP           Link    PPP, MAC, Frame Relay, ATM (IEEE 802.3)           Physical    DS1, DS-0 x n , V.34     Table 6-1 Interface Protocol Stack          R6-25   Multiple application associations    NPAC SMS shall support multiple application associations per Service Provider.          6.4.2   Interface Performance Requirements            R6-26   Interface availability    Both the SOA to NPAC SMS and the NPAC SMS to Local SMS interfaces shall be available on a 24 by 7 basis, consistent with other availability requirements in this specification.          R6-27   Interface reliability    A 99.9 % reliability rate shall be maintained for both the SOA to NPAC SMS and NPAC SMS to Local SMS interfaces.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            AR6-1   Range Activations    DELETED          AR6-2   Percent of Range Activations    DELETED          R6-28.1   SOA to NPAC SMS interface transaction rates — sustained    A transaction rate of 4.0 CMIP transactions (sustained) per second shall be supported by each SOA to NPAC SMS interface association.          R6-28.2   SOA to NPAC SMS interface transaction rates — peak    NPAC SMS shall support a rate of 10.0 CMIP operations per second (peak for a five minute period, within any 60 minute window) over a single SOA to NPAC SMS interface association.          R6-29.1   NPAC SMS to Local SMS interface transaction rates    DELETED          R6-29.2   NPAC SMS to Local SMS interface transaction rates — peak    NPAC SMS shall, support a rate of 5.2 CMIP operations per second (peak for a five minute period, within any 60 minute window) over each NPAC SMS to Local SMS interface association.          RR6-107   SOA to NPAC SMS interface transaction rates – total bandwidth    NPAC SMS shall support a total bandwidth of 40.0 SOA CMIP transactions per second (sustained) for a single NPAC SMS region. (previously NANC 393, NewReq 1)          RR6-108   NPAC SMS to Local SMS interface transaction rates – sustained    NPAC SMS shall support a rate of 4.0 CMIP transactions per second (sustained) over each NPAC SMS to Local SMS interface association. (previously NANC 393, NewReq 2)          RR6-109   NPAC SMS to Local SMS interface transaction rates – total bandwidth    NPAC SMS shall support a total bandwidth of 156 Local SMS CMIP transactions per second (sustained) for a single NPAC SMS region. (previously NANC 393, NewReq 3)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            6.4.3   Interface Specification Requirements            R6-30.1   Interface specification    The interoperable interface model defining both the NPAC to Local SMS and the SOA to NPAC SMS shall be specified in terms of ISO 10165-4, “Guideline for the Definition of Managed Objects (GDMO)”.          R6-30.2   Interface specification identification    The interface specification shall be referred to as the “NPAC SMS Interoperable Interface Specification” (NPAC SMS IIS).          R6-35   NPAC SMS Interoperable Interface Specification extensibility    The interface specified shall be capable of extension to account for evolution of the interface requirements.          RR6-1   Acknowledgment of a Cancel Pending for a Subscription Version    NPAC SMS shall acknowledge receiving a cancel pending request for a Subscription Version via the SOA to NPAC SMS Interface.          RR6-2   Acknowledgment of a Conflict Resolution for a Subscription Version    NPAC SMS shall acknowledge receiving a conflict resolution request for a Subscription Version via the SOA to NPAC SMS Interface.          RR6-3   Deferred Disconnect of a Subscription Version    NPAC SMS shall allow a specific Subscription Version to be placed into a deferred disconnect status by having the effective date in the future via the SOA to NPAC SMS Interface.          RR6-4   Cancel Request Notification    NPAC SMS shall notify a Service Provider of a request for a Subscription Version status to be changed to cancel via the SOA to NPAC SMS Interface.          RR6-5   Conflict Resolution Request Notification    NPAC SMS shall notify a Service Provider of a request for a Subscription Version status to be changed to conflict resolution via the SOA to NPAC SMS Interface.          6.4.4   Request Restraints            RR6-8   Tunable Parameter Number of Aggregated Download Records    NPAC SMS shall allow NPAC System Administrators to specify a tunable parameter value for the maximum number of download records.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-9   Download Time Tunable Parameter to Restricted Time Range    NPAC SMS shall allow NPAC System Administrators to specify a tunable parameter value for the maximum time range for a download.          RR6-13   Queries Constrained by NPA-NXX    NPAC SMS shall constrain all queries on the NPAC SMS to Local SMS Interface to one NPA-NXX plus additional filter criteria.          RR6-14   Subscription Version Resynchronization Filter Usage    NPAC SMS shall, for a Subscription Version Resynchronization request, over the NPAC SMS to Local SMS Interface, only send subscription version that are not filtered on the Local SMS.          6.4.5   Application Level Errors            RR6-110   NPAC SMS Application Level Errors    NPAC SMS shall provide application level errors in the CMIP messaging in the SOA to NPAC SMS Interface and NPAC SMS to Local SMS Interface for those Service Providers that support this functionality. (previously ILL 130, Req 1)          RR6-111   NPAC SMS Application Level Error Details    NPAC SMS shall use the application level errors defined in the IIS, PartII, Appendix A. (previously ILL 130, Req 2)          RR6-112   NPAC SMS Application Level Error Details in soft format    NPAC SMS shall provide application level error code-to-text details in a pipe-delimited, soft format, at the FTP sub-directory for each Service Provider. (previously ILL 130, Req 3)  Note: This code-to-text mapping is designed to allow a SOA/LSMS to decode an error code received from the NPAC, into its corresponding text description.          RR6-113   SOA Action Application Level Errors Indicator    NPAC SMS shall provide SOA Action Application Level Errors Indicator tunable parameter, which defines whether a Service Provider supports Application Level Errors across the SOA Interface for M-ACTIONs. (previously ILL 130, Req 4)  Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-114   SOA Action Application Level Error Indicator Default    NPAC SMS shall default the Service Provider SOA Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130, Req 5)          RR6-115   SOA Action Application Level Errors Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 6)          RR6-116   LSMS Action Application Level Errors Indicator    NPAC SMS shall provide an LSMS Action Application Level Errors Indicator tunable parameter which defines whether a Service Provider LSMS supports Application Level Errors across the LSMS Interface for M-ACTIONs. (previously ILL 130, Req 7)  Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.          RR6-117   LSMS Action Application Level Errors Indicator Default    NPAC SMS shall default the Service Provider LSMS Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130, Req 8)          RR6-118   LSMS Action Application Level Errors Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 9)          RR6-119   LSMS Application Level Errors Indicator    DELETED          RR6-120   LSMS Application Level Error Indicator Default    DELETED          RR6-121   LSMS Application Level Errors Indicator Modification    DELETED          RR6-193   SOA Non-Action Application Level Errors Indicator    NPAC SMS shall provide a SOA Non-Action Application Level Errors Indicator tunable parameter, which defines whether a Service Provider supports Application Level Errors across the SOA Interface for all non-M-ACTIONs. (previously ILL 130, Req 10)  Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-194   SOA Non-Action Application Level Errors Indicator Default    NPAC SMS shall default the Service Provider SOA Non-Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130, Req 11)          RR6-195   SOA Non-Action Application Level Errors Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Non-Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 12)          RR6-196   LSMS Non-Action Application Level Errors Indicator    NPAC SMS shall provide an LSMS Non-Action Application Level Errors Indicator tunable parameter, which defines whether a Service Provider supports Application Level Errors across the LSMS Interface for all non-M-ACTIONs. (previously ILL 130, Req 13)  Note: For Service Providers that do NOT support Application Level Errors, the NPAC will continue to send the existing CMIP error messages.          RR6-197   LSMS Non-Action Application Level Errors Indicator Default    NPAC SMS shall default the Service Provider LSMS Non-Action Application Level Errors Indicator tunable parameter to FALSE. (previously ILL 130 , Req 14)          RR6-198   LSMS Non-Action Application Level Errors Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS Non-Action Application Level Errors Indicator tunable parameter. (previously ILL 130, Req 15)  6.5 NPAC SOA Low-tech Interface  The NPAC SOA Low-tech Interface supports the request functionality of the SOA to NPAC SMS interface.          RX6-2.1   NPAC SOA Low-tech Interface    NPAC SMS shall provide an NPAC SOA Low-tech Interface.          RX6-2.2   SOA to NPAC SMS Create Subscription Versions administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall support Create Subscription Version requests via a secure, NPAC SOA Low-tech Interface.                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RX6-2.3   SOA to NPAC SMS Cancel Subscription Versions administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall support Cancel Subscription Version requests via a secure, NPAC SOA Low-tech Interface.          RX6-2.4   SOA to NPAC SMS Modify Subscription Versions administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall support Modify Subscription Version requests via a secure, NPAC SOA Low-tech Interface.          RX6-2.5   SOA to NPAC SMS Query Subscription Versions administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall support query of Subscription Versions via a secure, NPAC SOA Low-tech Interface.          RX6-2.6   SOA to NPAC SMS Activate Subscription Versions administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall support Activation of Subscription Versions via a secure, NPAC SOA Low-tech Interface.          RX6-2.7   SOA to NPAC SMS Disconnect Subscription Versions administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall allow NPAC personnel and users of the SOA to NPAC SMS interface to request disconnection of a Subscription Version via a secure, NPAC SOA Low-tech Interface.          RR6-189   SOA to NPAC SMS Un-Do Cancel-Pending Subscription Version administration requests via an NPAC SOA Low-tech Interface    NPAC SMS shall support the ability to submit an un-do Cancel-Pending Subscription Version request via a secure, NPAC SOA Low-tech Interface. (previously NANC 388)          RX6-3   SOA to NPAC SMS audit requests    NPAC SMS shall support SOA to NPAC SMS audit requests for all, part or one Service Provider via the NPAC SOA Low-tech Interface.          RR6-35   SOA to NPAC SMS Number Pool Block Create Request via the SOA Low-tech Interface    NPAC SMS shall allow NPAC Personnel and users of the SOA to NPAC SMS interface to request creation of a Number Pool Block via a secure, NPAC SOA Low-tech Interface.          RR6-36   SOA to NPAC SMS Number Pool Block Modify Request via the SOA Low-tech Interface    NPAC SMS shall allow NPAC Personnel and users of the SOA to NPAC SMS interface to request modification of a Number Pool Block via a secure, NPAC SOA Low-tech Interface.                       Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RX6-   4 NPAC SMS Notification Handling    NPAC SMS shall support, via a secure NPAC SOA Low-tech Interface, a method to view and locally capture notifications that have occurred for the service provider upon request.  6.6 CMIP Request Retry Requirements          RR6-15   SOA Retry Attempts — Tunable Parameter    NPAC SMS shall provide a SOA Retry Attempts tunable parameter which defines the number of times a message will be sent to a SOA which has not acknowledged receipt of the message.          RR6-16   SOA Retry Interval — Tunable Parameter    NPAC SMS shall provide a SOA Retry Interval tunable parameter, which defines the delay between sending a message to a SOA that has not acknowledged receipt of the message.          RR6-17   SOA Retry Attempts — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the SOA Retry Attempts tunable parameter.          RR6-18   SOA Retry Interval — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the SOA Retry Interval tunable parameter.          RR6-19   SOA Retry Attempts — Tunable Parameter Default    NPAC SMS shall default the SOA Retry Attempts tunable parameter to 3 times.          RR6-20   SOA Retry Interval — Tunable Parameter Default    NPAC SMS shall default the SOA Retry Interval tunable parameter to 2 minutes.          RR6-21   SOA Activation Failure Retry    NPAC SMS shall resend the message a SOA Retry Attempts tunable parameter number of times to a SOA that has not acknowledged the receipt of the message once the SOA Retry Interval tunable parameter expires.          RR6-22   LSMS Retry Attempts — Tunable Parameter    NPAC SMS shall provide an LSMS Retry Attempts tunable parameter which defines the number of times a message will be sent to a Local SMS which has not acknowledged receipt of the message.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-23   LSMS Retry Interval — Tunable Parameter    NPAC SMS shall provide an LSMS Retry Interval tunable parameter, which defines the delay between sending a message to a Local SMS that has not acknowledged receipt of the message.          RR6-24   LSMS Retry Attempts — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the LSMS Retry Attempts tunable parameter.          RR6-25   LSMS Retry Interval — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS Administrator to modify the LSMS Retry Interval tunable parameter.          RR6-26   LSMS Retry Attempts — Tunable Parameter Default    NPAC SMS shall default the LSMS Retry Attempts tunable parameter to 3 times.          RR6-27   LSMS Retry Interval — Tunable Parameter Default    NPAC SMS shall default the LSMS Retry Interval tunable parameter to 2 minutes.          RR6-28   LSMS Activation Failure Retry    NPAC SMS shall resend the message an LSMS Retry Attempts tunable parameter number of times to a Local SMS that has not acknowledged the receipt of the message once the LSMS Retry Interval tunable parameter expires.  6.7 Recovery –  The following section defines Recovery functionality supported by the NPAC SMS to SOA interface and NPAC SMS to LSMS interface.          RR6-84   Linked Replies Information – Sending Linked Replies During Recovery    NPAC SMS shall be capable of sending linked action replies, via the SOA to NPAC SMS Interface, and NPAC SMS to Local SMS Interface in response to a recovery request. (Previously NANC 187 Req 11)          RR6-85   Linked Replies Information – Service Provider SOA Linked Replies Indicator Sending of Linked Replies    NPAC SMS shall send Network and Notification Recovery Responses as Linked Replies, via the SOA to NPAC SMS Interface, if the Service Provider’s SOA Linked Replies indicator is TRUE, and the amount of data is greater than the associated Blocking Factor tunable parameter. (Previously NANC 187 Req 4)                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-86   Linked Replies Information – Service Provider SOA Linked Replies Indicator Sending of Non-Linked Replies    NPAC SMS shall send Network and Notification Recovery Responses as Non-Linked Replies, via the SOA to NPAC SMS Interface, if the Service Provider’s SOA Linked Replies indicator is FALSE. (Previously NANC 187 Req 5)          RR6-87   Linked Replies Information – Service Provider Local SMS Linked Replies Indicator Sending of Linked Replies    NPAC SMS shall send Network, Subscription, Number Pool Block and Notification Recovery Responses as Linked Replies, via the NPAC SMS to Local SMS Interface, if the Service Provider’s Local SMS Linked Replies indicator is TRUE, and the amount of data is greater than the associated Blocking Factor tunable parameter. (Previously NANC 187 Req 9)          RR6-88   Linked Replies Information – Service Provider Local SMS Linked Replies Indicator Sending of Non-Linked Replies    NPAC SMS shall send Network, Subscription, Number Pool Block and Notification Recovery Responses as Non-Linked Replies, via the NPAC SMS to Local SMS Interface, if the Service Provider’s Local SMS Linked Replies indicator is FALSE. (Previously NANC 187 Req 10)          RR6-122   SWIM Recovery Tracking    NPAC SMS shall provide functionality that tracks messages not sent to, and acknowledged by, a Service Provider SOA/LSMS for SWIM Recovery purposes. (previously NANC 351, Req 1)          RR6-123   Service Provider SOA SWIM Recovery Indicator    NPAC SMS shall provide a Service Provider SOA SWIM Recovery Indicator tunable parameter which defines whether a SOA supports SWIM recovery. (previously NANC 351, Req 2)          RR6-124   Service Provider SOA SWIM Recovery Indicator Default    NPAC SMS shall default the Service Provider SOA SWIM Recovery Indicator tunable parameter to FALSE. (previously NANC 351, Req 3)          RR6-125   Service Provider SOA SWIM Recovery Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA SWIM Recovery Indicator tunable parameter. (previously NANC 351, Req 4)          RR6-126   SOA SWIM Maximum Tunable    NPAC SMS shall provide a SOA SWIM Maximum tunable parameter, which is defined as the maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery. (previously NANC 351, Req 5)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-127   SOA SWIM Maximum Tunable Default    NPAC SMS shall default the SOA SWIM Maximum tunable parameter to 50,000. (previously NANC 351, Req 6)          RR6-128   SOA SWIM Maximum Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the SOA SWIM Maximum tunable parameter. (previously NANC 351, Req 7)          RR6-129   Service Provider LSMS SWIM Recovery Indicator    NPAC SMS shall provide a Service Provider LSMS SWIM Recovery Indicator tunable parameter, which defines whether a LSMS supports SWIM recovery. (previously NANC 351, Req 8)          RR6-130   Service Provider LSMS SWIM Recovery Indicator Default    NPAC SMS shall default the Service Provider LSMS SWIM Recovery Indicator tunable parameter to FALSE. (previously NANC 351, Req 9)          RR6-131   Service Provider LSMS SWIM Recovery Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS SWIM Recovery Indicator tunable parameter. (previously NANC 351, Req 10)          RR6-190   LSMS SWIM Maximum Tunable    NPAC SMS shall provide a LSMS SWIM Maximum tunable parameter, which is defined as the maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery. (previously, NANC 351, Req 11)          RR6-191   LSMS SWIM Maximum Tunable Default    NPAC SMS shall default the LSMS SWIM Maximum tunable parameter to 50,000. (previously NANC 351, Req 12)          RR6-192   LSMS SWIM Maximum Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the LSMS SWIM Maximum tunable parameter. (previously NANC 351, Req 13)          6.7.1   Notification Recovery    The following section defines specific requirements of the Notification Recovery functionality supported by the NPAC SMS.                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-12    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-29   Notification Recovery    NPAC SMS shall support recovery of all CMIP notifications defined in the IIS that are emitted over the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces. Examples of notifications to be recovered include:       •   subscriptionVersionNewNPA-NXX        •   subscriptionVersionDonorSP-CustomerDisconnectDate        •   subscriptionAudit-DiscrepancyRpt        •   subscriptionAuditResults        •   lnpNPAC-SMS-Operational-Information        •   subscriptionVersionNewSP-CreateRequest (time sensitive T1 New SP)        •   subscriptionVersionOld-SP-ConcurrenceRequest (time sensitive T1 Old SP)        •   subscriptionVersionOldSPFinalWindowExpiration (time sensitive T2 Old SP)        •   subscriptionVersionStatusAttributeValueChange        •   numberPoolBlockStatusAttributeValueChange        •   attributeValueChange        •   objectCreation        •   objectDeletion        •   subscriptionVersionNewSP-FinalCreateWindowExpiration (if supported by the recovering SOA)        •   subscriptionVersionRangeStatusAttributeValueChange        •   subscriptionVersionRangeAttributeValueChange        •   subscriptionVersionRangeObjectCreation        •   subscriptionVersionRangeDonorSP-CustomerDisconnectDate        •   subscriptionVersionRangeNewSP-CancellationAcknowledge        •   subscriptionVersionRangeNewSP-CreateRequest        •   subscriptionVersionRangeOldSP-ConcurrenceRequest        •   subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration        •   subscriptionVersionRangeNewSPFinalCreateWindowExpiration            For a complete list of notifications reference the IIS.            RR6-79   TN Range Notification Information – Recovery of TN Range Notifications    NPAC SMS shall send TN Range Notifications during recovery that mimic the same TN Range Notifications that would have been received by the Service Provider had they been associated during the original broadcast of the TN Range Notifications. (Formerly NANC 179 Req 8)          RR6-80   TN Range Notification Information – Single NPA-NXX    NPAC SMS shall only allow a TN Range Notification to be inclusive within a single NPA-NXX. (Formerly NANC 179 Req 9)          RR6-81   TN Range Notifications – When They Will be Sent    NPAC SMS shall send, to Service Providers that have their TN Range Notification Indicator set to TRUE, the corresponding range notifications in place of the following notifications and their recovery counterpart:       •   subscriptionVersionStatusAttributeValueChange        •   subscriptionVersionAttributeValueChange        •   subscriptionVersionObjectCreation        •   subscriptionVersionDonorSP-CustomerDisconnectDate                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-13    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces         •   subscriptionVersionNewSP-CancellationAcknowledge        •   subscriptionVersionNewSP-CreateRequest        •   subscriptionVersionOldSP-ConcurrenceRequest        •   subscriptionVersionOldSPFinalConcurrenceWindowExpiration        •   subscriptionVersionNewSPFinalCreateWindowExpiration    (Formerly NANC 179 Req 10)          RR6-82   Range Sizes and Format of Notifications Sent in Recovery    NPAC SMS shall, during recovery, send a service provider’s notifications in the original range sizes and in the format that corresponds to their TN Range Notification Indicator value at the time of recovery. (Formerly NANC 179 Req 11)          RR6-30   Notification Recovery – Order of Recovery    NPAC SMS shall recover all notifications, failed or successful, in the order the NPAC SMS attempts to send them when notification recovery is requested by the SOA or LSMS.          RR6-31   Notification Recovery – Time Range Limit    NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a notification recovery request.          RR6-32   Notification Recovery – SOA and LSMS Independence    NPAC SMS shall support the recovery of notifications for the SOA and LSMS as independent requests.          RR6-33   Notification Recovery – SOA Notifications    NPAC SMS shall allow the SOA to only recover SOA notifications.          RR6-83   Maintaining Priority of SOA Notifications During Recovery    NPAC SMS shall, during recovery, maintain the priority of the SOA Notifications that reflect the values of the SOA Notification Priority Tunable Parameter at the time the notification was created. (Formerly NANC 329 Req 5.5)          RR6-34 Notification Recovery – LSMS Notifications    NPAC SMS shall allow the LSMS to only recover LSMS notifications.          RR6-89   Linked Replies Information – Sending Linked Replies During Notification Data Recovery to SOA    NPAC SMS shall send notification data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, in groups of notifications based on the Notification Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 24)                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-14    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-90   Linked Replies Information – Sending Linked Replies During Notification Data Recovery to Local SMS    NPAC SMS shall send notification data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of notifications based on the Notification Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 25)          RR6-91   Linked Replies Information – Notification Data Recovery Maximum Size to SOA    NPAC SMS shall allow notification data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, to be as large as the Notification Data Maximum Linked Recovered Notifications tunable parameter value. (Previously NANC 187 Req 38)          RR6-96   Linked Replies Information – Notification Data Recovery Maximum Size to Local SMS    NPAC SMS shall allow notification data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Notification Data Maximum Linked Recovered Notifications tunable parameter value. (Previously NANC 187 Req 39)          RR6-132   Notification Recovery – Notification Data Criteria    NPAC SMS shall require a SOA/LSMS to specify one of the following choices for notification data recovery criteria:     •   Time-range       •   SWIM (Send What I Missed)    (previously NANC 351, Req 0.5)          6.7.2   Network Data Recovery    The following section defines specific requirements of the Network Data Recovery functionality supported by the NPAC SMS.          RR6-37   Network Data Recovery    NPAC SMS shall provide a mechanism that allows a SOA or LSMS to recover network data downloads that were missed during a broadcast to the SOA or LSMS.          RR6-38   Network Data Recovery – Order of Recovery    NPAC SMS shall recover all network data download broadcasts in time sequence order when network data recovery is requested by the SOA or LSMS.          RR6-39   Network Data Recovery – Time Range Limit    NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a network data recovery request.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-15    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces    RR6-40 Network Data Recovery – SOA and LSMS Independence  NPAC SMS shall support the recovery of network data for the SOA and LSMS as independent requests.          RR6-41   Network Data Recovery – SOA Network Data    NPAC SMS shall allow the SOA to only recover network data downloads intended for the SOA.          RR6-42   Network Data Recovery – LSMS Network Data    NPAC SMS shall allow the LSMS to only recover network data downloads intended for the LSMS.          RR6-43   Network Data Recovery – Network Data Criteria    NPAC SMS shall support the following network data download criteria:     •   Single Service Provider or all Service Providers with optional time range       •   SWIM Send What I Missed            RR6-44   Network Data Recovery – Network Data Choices    NPAC SMS shall require one of the following network data download choices:     •   npa-nxx-data (with one of the two selections below)          - npa-nxx-range          - all       •   lrn data (with one of the two selections below)          - lrn-range          - all       •   all network data       •   npa-nxx-x-data (with one of the two selections below)          - npa-nxx-x-range          - all            RR6-45   Resynchronization of Number Pool NPA-NXX-X Holder Information – Local SMS NPA-NXX-X Indicator set to TRUE    NPAC SMS shall process a Service Provider request to download Network data over the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall send the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer LSMS NPA-NXX-X Indicator is set to TRUE. (Previously N-380)          RR6-46   Resynchronization of Number Pool NPA-NXX-X Holder Information – Local SMS NPA-NXX-X Indicator set to FALSE    NPAC SMS shall process a Service Provider request to download Network data over the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall suppress the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer LSMS NPA-NXX-X Indicator is set to FALSE. (Previously N-390)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-16    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-47   Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and queuing of messages to Local SMS    NPAC SMS shall queue up a single instance of all messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the NPAC SMS and where the resynchronization flag is set to TRUE. (Previously N-392)          RR6-48   Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and sending of queued messages to Local SMS    NPAC SMS shall send queued up messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider has sent a message to the NPAC SMS that resynchronization has been completed. (Previously N-394)          RR6-49   Resynchronization of Number Pool NPA-NXX-X Holder Information – Filters on NPA-NXX-X resync to Local SMS    NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X resynchronization to the Local SMS(s) via the NPAC SMS to Local SMS Interface. (Previously N-400)          RR6-50   Resynchronization of Number Pool NPA-NXX-X Holder Information – SOA NPA-NXX-X Indicator set to TRUE    NPAC SMS shall process a Service Provider request to download Network data over the SOA to NPAC SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall send the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer SOA NPA-NXX-X Indicator is set to TRUE. (Previously N-410)          RR6-51   Resynchronization of Number Pool NPA-NXX-X Holder Information – SOA NPA-NXX-X Indicator set to FALSE    NPAC SMS shall process a Service Provider request to download Network data over the SOA to NPAC SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and the download of NPA-NXX-X (or ALL) is TRUE, and shall suppress the NPA-NXX-X portion of the Network data when the Service Provider’s NPAC Customer SOA NPA-NXX-X Indicator is set to FALSE. (Previously N-420)          RR6-52   Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and queuing of messages to SOA    NPAC SMS shall queue up a single instance of all messages to the SOA, via the SOA to NPAC SMS Interface, when a Service Provider establishes an association with the NPAC SMS and where the resynchronization flag is set to TRUE. (Previously N-430)          RR6-53   Resynchronization of Number Pool NPA-NXX-X Holder Information – NPA-NXX-X resync and sending of queued messages to SOA    NPAC SMS shall send queued up messages to the SOA, via the SOA to NPAC SMS Interface, when a Service Provider has sent a message to the NPAC SMS that resynchronization has been completed. (Previously N-440)                        Release4 3.3:© 1997 — 2006 NeuStar, Inc.    6-17    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-54   Resynchronization of Number Pool NPA-NXX-X Holder Information – Filters on NPA-NXX-X resync to SOA    NPAC SMS shall apply NPA-NXX Filters to NPA-NXX-X resynchronization to the SOA(s) via the SOA to NPAC SMS Interface. (Previously N-450)          RR6-92   Linked Replies Information – Sending Linked Replies During Network Data Recovery to SOA    NPAC SMS shall send network data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 15)          RR6-93   Linked Replies Information – Sending Linked Replies During Network Data Recovery to Local SMS    NPAC SMS shall send network data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 16)          RR6-94   Linked Replies Information – Network Data Recovery Maximum Size to SOA    NPAC SMS shall allow network data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (Previously NANC 187 Req 29)          RR6-95   Linked Replies Information – Network Data Recovery Maximum Size to Local SMS    NPAC SMS shall allow network data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (Previously NANC 187 Req 30)          6.7.3   Subscription Data Recovery    The following section defines specific requirements of the Subscription Data Recovery functionality supported by the NPAC SMS.          RR6-55   Subscription Data Recovery    NPAC SMS shall provide a mechanism that allows an LSMS to recover subscription data downloads that were missed during a broadcast to the LSMS.          RR6-56   Subscription Data Recovery – Order of Recovery    NPAC SMS shall recover subscription data download broadcasts in time sequence order when subscription data recovery is requested by the LSMS.                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-18    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-57   Subscription Data Recovery – Time Range Limit    NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a subscription data recovery request.          RR6-58   Subscription Data Recovery – Subscription Data Choices    NPAC SMS shall require an LSMS to specify one of the following choices in a subscription data recovery request:     •   time-range       •   TN       •   TN-range (NPA-NXX-XXXX) – (YYYY)       •   SWIM (Send What I Missed)            RR6-59   Subscription Data Recovery – Full Failure SV    NPAC SMS shall exclude Subscription Versions with a status of failed, when subscription data recovery is requested by the LSMS.          RR6-60   Subscription Data Recovery – SV Timestamp for Requested Time Range    NPAC SMS shall use the Subscription Version’s Broadcast Timestamp value to determine if an SV falls within the requested time range for a subscription data recovery request.          RR6-97   Subscription Data Recovery – Statuses of Subscription Versions Recovered    NPAC SMS shall include Subscription Versions with a status of active, partial failure, disconnect-pending, old with a failed list, and sending, at the time subscription data recovery is requested by the Local SMS and processed by the NPAC SMS, for all Subscription Versions with broadcast activity during the requested recovery timeframe. (Previously NANC 297 Req 1)          RR6-61   Subscription Data Recovery – Removal of Service Provider from Failed List    NPAC SMS shall remove a Service Provider from the Failed SP List of an SV, upon successful recovery of the subscription data.          RR6-98   Subscription Data Recovery – Removal of Service Provider from Failed SP List of Subscription Versions Recovered    NPAC SMS shall remove a Service Provider from the Failed SP List of a Subscription Version with a status of sending, even if there are additional retry attempts, after the subscription data recovery response has been sent to the Local SMS of that Service Provider. (Previously NANC 297 Req 2)          RR6-99   Subscription Data Recovery – Suppression of Broadcast of Subscription Versions Recovered    NPAC SMS shall ensure that the download of subscription data that was in a sending status at the start of the Subscription Data recovery process, even if there are additional retry attempts, is not sent to the Service Provider at the completion of recovery that included subscription data to the Local SMS. (Previously NANC 297 Req 3)                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-19    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-62   Subscription Data Recovery – Successful Recovery of SV Data and Removal of Service Provider from Failed List – Both Service Providers    NPAC SMS shall send, to the Old and New Service Providers, the status and a list of all Local SMSs that currently exist on the Failed SP List of an SV, upon successful recovery of the subscription data, with the exception of modify active or disconnect requests.          RR6-63   Subscription Data Recovery – Successful Recovery of SV Data and Removal of Service Provider from Failed List – New Service Provider Only    NPAC SMS shall send, to the New Service Provider only, the status and a list of all Local SMSs that currently exist on the Failed SP List of an SV, upon successful recovery of the subscription data, specific to modify active or disconnect requests.          RR6-133   Subscription Version Failed SP List – Recovery of Excluded Service Provider Subscription Versions    NPAC SMS shall, for a recovery of subscription data, in instances where the NPAC SMS excluded the Service Provider from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface, allow the Local SMS to recover a Subscription Version with all current attributes, even though the Service Provider is no longer on the Failed SP List. (previously NANC 227/254, Req 3)          RR6-64   Number Pool Block Holder Information Resynchronization – Block    NPAC SMS shall process a Service Provider request to download Block data over the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the resynchronization flag set to TRUE, and requests Block data based on criteria sent to the NPAC SMS upon association. (Previously B-690)          RR6-65   Number Pool Block Holder Information Resynchronization – Block Criteria    NPAC SMS shall accept criteria for Block data, of either Time Range in GMT or Block Range entry fields or SWIM, where the Time Range in GMT includes the starting time in GMT and ending time in GMT based on the Activation Start Timestamp/Disconnect Broadcast Timestamp/Modify Broadcast Timestamp, and the Block Range includes the starting Block and ending Block. (Previously B-691)  Note: If the Block Range was 303-242-2 through 303-355-6, the range would contain all Blocks within the TN Range of 303-242-2000 through 303-355-6999.          RR6-66   Number Pool Block Holder Information Resynchronization – Block Range Tunable Parameters    NPAC SMS shall use the existing Subscription Version tunables for Maximum Download Duration and Maximum Number of Download Records, as defined in the Functional Requirements Specification’ s Appendix C, for Blocks that can be resynchronized by a Local SMS. (Previously B-695)          RR6-67   Number Pool Block Holder Information Resynchronization – Rejection of Block Criteria    NPAC SMS shall reject a resynchronization request, if the criteria of either Time Range or Block Range, exceeds the current values of the Maximum Download Duration or Maximum Number of Download Records tunables. (Previously B-698)                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-20    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-68   Number Pool Block Holder Information Resynchronization – Block resync and queuing of messages    NPAC SMS shall queue up a single instance of all messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider establishes an association with the NPAC SMS and where the resynchronization flag is set to TRUE. (Previously B-700)          RR6-69   Number Pool Block Holder Information Resynchronization – Block resync and sending of queued messages    NPAC SMS shall send, queued up messages to the Local SMS, via the NPAC SMS to Local SMS Interface, when a Service Provider has sent a message to the NPAC SMS that resynchronization has been completed. (Previously B-710)          RR6-70   Number Pool Block Holder Information Resynchronization – Filters on Block resync    NPAC SMS shall apply NPA-NXX Filters to Block resynchronization to the Local SMS(s), via the NPAC SMS to Local SMS Interface. (Previously B-720)          RR6-71   Number Pool Block Holder Information Resynchronization – Update to Failed SP List    NPAC SMS shall update the Block Failed SP List and Subscription Version Failed SP List, by removing the resyncing Local SMS, upon a successful response to a resynchronization request to a previously failed EDR Local SMS, as defined in RR3-138.1 and RR3-138.2. (Previously B-730)          RR6-100   Number Pool Block Data Recovery – Statuses of Number Pool Blocks Recovered    NPAC SMS shall include Number Pool Blocks with a status of active, partial failure, old with a failed list, and sending, at the time Number Pool Block data recovery is requested by the Local SMS and processed by the NPAC SMS, for all Number Pool Blocks with broadcast activity during the requested recovery timeframe. (Previously NANC 297 Req 4)          RR6-101   Number Pool Block Data Recovery – Removal of Service Provider from Failed SP List of Number Pool Blocks Recovered    NPAC SMS shall remove a Service Provider from the Failed SP List of a Number Pool Block with a status of sending, even if there are additional retry attempts, after the Number Pool Block data recovery response has been sent to the Local SMS of that Service Provider. (Previously NANC 297 Req 5)          RR6-134   Number Pool Block Failed SP List – Recovery of Excluded Service Provider Subscription Versions    NPAC SMS shall, for a recovery of number pool block data, in instances where the NPAC SMS excluded the Service Provider from the Failed SP List based on a request by NPAC Personnel via the NPAC Administrative Interface, allow the Local SMS to recover a Number Pool Block or its associated pool-type subscription versions with all current attributes, even though the Service Provider is no longer on the Failed SP List. (previously NANC 300, Req 3)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    6-21    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces            RR6-102   Number Pool Block Data Recovery – Suppression of Broadcast of Number Pool Blocks Recovered    NPAC SMS shall ensure that the download of Number Pool Block data that was in a sending status at the start of the Number Pool Block Data recovery process, even if there are additional retry attempts, is not sent to the Service Provider at the completion of recovery that included Number Pool Block data to the Local SMS. (Previously NANC 297 Req 6)          RR6-72   Number Pool Block Holder Information Resynchronization – Status Update to Block after Successful Resynchronization    NPAC SMS shall update the status of the Block, specified in the resynchronization request for a Block Creation, Modification, or Deletion, at the completion of the resynchronization to the Local SMS, as defined in RR3-137.1, RR3-137.2, RR3-137.3, and RR3-137.4. (Previously B-740)          RR6-73   Number Pooling Subscription Version Information Resynchronization – Filters on Subscription Versions Resync    NPAC SMS shall filter out Subscription Versions with LNP Type of POOL for Resynchronization of Subscription Version data, when the resyncing Service Provider has an EDR Indicator set to TRUE. (Previously SV-522)          RR6-74   Number Pooling Subscription Version Information Resynchronization – Disconnect or Port-To-Original of a TN within a Pooled 1K Block    NPAC SMS shall examine a Service Provider’s EDR Indicator, at the time of resync, to determine the message to resync, for a disconnect or a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block. (Previously SV-530)          RR6-75   Number Pooling Subscription Version Information Resynchronization – Disconnect TN within a Pooled 1K Block to EDR Local SMS    NPAC SMS shall, for a resync of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the EDR Local SMS to recover the Delete request of the Subscription Version that was active prior to the disconnect broadcast, regardless of it’s status, to an EDR Local SMS. (Previously SV-540)  Note: The NPAC SMS will resync an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the disconnect request (SV2), as defined in the IIS Flows for Disconnect of a Ported Pooled Number, and regardless of the status on SV1.          RR6-76   Number Pooling Subscription Version Information Resynchronization – Disconnect TN within a Pooled 1K Block to non-EDR Local SMS    NPAC SMS shall, for a resync of a disconnect Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the non-EDR Local SMS to recover the Create request of the Subscription Version that was created to restore default routing, regardless of it’s status, and regardless of the status of the Subscription Version that was active prior to the disconnect broadcast, to a non-EDR Local SMS. (Previously SV-550)  Note: The NPAC SMS will resync an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV2) that was created to restore default routing (SV1), even though the Failed SP List resides on SV1, as defined in the IIS Flows for Disconnect of a Ported Pooled Number, and regardless of the status on SV1 and SV2.                        Release 3.3:© 1997 — 2006 NeuStar, Inc.    6-22    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             NPAC SMS Interfaces             RR6-77   Number Pooling Subscription Version Information Resynchronization —Port-To-Original TN within a Pooled 1K Block to EDR Local SMS    NPAC SMS shall, for a resync of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the EDR Local SMS to recover the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast, regardless of it’s status, and regardless of the status of the Subscription Version that is used to generate the Port-To-Original request to the NPAC SMS, to an EDR Local SMS. (Previously SV-560)  Note: The NPAC SMS will resync an M-DELETE, to an EDR Local SMS, of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number, and regardless of the status on SV1 and SV2.          RR6-78   Number Pooling Subscription Version Information Resynchronization — Port-To-Original TN within a Pooled 1K Block to non-EDR Local SMS    NPAC SMS shall, for a resync of a Port-To-Original Subscription Version of a ported pooled TN, where the TN is contained within a Pooled 1K Block, allow the non-EDR Local SMS to recover the Create request of the Subscription Version that was created to restore default routing, and shall NOT allow the non-EDR Local SMS to recover the Delete request of the Subscription Version that was active prior to the Port-To-Original broadcast, regardless of it’s status, regardless of the status of the Subscription Version that is used to generate the Port-To-Original request to the NPAC SMS, and regardless of the status of the Subscription Version that was created to restore default routing, to a non-EDR Local SMS. (Previously SV-570)  Note: The NPAC SMS will resync an M-CREATE, to a non-EDR Local SMS, of the Subscription Version (SV3) that was created to restore default routing, and will NOT resync an M-DELETE of the Subscription Version (SV1) that was active prior to the Port-To-Original request (SV2), even though the Failed SP List resides on SV2, as defined in the IIS Flows for a Port-To-Original of a Ported Pooled Number, and regardless of the status on SV1, SV2, and SV3.          RR6-103   Linked Replies Information — Sending Linked Replies During Subscription Data Recovery to Local SMS    NPAC SMS shall send subscription data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Subscription Data Linked Replies Blocking Factor tunable parameter value. (Previously NANC 187 Req 20)          RR6-104   Linked Replies Information — Subscription Data Recovery Maximum Size to Local SMS    NPAC SMS shall allow subscription data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Subscription Data Maximum Linked Recovered Objects tunable parameter value. (Previously NANC 187 Req 34)          RR6-105   Linked Replies Information — Sending Linked Replies During Number Pool Block Recovery to Local SMS    NPAC SMS shall send number pool block data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Number Pool Block Data Linked Replies Blocking Factor tunable parameter value. (Previously related to NANC 187)                         Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-23    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces              RR6-106   Linked Replies Information — Number Pool Block Recovery Maximum Size to Local SMS    NPAC SMS shall allow number pool block data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Number Pool Block Data Maximum Linked Recovered Objects tunable parameter value. (Previously related to NANC 187)  6.7.4 Service Provider Recovery          RR6-135   Service Provider Data Recovery    NPAC SMS shall provide a mechanism that allows a SOA or LSMS to recover service provider downloads that were missed during a broadcast to the SOA or LSMS. (previously NANC 352, Req 1)          RR6-136   Service Provider Data Recovery Only in Recovery Mode    NPAC SMS shall allow a SOA or LSMS to recover service provider data ONLY in recovery mode. (previously NANC 352, Req 2)          RR6-137   Service Provider Data Recovery — Order of Recovery    NPAC SMS shall recover all service provider data download broadcasts in time sequence order when service provider recovery is requested by the SOA or LSMS. (previously NANC 352, Req 3)          RR6-138   Service Provider Data Recovery — Time Range Limit    NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in a service provider data recovery request. (previously NANC 352, Req 4)          RR6-139   Service Provider Data Recovery — SOA and LSMS Independence    NPAC SMS shall support the recovery of service provider data for the SOA and LSMS as independent requests. (previously NANC 352, Req 5)          RR6-140   Service Provider Data Recovery — SOA Network Data    NPAC SMS shall allow the SOA to only recover service provider data downloads intended for the SOA. (previously NANC 352, Req 6)          RR6-141   Service Provider Data Recovery — LSMS Network Data    NPAC SMS shall allow the LSMS to only recover service provider data downloads intended for the LSMS. (previously NANC 352, Req 7)          RR6-142   Service Provider Data Recovery — Service Provider Data Criteria    NPAC SMS shall support the following service provider data download criteria:                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-24    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces         •   Single Service Provider with optional time range, or all Service Providers with optional time range      •   SWIM (Send What I Missed)    (previously NANC 352, Req 8)          RR6-143   Service Provider Data Recovery — Network Data Choices    DELETED          RR6-144   Linked Replies Information — Sending Linked Replies During Service Provider Data Recovery to SOA    NPAC SMS shall send Service Provider data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (previously NANC 352, Req 10)          RR6-145   Linked Replies Information — Sending Linked Replies During Service Provider Data Recovery to Local SMS    NPAC SMS shall send Service Provider data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, in groups of objects based on the Network Data Linked Replies Blocking Factor tunable parameter value. (previously NANC 352, Req 11)          RR6-146   Linked Replies Information — Service Provider Data Recovery Maximum Size to SOA    NPAC SMS shall allow Service Provider data in response to a recovery request, via the SOA to NPAC SMS Interface, to a SOA that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (previously NANC 352, Req 12)          RR6-147   Linked Replies Information — Service Provider Data Recovery Maximum Size to Local SMS    NPAC SMS shall allow Service Provider data in response to a recovery request, via the NPAC SMS to Local SMS Interface, to a Local SMS that support Linked Replies, to be as large as the Network Data Maximum Linked Recovered Objects tunable parameter value. (previously NANC 352, Req 13)  6.8 Out-Bound Flow Control          RR6-148   Out-Bound Flow Control Upper Threshold Tunable    NPAC SMS shall provide an Out-Bound Flow Control Upper Threshold tunable parameter which is defined as the number of non-responsive messages sent to a SOA/LSMS before Out-Bound Flow Control is invoked, on a per association basis. (previously NANC 368, Req 1)          RR6-149   Out-Bound Flow Control Upper Threshold Tunable Default    NPAC SMS shall default the Out-Bound Flow Control Upper Threshold tunable parameter to 100 messages. (previously NANC 368, Req 2)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-25    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces              RR6-150   Out-Bound Flow Control Upper Threshold Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Out-Bound Flow Control Upper Threshold tunable parameter. (previously NANC 368, Req 3)          RR6-151   Out-Bound Flow Control Lower Threshold Tunable    NPAC SMS shall provide an Out-Bound Flow Control Lower Threshold tunable parameter which is defined as the number of non-responsive messages sent to a SOA/LSMS that is in a Flow Control state before normal processing is resumed, on a per association basis. (previously NANC 368, Req 4)          RR6-152   Out-Bound Flow Control Lower Threshold Tunable Default    NPAC SMS shall default the Out-Bound Flow Control Lower Threshold tunable parameter to 75 messages. (previously NANC 368, Req 5)          RR6-153   Out-Bound Flow Control Lower Threshold Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Out-Bound Flow Control Lower Threshold tunable parameter. (previously NANC 368, Req 6)  6.9 Roll-Up Activity and Abort Behavior          RR6-154   Roll-Up Activity-Single Tunable    NPAC SMS shall provide a Roll-Up Activity Timer — Single tunable parameter, which is defined as the number of minutes before roll-up activity is initiated for an event involving a single SV. (previously NANC 347/350, Req 1)          RR6-155   Roll-Up Activity-Single Tunable Default    NPAC SMS shall default the Roll-Up Activity Timer — Single tunable parameter to 15 minutes. (previously NANC 347/350, Req 2)          RR6-156   Roll-Up Activity-Single Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Roll-Up Activity Timer — Single tunable parameter. (previously NANC 347/350, Req 3)          RR6-157   Roll-Up Activity Timer Expire SVRange Tunable    NPAC SMS shall provide a Roll-Up Activity Timer Expire SVRange tunable parameter which is defined as the number of minutes before roll-up activity is initiated for an event involving a range of SVs. (previously NANC 347/350, Req 4)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-26    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces              RR6-158   Roll-Up Activity Timer Expire SVRange Tunable Default    NPAC SMS shall default the Roll-Up Activity Timer Expire SVRange tunable parameter to 60 minutes. (previously NANC 347/350, Req 5)          RR6-159   Roll-Up Activity Timer Expire SVRange Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Roll-Up Activity Timer Expire SVRange tunable parameter. (previously NANC 347/350, Req 6)          RR6-160   Abort Processing Behavior Upper Threshold Tunable    NPAC SMS shall provide an Abort Processing Behavior Upper Threshold tunable parameter which is defined as the number of minutes before an NPAC abort will occur for a SOA/LSMS that has at least one outstanding message with a delta between the origination time and the current time that is equal to or greater than the tunable window, regardless of whether the SOA/LSMS has incurred any other activity (request or response). (previously NANC 347/350, Req 7)          RR6-161   Abort Processing Behavior Upper Threshold Tunable Default    NPAC SMS shall default the Abort Processing Behavior Upper Threshold tunable parameter to 60 minutes. (previously NANC 347/350, Req 8)          RR6-162   Abort Processing Behavior Upper Threshold Tunable Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Abort Processing Behavior Upper Threshold tunable parameter. (previously NANC 347/350, Req 9)  6.10 NPAC Monitoring of SOA and LSMS Associations          RR6-163   NPAC SMS Monitoring of SOA and Local SMS Connections via a Application Level Heartbeat    NPAC SMS shall be capable of supporting an Application Level Heartbeat via an Application Level Heartbeat message to a Service Provider SOA/Local SMS. (previously NANC 299, Req 1)          RR6-164   NPAC SMS-to-SOA Application Level Heartbeat Indicator    NPAC SMS shall provide a Service Provider SOA Application Level Heartbeat Indicator tunable parameter which defines whether a SOA supports an Application Level Heartbeat message. (previously NANC 299, Req 2)          RR6-165   NPAC SMS-to-SOA Application Level Heartbeat Indicator Default    NPAC SMS shall default the Service Provider SOA Application Level Heartbeat Indicator tunable parameter to FALSE. (previously NANC 299, Req 3)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-27    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces              RR6-166   NPAC SMS-to-SOA Application Level Heartbeat Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Application Level Heartbeat Indicator tunable parameter. (previously NANC 299, Req 4)          RR6-167   NPAC SMS-to-Local SMS Application Level Heartbeat Indicator    NPAC SMS shall provide a Service Provider Local SMS Application Level Heartbeat Indicator tunable parameter which defines whether an Local SMS supports an Application Level Heartbeat message. (previously NANC 299, Req 5)          RR6-168   NPAC SMS-to- Local SMS Application Level Heartbeat Indicator Default    NPAC SMS shall default the Service Provider Local SMS Application Level Heartbeat Indicator tunable parameter to FALSE. (previously NANC 299, Req 6)          RR6-169   NPAC SMS-to- Local SMS Application Level Heartbeat Indicator Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Local SMS Application Level Heartbeat Indicator tunable parameter. (previously NANC 299, Req 7)          RR6-170   NPAC SMS Application Level Heartbeat Tunable Parameter    NPAC SMS shall provide an Application Level Heartbeat Interval tunable parameter that defines the period of quiet time (no interface traffic) the NPAC should wait after the receipt of any interface traffic (request or response), before sending an Application Level Heartbeat message to the SOA/Local SMS. (previously NANC 299, Req 8)          RR6-171   NPAC SMS Application Level Heartbeat Tunable Parameter Usage    NPAC SMS shall use the same tunable value for both SOA and the Local SMS Associations. (previously NANC 299, Req 9)          RR6-172   NPAC SMS Application Level Heartbeat Tunable Parameter Default    NPAC SMS shall default the Application Level Heartbeat Interval tunable parameter to 15 minutes. (previously NANC 299, Req 10)          RR6-173   NPAC SMS Application Level Heartbeat Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the NPAC SMS Application Level Heartbeat tunable parameter. (previously NANC 299, Req 11)          RR6-174   NPAC SMS Application Level Heartbeat Timeout Tunable Parameter    NPAC SMS shall provide an Application Level Heartbeat Timeout tunable parameter that defines the period of time the NPAC should wait after sending an Application Level Heartbeat message to the SOA/Local SMS and not receiving a response from the SOA/Local SMS, before aborting the association. (previously NANC 299, Req 12)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-28    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces              RR6-175   NPAC SMS Application Level Heartbeat Timeout Tunable Parameter Usage    NPAC SMS shall use the same tunable value for both SOA and the Local SMS Associations. (previously NANC 299, Req 13)          RR6-176   NPAC SMS Application Level Heartbeat Timeout Tunable Parameter Default    NPAC SMS shall default the Application Level Heartbeat Timeout tunable parameter to 1 minute. (previously NANC 299, Req 14)          RR6-177   NPAC SMS Application Level Heartbeat Timeout Tunable Parameter Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the NPAC SMS Application Level Heartbeat Timeout tunable parameter. (previously NANC 299, Req 15)  6.11 Separate SOA Channel for Notifications          RR6-178   SOA Notification Channel Service Provider Indicator    NPAC SMS shall provide a Service Provider SOA Notification Channel indicator which defines whether a SOA supports a separate SOA association dedicated to notifications. (previously NANC 383, Req 1)          RR6-179   SOA Notification Channel Service Provider Indicator — Default    NPAC SMS shall default the Service Provider SOA Notification Channel indicator to FALSE. (previously NANC 383, Req 2)          RR6-180   SOA Notification Channel Service Provider Indicator — Modification    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Notification Channel indicator. (previously NANC 383, Req 3)          RR6-181   Separation of Association Functions    DELETED          RR6-182   Separate Association for the Notification Function From different NSAPs    NPAC SMS shall accept a separate association from the SOA for the Notification function from different Service Provider NSAPs, when the SOA Notification Channel tunable is set to TRUE. (previously NANC 383, Req 5)          RR6-183   Security Management of Multiple SOA Associations of Different Association Functions    NPAC SMS shall manage security for multiple SOA associations of different association functions from different Service Provider NSAPs. (previously NANC 383, Req 6)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-29    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            NPAC SMS Interfaces              RR6-184   Sending of SOA Notifications when Notification Channel is Active    NPAC SMS shall send notifications for a particular Service Provider across a Notification Channel when it is active. (previously NANC 383, Req 7)          RR6-185   Separate Notification Channel during Recovery    NPAC SMS shall only allow a separate Notification Channel association to request notification recovery, when the Service Provider SOA Notification Channel tunable is TRUE. (previously NANC 383, Req 8)          RR6-186   Treatment of Multiple Associations when there is an Intersection of Association Function    NPAC SMS shall accept an association bind request, in the case of an intersection of the association functions of an existing SOA association, and abort any previous associations that use that same function. (previously NANC 383, Req 9)  6.12 Maintenance Window Timer Behavior          RR6-187   NPAC Maintenance Windows — Timer Update Tool    NPAC SMS shall support a “Knowledgeable-Internal-NPAC-Generation — Timer-Update-Tool” that would update applicable timer events based on an input parameter that defined the amount of time the timers should be extended. (previously NANC 385, Req 1)          RR6-188   NPAC Maintenance Windows — Timer Update Tool — Affected Timers    NPAC SMS shall use the “Knowledgeable-Internal-NPAC-Generation — Timer-Update-Tool” to update the following timers:       •   Initial Concurrence Window (New SPID and Old SPID, Short and Long)        •   Final Concurrence Window (New SPID and Old SPID, Short and Long)        •   Cancellation Initial Concurrence Window (New SPID and Old SPID, Short and Long)        •   Cancellation Final Concurrence Window (New SPID and Old SPID, Short and Long)    (previously NANC 385, Req 2)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     6-30    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            Security      7. Security  7.1 Overview  In addition to the general security requirements based on the user interface paradigm, there are requirements for the security on an OSI application-to-application interface (such as the one specified in Section 6, NPAC SMS Interfaces, for the SMS to SMS and SMS to SOA interfaces).  7.2 Identification  The NPAC will accept only authorized NPAC customers through interface connections, and among NPAC customers, the NPAC will make appropriate limitations on their actions (for example, letting only old or new Service Providers view a pending record). The NPAC will only accept authorized customer user IDs. However, the NPAC will make no distinction among an NPAC customer’s employees; the NPAC customer and their systems must control individual NPAC customer employee actions.  A user identification is a unique, auditable representation of the user’s identity within the system. The NPAC SMS requires all system users, both individuals and remote machines, to be uniquely identified to support individual accountability over the NPAC Administrative and NPAC SOA Low-tech Interfaces.          R7-l   Unique User Identification Codes — Individuals    NPAC SMS shall require unique user identification codes (userids) to identify all NPAC and Service Provider personnel.          R7-2   Assigned Userid Identification    NPAC SMS shall require NPAC and Service Provider personnel to identify themselves with their assigned userId before performing any actions.          R7-3   Current Active User List Maintenance    NPAC SMS shall maintain internally the identity of all NPAC and Service Provider personnel logged on to the NPAC SMS.          R7-4   User Invoked Processes    NPAC SMS shall have for every process running an associated userId of the invoking user (or the userId associated with the invoking process).                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-1    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            Security              R7-5.1   Userids, Unused — Disabling    NPAC SMS shall disable userids after a period of time during which the userId has not been used.          R7-5.2   Unused Userid Disable Period — Tunable Parameter    NPAC SMS shall provide an Unused Userid Disable Period tunable parameter which is defined as the number of days for which the userId has not been used.          R7-5.3   Unused Userid Disable Period — Tunable Parameter Modification    NPAC SMS shall allow the NPAC SMS administrator to modify the Unused Userid Disable Period tunable parameter time period.          R7-5.4   Unused Userid Disable Period — Tunable Parameter Default    NPAC SMS shall default the Unused Userid Disable Period tunable parameter to 60 days.          R7-6.1   Userids, Disabled — Reinstatement    NPAC SMS shall provide a complementary mechanism or procedure for the re-instatement disabled userids.          R7-6.2   Userids — Deletion    NPAC SMS shall provide a procedure for the deletion of userids.          R7-7   Userids — Temporary Disabling    NPAC SMS shall support the temporary disabling of userids.          R7-8   Userids, Disabled — Automatic Reactivation    NPAC SMS shall provide an option for automatic reactivation of disabled userids.          R7-9.1   Userids — One Active Login    NPAC SMS shall control and limit simultaneous active usage of the same userids by allowing only one active login.          R7-9.2   Second Login Attempt    NPAC SMS shall present the NPAC or Service Provider personnel with an option of disconnecting the first login and continuing the second login or terminating the second login, when a second login is entered.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-2    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security      7.3 Authentication  The identity of all NPAC SMS system users, both individuals and remote machines, must be verified or authenticated to enter the system, and to access restricted data or transactions over the NPAC Administrative and NPAC SOA Low-Tech Interfaces.          R7-10   User Authentication    NPAC SMS shall authenticate the identity of all NPAC and Service Provider users of the NPAC Administrative and NPAC SOA Low-tech Interfaces prior to their initially gaining access to NPAC SMS.          R7-12   Authentication Data Protection    NPAC SMS shall protect all internal storage of authentication data so that it can only be accessed by an NPAC Security Administrator user.  7.3.1 Password Requirements          R7-13   Passwords — Non-shared    NPAC SMS shall require a single password entry for each userId.          R7-14   Passwords — Userid Unique    NPAC SMS shall allow a user to define a password that is already associated with another userId.          R7-15   Passwords — One-Way Encrypted    NPAC SMS shall store passwords in a one-way encrypted form.          R7-16   Passwords, Encrypted — Privileged Users Access Control    NPAC SMS shall only allow access to encrypted passwords by authorized users.          R7-18   Passwords, Entry — Automatic Clear Text Suppression    NPAC SMS shall automatically suppress or fully blot out the clear-text representation of the password on the data entry device.          R7-19   Passwords — Network Transmission Clear Text Suppression    NPAC SMS shall ensure that passwords sent over public or external shared data networks are encrypted.          R7-20   Passwords — Non-Null    NPAC SMS shall require non-null passwords.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-3    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-21   Passwords — User-Changeable    NPAC SMS shall provide a mechanism to allow passwords to be user-changeable. This mechanism shall require re-authentication of the user identity.          R7-22   Passwords — Reset Capability    The NPAC SMS shall have a mechanism to reset passwords.          R7-23.1   Passwords — Aging Enforcement    NPAC SMS shall enforce password aging.          R7-23.2   Password Aging Default    NPAC SMS shall default the system password aging to 90 days.          R7-24.1   Passwords — Expiration Notification    NPAC SMS shall notify users a NPAC-specifiable period of time prior to their password expiring. The system supplied default shall be seven days.          R7-24.2   Passwords — Expiration Notification Default    NPAC SMS shall default the password expiration notification time period to seven days          R7-24.3   Passwords — Require User to Enter New Password    NPAC SMS shall require any user whose password has expired to enter a new password before allowing that user access to the system.          R7-25.1   Passwords — Non-Reusable    NPAC SMS shall ensure that a password can not be reused by the same individual for specifiable period of time.          R7-25.2   Password Reuse Default    NPAC SMS shall default the time period in which a password can not be reused to six months.          R7-26.1   Passwords — Minimum Structure Standard #1    Passwords shall contain a combination of at least six case-sensitive alphanumeric characters including at least one alphabetic and one numeric or punctuation character.          R7-26.2   Passwords — Associated Userid    NPAC SMS shall ensure that passwords do not contain the associated userId.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-4    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-27.1   Password Generator    NPAC SMS shall provide a password generator.          R7-27.2   Passwords, System Generated — Attack Resistant    NPAC SMS shall ensure that generated passwords are “reasonably” resistant to brute-force password guessing attacks.          R7-27.3   Passwords, System Generated — Random    NPAC SMS shall ensure that the generated sequence of passwords have the property of randomness.  7.4 Access Control  Access to the NPAC SMS and other resources will be limited to those users that have been authorized for that specific access right.  7.4 .1 System Access          R7-28.1   System Access — Individuals    NPAC SMS shall allow access to authorized individual users.          R7-28.2   System Access — Remote Machines    NPAC SMS shall allow access to authorized remote systems.          R7-29.1   System Access, User Information — Entry    NPAC SMS shall provide a facility for the initial entry of authorized user and associated authentication information.          R7-29.2   System Access, User Information — Modification    NPAC SMS shall provide a facility for the modification of authorized user and associated authentication information.          R7-31   System Access, Login — Trusted Communication    NPAC SMS’s login procedure shall be able to be reliably initiated by the user, i.e., a trusted communications path should exist between NPAC SMS and the user during the login procedure.          R7-32.1   System Access — Disconnect User    NPAC SMS shall disconnect end users after a period of non-use.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-5    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-32.2   Non-use Disconnect Tunable Parameter    NPAC SMS shall default the Non-use Disconnect tunable parameter to 60 minutes.          R7-33.1   System Access — User Authentication Failure    NPAC SMS shall exit and end the session if the user authentication procedure is incorrectly performed a specifiable number of times.          R7-33.2   Incorrect Login Exit Default    NPAC SMS shall default the number of allowable incorrect login attempts to 3.          R7-34   System Access, User Authentication Failure — Notification    NPAC SMS shall provide a mechanism to immediately notify the NPAC SMS system administrator when the threshold in R7-33.1 is exceeded.          R7-35.1   System Access — Login Process I/O Port Restart    NPAC SMS shall restart the login process when the threshold in R7-33.1 has been exceeded and a specified interval of time has passed.          R7-35.2   Login Process Restart Default    NPAC SMS shall default the time interval to restart the login process to 60 seconds.          R7-36   System Access, User Authentication Failure — Userid Non-Suspension    NPAC SMS shall not suspend the userId upon exceeding the threshold in R7-33.1.          R7-37   System Access, User Authentication Procedure — Entry    NPAC SMS shall perform the entire user authentication procedure even if the userId that was entered was not valid.          R7-38   System Access, User Authentication Procedure Entry — Error Feedback    NPAC SMS shall only provide error feedback of “invalid”.          R7-39   System Access, User Authentication Procedure Entry — Time Parameters    NPAC SMS shall provide a mechanism to restrict user login based on time-of-day, day-of-week, and calendar date.          R7-40.1   System Access, User Authentication Procedure Entry — Method    NPAC SMS shall provide a mechanism to restrict user login based on method of entry.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-6    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-40.2   System Access, User Authentication Procedure Entry — Location    NPAC SMS shall provide a mechanism to restrict user login based on user system location.          R7-41   System Access, User Authentication Procedure Entry — Dial-Up Limitations    NPAC SMS shall provide a mechanism to limit the users authorized to access the system via dial-up facilities.          R7-42.1   System Access — Network Basis    NPAC SMS shall provide a mechanism to limit system entry for privileged NPAC SMS users on a specifiable network access.          R7-42.2   System Access — Per-Port Basis    NPAC SMS shall provide a mechanism to limit system entry for privileged NPAC SMS users on a specifiable per-port basis.          R7-43.1   System Access, Network Authentication    NPAC SMS shall provide a strong authentication mechanism for network access.          R7-43.2   Internet Access    NPAC SMS shall use authentication of public encryption keys for users accessing the NPAC SMS over the Internet.          R7-43.3   Dial-in Access    NPAC SMS shall use smart cards to authenticate users accessing the NPAC SMS via dial-up.          R7-44   System Access — Secure Logoff Procedures    NPAC SMS shall provide a mechanism to end the session through secure logoff procedures.          R7-46   System Access, Unauthorized Use Message — Specifiable    NPAC SMS shall ensure that the message is NPAC SMS-specifiable to meet their own requirements, and any applicable laws.          R7-47.1   System Access, Unauthorized Use Message — Specifiable    NPAC SMS shall be able to display an advisory warning message of up to 20 lines in length prior to login.          R7-47.2   Advisory Warning Message Default    NPAC SMS shall default the pre-login advisory warning message to the following:            NOTICE: This is a private computer system.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-7    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security                Unauthorized access or use may lead to prosecution.          R7-48.1   System Access — User’s Last Successful Access    NPAC SMS shall display the date and time of the user’s last successful system access upon successful login.          R7-48.2   System Access — User’s Unsuccessful Access Attempts    NPAC SMS shall display the number of unsuccessful attempts by that userId to access the system, since the last successful access by that userId upon successful login.          R7-49.1   System Access, Security Administration — Authorize Users    NPAC SMS shall only allow the NPAC Security Administrator to authorize users.          R7-49.2   System Access, Security Administration — Revoke Users    NPAC SMS shall only allow the NPAC Security Administrator to revoke users.          R7-50.1   System Access, Security Administration -Adding Users    NPAC SMS shall provide security documentation that defines and describes procedures for adding users.          R7-50.2   System Access, Security Administration -Deleting Users    NPAC SMS shall provide security documentation that defines and describes procedures for deleting users.  7.4.2 Resource Access          R7-51   Data Access for Authorized Users    NPAC SMS shall allow only authorized users to access the data that is part of or controlled by the SMS system.          R7-52   Service Provider Data Protected    NPAC SMS shall protect service provider data from access by unauthorized users.          R7-53.1   Authorized User Access to Software    NPAC SMS shall ensure that only NPAC system administrators can access the software files that constitute the NPAC SMS.          R7-53.2   Authorized User Access to Transactions    NPAC SMS shall ensure that only authorized users can access the transactions that constitute the NPAC SMS.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-8    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            Security              R7-53.3   Authorized User Access to Data    NPAC SMS shall ensure that only authorized NPAC Administrative and NPAC SOA Low-tech Interfaces users can access the data generated by the transactions that constitutes the SMS.          R7-54.1   Access Control of Executable Software    NPAC SMS shall ensure that the executable and loadable software is access controlled for overwrite and update, as well as execution rights.          R7-55   Access Control of Resources    NPAC SMS shall ensure that control of access to resources is based on authenticated user identification.          R7-56   Use of Encryption    NPAC SMS shall ensure that userId and password is used as a primary access control for direct login and system ID is used for primary access control to the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.          R7-57   Resource Access to Users    NPAC SMS shall ensure that for software resources controlled by NPAC SMS, it must be possible to grant access rights to a single user or a group of users.          R7-58   Resource Access Denied to Users    NPAC SMS shall ensure that for software resources controlled by NPAC SMS, it must be possible to deny access rights to a single user or a group of users.          R7-60   Only NPAC Personnel Can Modify User Access    NPAC SMS shall allow only NPAC personnel to modify access rights to a resource.          R7-61   Removal of User Access Rights    NPAC SMS shall provide a mechanism to remove access rights to all software resources for a user or a group of users.  7.5 Data and System Integrity          R7-63   Identify Originator of System Resources    NPAC SMS shall identify the originator of any accessible system resources.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-9    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-64   Identify Originator of Information Received Across Communication Channels    NPAC SMS shall be able to identify the originator of any information received across communication channels.          R7-65.1   Monitor System Resources    NPAC SMS NMS shall use SNMP to monitor the system resources.          R7-65.2   Detect Error Conditions    NPAC SMS NMS shall use SNMP to detect error conditions.          R7-65.3   Detect Communication Errors    NPAC SMS NMS shall use SNMP to detect communication errors.          R7-65.4   Detect Link Outages    NPAC SMS NMS shall use SNMP to detect link outages.          R7-66.1   Rule Checking on Update    NPAC SMS shall ensure proper rule checking on data update.          R7-66.2   Handling of Duplicate Inputs    NPAC SMS shall handle duplicate/multiple inputs.          R7-66.3   Check Return Status    NPAC SMS shall check return status.          R7-66.4   Validate Inputs    NPAC SMS shall validate inputs for reasonable values.          R7-66.5   Transaction Serialization    NPAC SMS shall ensure proper serialization of update transactions.          R7-67   Database Integrity Checking    NPAC SMS shall include database integrity checking utilities for the NPAC SMS database.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-10    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security      7.6 Audit  7.6.1 Audit Log Generation          R7-68.1   Security Audit Log for After the Fact Investigation    NPAC SMS shall generate a security audit log that contains information sufficient for after the fact investigation of loss or impropriety for appropriate response, including pursuit of legal remedies.          R7-68.2   Security Audit Data Availability    NPAC SMS shall ensure that the security audit data is available on-line for a minimum of 90 days.          R7-68.3   Security Audit Data Archived    NPAC SMS shall archive the security audit data off-line for a minimum of two years.          R7-69   User Identification Retained    NPAC SMS shall ensure that the user-identification associated with any NPAC SMS request or activity is maintained, so that the initiating user can be traceable.          R7-70   Protection of Security Audit Log Access    NPAC SMS shall protect the security audit log from unauthorized access.          R7-71.2   NPAC Personnel Delete Security Audit Log    NPAC SMS shall ensure that only authorized NPAC personnel can archive and delete any or all of the security audit log(s) as part of the archival process.          R7-72   Security Audit Control Protected    NPAC SMS shall ensure that the security audit control mechanisms are protected from unauthorized access.  R7-73.1  Log Invalid User Authentication Attempts  NPAC SMS shall write a record to the security audit log for each invalid user authentication attempt.          R7-73.2   Log NPAC SMS End User Logins    NPAC SMS shall write a record to the security audit log for logins of NPAC users.          R7-73.3   Log NPAC Personnel Activities    NPAC SMS shall write a record to the security audit log for security-controlled activities of NPAC users.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-11    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-73.4   Log Unauthorized Data Access    NPAC SMS shall write a record to the security audit log for unauthorized data access attempts.          R7-73.5   Log Unauthorized Transaction Access    NPAC SMS shall write a record to the security audit log for unauthorized NPAC SMS transaction functionality access attempts.          R7-74   No Disable of Security Auditing    NPAC SMS shall ensure that NPAC audit capability cannot be disabled.          R7-75   Security Audit Record Contents     NPAC SMS shall ensure that for each recorded event, the audit log contains the following:    •   Date and time of the event      •   User identification including relevant connection information      •   Type of event      •   Name of resources accessed or function performed      •   Success or failure of the event            R7-76.1   Recorded Login Attempts    NPAC SMS shall record actual or attempted logins in audit logs after an NPAC-tunable parameter threshold of consecutive login failures.  7.6.2 Reporting and Intrusion Detection          R7-77.1   Exception Reports on Data Items    NPAC SMS shall provide post-collection audit analysis tools that can produce exception reports on items relating to system intrusions.          R7-77.2   Exception Reports on Users    NPAC SMS shall provide post-collection audit analysis tools that can produce exception reports on users relating to system intrusions.          R7-77.3   Exception Reports on Communication Failures    NPAC SMS shall provide post-collection audit analysis tools that can produce exception reports on communication failures relating to system intrusions.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-12    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-77.4   Summary Reports on Data Items    NPAC SMS shall provide post-collection audit analysis tools that can produce summary reports on data items relating to system intrusions.          R7-77.5   Summary Reports on Users    NPAC SMS shall provide post-collection audit analysis tools that can produce summary reports on users relating to system intrusions.          R7-77.6   Summary Reports on Communication Failures    NPAC SMS shall provide post-collection audit analysis tools that can produce summary reports on communication failures relating to system intrusions.          R7-77.7   Detailed Reports on Data Items    NPAC SMS shall provide post-collection audit analysis tools that can produce detailed reports on data items relating to system intrusions.          R7-77.8   Detailed Reports on Users    NPAC SMS shall provide post-collection audit analysis tools that can produce detailed reports on users relating to system intrusions.          R7-77.9   Detailed Reports on Communication Failures    NPAC SMS shall provide post-collection audit analysis tools that can produce detailed reports on communication failures relating to system intrusions.          R7-78   Review User Actions    NPAC SMS shall provide a capability to review a summary of the actions of any one or more users, including other NPAC users, based on individual user identity.          R7-79.1   Monitor Network Address    NPAC SMS shall provide tools for the NPAC to monitor the message passing activities to and from a specific network address as they occur.          R7-80.1   Real-time Security Monitor    NPAC SMS NMS shall provide a real-time mechanism to monitor the occurrence or accumulation of security auditable events. Where possible, NPAC SMS shall determine and execute the least disruptive action to terminate the event.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-13    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-80.2   Security Event Notification    NPAC SMS NMS shall notify the NPAC personnel immediately when security event thresholds are exceeded through the SNMP agent.  7.7 Continuity of Service          R7-81   System Made Unavailable by Service Provider    NPAC SMS shall ensure that no service provider action, either deliberate or accidental, should cause the system to be unavailable to other users.          R7-82   Detect Service Degrading Conditions    NPAC SMS shall report conditions that would degrade service below a pre-specified minimum, including high memory, CPU, network traffic, and disk space utilization.          R7-83   System Recovery After Failure    NPAC SMS shall provide procedures or mechanisms to allow recovery after a system failure without a security compromise.          R7-84.1   Software Backup Procedures    NPAC SMS shall have documented procedures for software backup.          R7-84.2   Data Backup Procedures    NPAC SMS shall have documented procedures for data backup.          R7-84.3   Software Restoration Procedures    NPAC SMS shall have documented procedures for software restoration.          R7-84.4   Data Restoration Procedures    NPAC SMS shall have documented procedures for data restoration.          R7-85.1   Software Version Number    NPAC SMS shall record the exact revision number of the latest software installed.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-14    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-85.2   Software Version Number    NPAC SMS shall display for viewing the exact revision number of the latest software via a Web bulletin board, and also through the NPA Administrative and NPAC SOA Low-tech Interfaces upon completion of the user login sequence.  7.8 Software Vendor          R7-86   Software Development Methodology    NPAC SMS shall be developed using a corporate policy governing the development of software.          R7-87   Bypass of Security    NPAC SMS shall not support any mode of entry into NPAC SMS for maintenance, support, or operations that would violate or bypass any security procedures.          R7-88   Documented Entry    NPAC SMS shall document any mode of entry into the SMS for maintenance, support, or operations.  7.9 OSI Security Environment  7.9.1 Threats  Attacks against the NPAC SMS may be perpetrated in order to achieve any of the following:     •   Denial of service to a customer by placing wrong translation information in the SMS      •   Denial of service to a customer by preventing a valid message from reaching the SMS      •   Disrupting a carrier’s operations by having numerous spurious calls (to users who are not clients of that carrier) directed to that carrier      •   Switching customers to various carriers without their consent      •   Disrupting the functioning of the NPAC SMS by swamping it with spurious messages    7.9.2 Security Services          R7-89   Authentication    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support Authentication (at association setup).                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-15    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006             Security              R7-90   Data Origin Authentication    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support data origin authentication for each incoming message.          R7-91.1   Detection of Message Replay    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of replay.          R7-91.2   Deletion of a Message    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of message deletion.          R7-91.3   Modification of a Message    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of message modification.          R7-91.4   Delay of a Message    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support detection of message delay.          R7-92   Non-repudiation of Origin    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall support non-repudiation of origin.          R7-93   Access Control    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall allow only authorized parties (i.e., carriers serving a given customer) to cause changes in the NPAC SMS database.  7.9.3 Security Mechanisms  This section outlines the requirements to specify security mechanisms.  7.9.3.1 Encryption          R7-94.1   Public Key Crypto System (PKCS)    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall use a public key crypto system (PKCS) to provide digital signatures. Since there is no requirement for confidentiality service there is no need for any additional encryption algorithms.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-16    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            Security              R7-94.2   Digital Signature Algorithms    NPAC SMS shall support one of the digital signature algorithms listed in the OIW Stable Implementation Agreement, Part 12, 1995.          R7-95   RSA Encryption Modulus Size    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall require the size of the modulus of each key to be at least 600 bits for RSA encryption.  7.9.3.2 Authentication          R7-96   Digital Signature Algorithm    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall apply the digital signature algorithm to the fields specified below without any separators between those fields or any other additional characters.     •   System ID      •   System type      •   User ID      •   Departure time      •   Sequence number            R7-97   Authenticator Contents    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall provide authentication consisting of the following:     •   The unique identity of the sender      •   The Generalized Time, corresponding to the issuance of the message      •   A sequence number      •   A key identifier      •   The digital signature of the sender’s identity, Generalized Time and sequence number listed above      •   Key list ID            R7-98   Authenticator in Access Control Field    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall convey the authenticator in the CMIP access control field.  7.9.3.3 Data Origin Authentication          R7-99.1   Subsequent Messages Contain Access Control Field    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that every subsequent CMIP message that contains the access control field carries the authenticator.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-17    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            Security              R7-99.2   Separate Counter for Association Sequence Numbers    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall verify that each party maintains a separate sequence number counter for each association it uses to send messages.          R7-99.3   Increment Sequence Numbers    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall verify that every time the authenticator is used the value of the sequence number will be incremented by one.  7.9.3.4 Integrity and Non-repudiation          R7-100.1   Security Field    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that all the notifications defined for the number portability application contain a security field.          R7-100.2   Security Field Syntax    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that the syntax of the security field used for the notification corresponds to the authenticator.          R7-102   Notifications in Confirmed Mode    NPAC SMS shall ensure that all the notifications are sent in the confirmed mode.  R7-103  MISSING in RFP  7.9.3.5 Access Control          R7-104   Responsible for Access Control    NPAC SMS shall be responsible for access control on the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface.          R7-105.2   Generalized Time — Valid Message Timeframe    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall ensure that external messages received have a generalized time in the access control information within the Departure Time Threshold tunable number of minutes of the NPAC SMS system clock.          RR7-3   Generalized Time — Departure Time Threshold Tunable Parameter    NPAC SMS shall provide a Departure Time Threshold tunable, which is defined as the maximum number of minutes of difference between the departure time of a message from the sending system, and the receipt of that message at the receiving system.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-18    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006            Security              RR7-4   Generalized Time — Departure Time Threshold Tunable Parameter Default    NPAC SMS shall default the Departure Time Threshold tunable parameter to five (5) minutes.  7.9.3.6 Audit Trail          R7-106   Log Contents    SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface shall keep a log of all of the following:     •   Incoming messages that result in the setup or termination of associations      •   All invalid messages (invalid signature, sequence number out of order, Generalized Time out of scope, sender not authorized for the implied request)      •   All incoming messages that may cause changes to the NPAC SMS database    7.9.3.7 Key Exchange          R7-107.1   Lists of Keys    NPAC SMS shall ensure that during a security key exchange, each party provide the other with a list of keys.          R7-107.2   Keys in Electronic Form    NPAC SMS shall provide the list of keys in a secure electronic form.          R7-107.3   Paper copy of MD5 Hashes of the Keys    The originator of the list of keys shall also provide the receiver with signed (in ink) paper copy of the MD5 hashes of the keys in the list.          R7-107.4   Key List Exchange    NPAC SMS shall support exchange of the list of keys in person or remotely.          R7-107.5   Remote Key List Exchange    NPAC SMS shall convey the lists via two different channels, diskette sent via certified mail, and a file sent via Email or FTP using encryption mechanisms if the keys are exchanged remotely.          R7-108.1   Remote Reception Acknowledgment    NPAC SMS shall support the Service Providers’ acknowledgment via 2 secure electronic forms, Email or FTP using encryption mechanisms.          R7-108.2   Acknowledgment Contents    NPAC SMS shall support the acknowledgment consisting of the MD5 hash of each one of the keys in the list.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-19    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006          Security              R7-108.3   Phone Confirmation    The recipient shall call the sender by phone for further confirmation and provide the sender with the MD5 hash of the whole list.          R7-109.1   Periodic Paper List of Public Keys NPAC Uses    NPAC SMS shall generate a paper list to each Service Provider of the MD5 hashes of all the public keys used by a Service Provider once a month.          R7-109.2   Acknowledgment of Paper List of Public Keys    NPAC SMS shall verify the identity of the Service Provider to whom the MD5 hashes of the public keys was sent.          R7-110.1   List Encryption Keys    NPAC SMS shall provide each Service Provider with a numbered list of encryption keys, numbered from 1 to 1000.          R7-110.3   List Encryption Keys    NPAC SMS shall ensure unique numbering of the keys.          R7-111.1   New Encryption Key Can Be Chosen    NPAC SMS shall allow a new encryption key to be chosen with every message that contains a key identifier.          R7-111.2   Keys Not Reused    NPAC SMS shall reject messages that use a key whose usage has stopped.          R7-111.3   Compromised Keys    NPAC SMS shall allow authorized NPAC SMS personnel to initiate a new key for messages.          R7-111.4   Key Change Once Per Year    NPAC SMS shall change the key used between the NPAC SMS and Service Provider after one year of usage.          R7-111.5   Key Size Increase Per Year    NPAC SMS shall allow NPAC SMS personnel to change key sizes for Service Providers as needed to ensure secure communications between the NPAC SMS and the Service Providers.          R7-111.6   Per Service Provider Application Basis    NPAC SMS shall expect new key initiation to be requested on a per Service Provider application basis.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-20    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Security              R7-111.7   NPAC Key Change Algorithm    NPAC SMS shall, upon determination that its key list has been compromised, change its own private key.          R7-111.8   Service Provider Key Marked Used/Invalid    NPAC SMS shall only mark an SP key as invalid or used when the service provider changes keys.          RR7-1   Load Key List    NPAC SMS shall be able to load a new key list in 15 minutes or less.          RN7-1   Authenticator Contents — Individual System Clock Accuracy    NPAC SMS shall be responsible for ensuring that the system clock is accurate to within two minutes of GMT.          RN7-2   Authenticator Contents — Zero Sequence Number    A sequence number equal to zero shall be required for association request and association response messages.          RR7-2   Modifying User Name    NPAC SMS shall provide a mechanism for authorized NPAC personnel to change a user name in the NPAC SMS.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     7-21    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Audit Administration      8. Audit Administration  2.1 Overview  An audit function will be necessary for troubleshooting a customer problem and also as a maintenance process to ensure data integrity across the entire LNP network. Audit will be concerned with the process of comparing the NPAC view of the LNP network with one or more of the Service Provider’s view of its network. In the case of “on demand” audits, audits may be initiated by any Service Provider who has reason to believe a problem may exist in another Service Provider’s network. Such audits are executed via queries to the appropriate Service Provider’s network, and corrected via downloads to those same networks. Requirements pertaining to these requirements are given in Sections 8.2 through 8.6.  With audits, two different scenarios are supported, one designed to “sync up” the information contained in the various Local SMS databases with the content of the NPAC SMS database, the other for the NPAC to perform random integrity checks of its own database.  The local SMS will be responsible for comparing database extracts written to an FTP site by the NPAC SMS with its own version of that same data. Note that the Service Provider network may contain several network nodes designated for local number portability and may also choose to keep its own copy in its respective SMS. In the second scenario, the NPAC SMS will select a random sample of active Subscription Versions from its own database, then compare those samples to the representation of that same data in the various Local SMS databases. Requirements pertaining to periodic audits are given in Section 8.7.          A8-1   Service Provider Audits Issued Immediately    NPAC SMS will process audit requests from service providers immediately.  8.2 Service Provider User Functionality          R8-1   Service Providers Audit Request — Single TN    DELETED          R8-2.1   Service Providers Audit Request — Range of TNs    DELETED          RR8-19   Service Provider Audit Request — Required Information    NPAC SMS shall require the following information as part of an audit request over the SOA to NPAC SMS interface or Service Provider Personnel:                        Release 3.3: © 1997 — 2006 NeuStar, Inc.     8-1    North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a       Freely distributable subject to the terms of the GNU GPL, see inside cover notice.   March 9, 2006           Audit Administration       •   Unique Audit Name       •   TN (either a single or range of TNs)    R8-3       Service Providers Specify Audit Scope  NPAC SMS shall allow Service Providers to specify the scope of an audit by specifying one or more of the following parameters:     •   Specific Service provider network or ALL Service Providers networks       •   Specify an activation Date/Time stamp range, i.e., only audit records activated between a specific time window       •   Full audit for all LNP attributes or a partial audit where the Service Provider can specify one or more of the following LNP attributes:             - LIDB data            - CLASS data            - LRN data            - CNAM data            - ISVM data            - WSMSC data (only Service Provider Local SMSs that support this attribute will be audited on this attribute)            Default: Full audit      8.3 NPAC User Functionality  R8-4         NPAC Personnel Audit Request — Single TN  DELETED   R8-5.1       NPAC Personnel Audit Request — Range of TNs  DELETED   RR8-20      NPAC Personnel Audit Request – Required Information  NPAC SMS shall require the following information as part of an audit request from NPAC Personnel:     •   Unique Audit Name       •   TN (either a single or a range of TNs)    R8-6.1      Specify an Immediate Audit Request  NPAC SMS shall provide NPAC personnel and users of the SOA to NPAC SMS interface the capability to issue an audit request to be executed immediately.  R8-9        NPAC Personnel Specify Audit Scope  NPAC SMS shall allow NPAC SMS Personnel to specify the scope of an audit by specifying one or more of the following parameters:     •   Specific Service Provider network or ALL Service Providers networks.       •   Specify an activation Date/Time stamp range, i.e., only audit records activated between a specific time window.                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration       •   Full audit for all LNP attributes or a partial audit where the Service Provider can specify one or more of the following LNP attributes:             - LIDB data            - CLASS data            - LRN data            - CNAM data            - ISVM data            - WSMSC data (only Service Provider Local SMSs that support this attribute will be audited on this attribute)            Default: Full audit    R8-10       NPAC Personnel Status of Audit Request  NPAC SMS shall allow NPAC personnel to obtain the final results of an audit request.  R8-11      Audit Progress Indicators  NPAC SMS shall indicate the progress of an audit as the percentage of records audited, when supplying the status of an audit request.  R8-12      NPAC Personnel Cancel of an Audit  NPAC SMS shall allow NPAC personnel to cancel an audit request.    8.4 System Functionality  R8-15.1   NPAC Personnel View of ALL Audit Requests  NPAC SMS shall allow NPAC Personnel to view ALL audit requests including requests issued by the Service Providers.  R8-15.2    Mechanized SOA Interface Obtain Audit Requests  NPAC SMS shall allow the mechanized SOA interface to obtain all audit requests issued from that particular mechanized SOA interface.  R8-15.3   Send Audit Results to Originating SOA  NPAC SMS shall send audit results to the originating SOA.  R8-16.1    Flow of Audit Execution  NPAC SMS shall send the query resulting from the audit request to the local Service Providers’ networks that are accepting Subscription Version data downloads for the given NPA-NXX via the NPAC SMS to Local SMS interface, as described in the NPAC SMS Interoperable Interface Specification.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration    R8-17.1   Compare NPAC SMS Subscription Versions to Service Provider Subscription Versions  NPAC SMS shall conduct a comparison of the Subscription Versions belonging to the Service Provider to its own Subscription Versions.  R8-17.2   Add TNs to Service Provider Subscription Versions  NPAC SMS shall, following the comparison of its own Subscription Versions to the Service Provider’s Subscription Versions, broadcast to the Service Provider an update for any TN that was NOT found in the Service Provider’s Subscription Version database, where the status of the Subscription Version contains a status of Active or Partial Failure.  R8-17.3   Modify Erroneous TNs  NPAC SMS shall, following the comparison of its own Subscription Versions to the Service Provider’s Subscription Versions, modify any TN found to be in error.  R8-17.4    Delete Discrepant TNs from Service Provider Subscription Versions  NPAC SMS shall, following the comparison of its own Subscription Versions to the Service Provider’s Subscription Versions, delete any discrepant TNs from the Service Provider’s Subscription Version database.  R8-19      Record Audit Results in an Audit Log  NPAC SMS shall record all audit results in an audit log.  RR8-4     Skip Subscription Versions with a Status of Sending  NPAC SMS shall, when processing the audit query results from a Local SMS, NOT perform comparisons or attempt to correct any Subscription Version within the requested range, which has a status of sending.  RR8-5       Report No Discrepancies Found in Audit Results for Skipped Subscription Versions  NPAC SMS shall consider a skipped Subscription Version as non-discrepant, and report no discrepancies found in the audit results.  RR8-21      Audit for Support of SV Type  NPAC SMS shall audit the SV Type attribute as part of a full audit scope, only when a Service Provider’s LSMS supports SV Type. (previously NANC 399, Req 17)  RR8-22      Audit for Support of Alternative SPID  NPAC SMS shall audit the Alternative SPID attribute as part of a full audit scope, only when a Service Provider’s LSMS supports Alternative SPID. (previously NANC 399, Req 18)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration              8.5 Audit Report Management  R8-20       Service Providers Audit Retrieval  NPAC SMS shall allow NPAC personnel and Service Provider personnel to retrieve an audit report for a specific audit request by specifying the unique audit name.  R8-21.1    Generate an Audit Report  NPAC SMS shall be capable of generating an audit report for each audit request that has been requested.  R8-21.2     Audit Report Contents  NPAC SMS shall generate an audit report containing the following information:     •   Audit name       •   Audit request parameters which identified the scope of the audit.       •   Date and Time of Audit.       •   Progress indication.       •   Service Provider network which contains database conflict.    A difference indicator which indicates one of the following:      •   Mismatch between the NPAC SMS and local SMS       •   Record missing in local SMS       •   An audit failure       •   No discrepancies found    R8-22      NPAC Personnel Generate and View an Audit Report  NPAC SMS shall allow NPAC and Service Provider personnel to generate and view an audit report on-line.  R8-23.1   NPAC Personnel View an In-progress Audit Report  NPAC SMS shall allow NPAC personnel to view an audit report while the audit is in progress so the current audit results can be viewed on-line up to this point.  R8-23.2    Service Providers View Results of Audits They Have Requested  NPAC SMS shall ensure that Service Providers can only view the results of those audits which they have requested.  R8-25      NPAC Personnel Specify Time Audit Results Retained  NPAC SMS shall allow NPAC personnel to specify the length of time audit results will be retained in the audit log.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration      8.6 Additional Requirements  RX8-1      Valid Audit Statuses  NPAC SMS shall support the following valid audit statuses:     •   In-progress       •   Canceled       •   Complete      8.7 Database Integrity Sampling  RR8-1      Random Sampling of Active Subscription Versions  NPAC SMS shall select a random sample of active Subscription Versions to query over the NPAC SMS to Local SMS interface to monitor NPAC SMS data integrity.  RR8-2.1    Data Integrity Sample Size — Tunable Parameter  NPAC SMS shall provide a Data Integrity Sample Size tunable parameter which is defined as the number of active Subscription Versions in the sample to monitor NPAC SMS data integrity.  RR8-2.2    Data Integrity Sample Size — Tunable Parameter Modification  NPAC SMS shall allow the NPAC SMS Administrator to modify the Data Integrity Sample Size tunable parameter.  RR8-2.3    Data Integrity Sample Size — Tunable Parameter Default  NPAC SMS shall default the Data Integrity Sample Size tunable parameter to 1000.  RR8-3.1   Data Integrity Frequency — Tunable Parameter  NPAC SMS shall provide a Data Integrity Frequency tunable parameter which is defined as the frequency in days that the data integrity sampling is performed.  RR8-3.2    Data Integrity Frequency — Tunable Parameter Modification  NPAC SMS shall allow the NPAC SMS Administrator to modify the Data Integrity Frequency tunable parameter.  RR8-3.3    Data Integrity Frequency — Tunable Parameter Default  NPAC SMS shall default the Data Integrity Frequency tunable parameter to seven days. The allowable range is between one and ninety (1-90) days.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration      8.8      Audit Processing in a Number Pool Environment  The Audit processing that is described in this section deals with all Subscription Versions in a Number Pooling environment, whether ported, pooled, or pooled ported numbers. Audit processing in a Number Pooling environment will use the information in the Service Provider’s profile (NPAC Customer LSMS EDR Indicator) to determine whether to send a query for a TN Range only (non-EDR Local SMSs), or a TN Range and Block (EDR Local SMSs).  RR8-6    Audit Processing for All Subscription Versions in a Number Pooling Environment  NPAC SMS shall process an audit request of an Active-Like Subscription Version(s), by performing the following steps: (Previously A-2)     •   Validate that the audit request is valid (existing FRS functionality).       •   Validate that the Block associated with the TN contained in the Subscription Version(s), exists in the NPAC SMS.       •   Send queries of TN Range, or TN Range with Activation Timestamp, to non-EDR Local SMSs that are accepting downloads for the given NPA-NXX.       •   Send queries of Block(s) AND TN Range or TN Range with Activation Timestamp, to EDR Local SMSs that are accepting downloads for the given NPA-NXX.       •   Process non-EDR Local SMS responses using same functionality as audits for LSPP and LISP Subscription Versions.       •   Process EDR Local SMS responses for the Block(s) by doing a comparison. If a discrepancy exists, the NPAC SMS data is considered “correct”, and a correction should be sent to the EDR Local SMS.       •   Process EDR Local SMS responses for Subscription Versions, as follows:         Ø    LSPP and LISP – Use existing audit functionality        Ø    POOL – “No Data” is correct response, SVs for other LNP Types need to be deleted.       •   Send audit results and notification of discrepancies, back to requesting SOA, only for the TN Range that was requested, even if other TNs were affected because of EDR Local SMS. The existing notification report will be unchanged, and will not contain block information. In cases were an EDR Local SMS erroneously contained a Number Pool Block, the NPAC SMS shall send a Number Pool Block delete to the Local SMS, but shall not report any discrepancy back to the requesting SOA for this Local SMS if this was the only discrepancy.       •   Suppress status change and attribute change notifications, for Subscription Versions, to the Block Holder SOA.       •   Send status change and attribute change notifications, for Blocks, to the Block Holder SOA when the SOA Origination is TRUE, and only when an audit correction causes the status and/or Failed SP List to be updated to different values.    RR8-7   Audit Discrepancy and Results Notifications for Pooled Number Subscription Versions to Requesting SOA  NPAC SMS shall, for audits of Subscription Versions with LNP Type of POOL, send notifications of discrepancies found and audit results to the requesting SOA. (Previously A-10)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration    RR8-8    Audit Discrepancy and Results Notifications for Pooled Number Subscription Versions for Audited TNs  NPAC SMS shall, for audits of Subscription Versions with LNP Type of POOL, only send back notifications to the requesting SOA, of the audited TNs, even if other TNs were modified. (Previously A-15)  RR8-9    Audit Status Attribute Value Change Notification Send for Pooled Number Blocks  NPAC SMS shall send status change notifications, for Blocks, to the Block Holder SOA when the SOA Origination is TRUE, only when an audit correction causes the status and/or Failed SP List to be updated to different values. (Previously A-35)  Note: Therefore, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Partial Failure, nothing is sent to the Block Holder SOA; however, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Active, a notification is sent to the Block Holder SOA. Likewise, if a Failed SP List gets updated, a notification is sent to the Block Holder SOA.  RR8-10   Audit Attribute Value Change Notification Send for Pooled Number Blocks  NPAC SMS shall send an attribute change notifications, for Blocks, to the Block Holder SOA when the SOA Origination is TRUE, only when an audit correction causes the status and/or Failed SP List to be updated to different values. (Previously A-36)  Note: Therefore, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Partial Failure, nothing is sent to the Block Holder SOA; however, if an audit causes a correction to be sent to a Service Provider, and the status goes from Partial Failure-to-Sending-to-Active, a notification is sent to the Block Holder SOA. Likewise, if a Failed SP List gets updated, a notification is sent to the Block Holder SOA.  RR8-11   Audit for Pooled Numbers and Block to EDR Local SMS  NPAC SMS shall send a query for Subscription Version(s), resulting from the TN Range or TN Range with Activation Timestamp audit request for Subscription Version(s) with LNP Type of POOL, and a query for the corresponding Block of the Subscription Version(s) with LNP Type of POOL, to an EDR Local SMS that is accepting Block and Subscription Version data download for the given NPA-NXX via the NPAC SMS to Local SMS Interface. (Previously A-40)  RR8-12   Audit Response – Ignore missing SVs for Pooled Ports at EDR Local SMS  NPAC SMS shall consider a query response of No Data, as a valid response from an EDR Local SMS, for a Subscription Version with LNP Type of POOL, and shall not include this as a discrepancy for the Subscription Version. (Previously A-50)  RR8-13   Audit Response — Delete erroneous SVs for Pooled Ports at EDR Local SMS  NPAC SMS shall consider a query response, which contains a Subscription Version, as a discrepancy from an EDR Local SMS, for a Subscription Version with LNP Type of POOL, by sending a Subscription Version Delete message for the Subscription Version. (Previously A-60)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Audit Administration    RR8-14   Audit Response – Compare NPAC SMS Block to Service Provider Block at EDR Local SMS  NPAC SMS shall conduct a comparison of the Block sent back in the audit response by the EDR Local SMS, to the Block stored in the NPAC SMS. (Previously A-80)  RR8-15   Audit Response – Block Missing from EDR Local SMS  NPAC SMS shall consider a query response of No Data related to a Block, for a Block that exists in the NPAC SMS, other than a status of Old, as a discrepant response from an EDR Local SMS, and shall send a Block Create/Activate message. (Previously A-90)  RR8-16   Audit Response – Block Discrepant at EDR Local SMS  NPAC SMS shall consider a query response with mis-matched data for a Block, as a discrepant response from an EDR Local SMS, and shall send a Block Modify message. (Previously A-100)  RR8-17   Audit Response – Extra Block at EDR Local SMS  NPAC SMS shall consider a query response of an existing Block, for a Block that has been de-pooled, as a discrepant response from an EDR Local SMS, when the latest version of the Block on the NPAC SMS contains a status of old, and shall send a Block Delete message. (Previously A-110)  RR8-18   Audit Processing – Skipping In-Progress Blocks  NPAC SMS shall skip the audit of a Block with a status of Sending, such that no discrepancies will be found for the Block. (Previously A-120)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    8-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability    9. Reports    9.1 Overview  The NPAC SMS must support scheduled and ad hoc report generation for selectable reports. The report generation service shall create output report files according to specified format definitions, and distribute reports to output devices as requested. A report distribution service is used to distribute report files to selected output devices. Authorized NPAC personnel can request reports from active database, history logs, error logs, traffic measurements, usage measurements, and performance reports.    9.2 User Functionality  R9-1 NPAC Personnel Report Selection  NPAC SMS shall allow NPAC personnel using the NPAC Administrative Interface to select the type of report required.  R9-2      NPAC Personnel Selection of Output Destination  NPAC SMS shall allow NPAC personnel using the NPAC Administrative Interface to select the predefined report output destination. Destinations are printer, file system, email, display or FAX.  R9-3      NPAC Personnel Re-print of Reports  NPAC SMS shall allow NPAC personnel using the NPAC Administrative Interface to re-print reports from previously saved report outputs.  R9-4      NPAC Personnel Create Customized Reports  NPAC SMS shall allow NPAC personnel to create customized reports through an ad-hoc facility.  R9-5     NPAC Personnel Define Scope and Filtering  NPAC SMS shall allow NPAC personnel to define scope and filtering for items to be included in the customized reports.  R9-6      Service Providers Receive Reports on Their Activities  NPAC SMS shall allow Service Provider personnel to receive reports on information related to their activities.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability    RX9-1      Service and Network Data Reports  NPAC SMS shall support the following service and network data reports for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface:       1.   NPAC Service Tunable Parameters Report        2.   List of Service Provider’s LRNs        3.   Open NPA-NXXs List    RX9-2      Service Provider Reports  NPAC SMS shall support the following Service Provider reports for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface:       1.   Service Provider Profile (Service Provider’s own data only)        2.   Service Provider’s Subscription List by Status (Service Provider’s own data only)    RX9-3      Subscription Data Reports  NPAC SMS shall support the following subscription data reports for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface:       1.   Subscriptions Listed by Status        2.   Subscriptions Listed by Service Provider by Status    RX9-4      System Reports  NPAC SMS shall support the following system reports for NPAC system administration personnel using the NPAC Administrative Interface:       1.   Overall CPU System Utilization        2.   Storage Utilization        3.   NPAC SMS Application Performance (SOA/LSMS Downloads per Second)        4.   NPAC SMS Application Performance (SOA/LSMS Subscription Activation Time)        5.   NPAC SMS-SOA Link Utilization        6.   NPAC SMS-LSMS Link Utilization        7.   NPAC SMS Application Performance (SOA/LSMS Response Time)        8.   NPAC SMS Application Performance (Interface Transaction Rate)        9.   NPAC SMS Application Performance (Provider SMS Database Sampling)    RX9-5      Security Reports  NPAC SMS shall support the following security reports for NPAC security administration personnel using the NPAC Administrative Interface:       1.   Access Privileges Matrix                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability         2.   Authorized Users List        3.   Security Log        4.   Invalid Access Attempts        5.   Encryption Keys List    RX9-6      Log File Reports  NPAC SMS shall support the following log file reports for NPAC personnel using the NPAC Administrative Interface:       1.   History Report        2.   Error Report        3.   Service Provider Notification Report        4.   Subscription Transaction Report        5.   Service Provider Administration Report        6.   Subscription Administration Report        7.   Cause Code Usage Log Report        8.   Resend Excluded Service Provider Report    RX9-7      Audit Reports  NPAC SMS shall support an Audit Results Report.  RX9-8      Regularly Scheduled Reports  NPAC SMS shall support the generation of regularly scheduled standard or ad hoc reports, to be provided at the request of a Service Provider.  RR9-1      Data Integrity Report – Database Sample Report  NPAC SMS shall generate an NPAC SMS data integrity report.    9.3 System Functionality  R9-9       Verification of User Privileges  NPAC SMS shall verify whether the user requesting the report has the proper viewing privileges for the selected data.  R9-10      Support of On-line File Transfer  NPAC SMS shall support on-line file transfer capabilities to transfer report files.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            R9-11   Transaction History Log    NPAC SMS shall maintain a History Log to keep track of transactions processed.          R9-12.1   Error Log — Transaction Errors    NPAC SMS shall maintain an Error Log to keep track of transaction errors.          R9-12.2   Error Log — Transmission Errors    NPAC SMS shall maintain an Error Log to keep track of transmission errors.          9.3.1   National Number Pooling Reports            RR9-7   Pooled Number Reports – OpGUI Report Generation    NPAC SMS shall support reports that list pooling information for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface. (Previously RR9-7 of Appendix F: Midwest Region Number Pooling)          RR9-2   Pooled Number Reports – Query functions    NPAC SMS shall support pooled number reports that allow queries on any combination of SPID, and TN Range, where the NPAC SMS returns all TNs that meet the selection criteria. (Previously R-10)          RR9-8   Pooled Number Reports – Block Holder Default Routing Report    NPAC SMS shall support a report that list the number pool range, the block holder, and the block holder default routing information for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface. (Previously RR9-8 of Appendix F: Midwest Region Number Pooling)          RR9-3   Pooled Number Reports – Block Holder Default Routing Report Data Elements    NPAC SMS shall support a report that lists the number pool range, the block holder, and the block holder default routing information, that contains the Block Holder ID, Service Provider Name, and the following data elements: (Previously R-25)  Block ID (primary sort) NPA-NXX-X (secondary sort) Effective Date LRN DPC (CLASS, CNAM, ISVM, LIDB and if supported WSMSC) SSN (CLASS, CNAM, ISVM, LIDB and if supported WSMSC)          RR9-4   Pooled Number Reports – Block Holder Default Routing Report Page Break    NPAC SMS shall page break the report listed in RR9-3, for every change in new Block Holder ID. (Previously R-26)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            RR9-9   Pooled Number Reports – Active-Like TNs in a NPA-NXX-X Report    NPAC SMS shall support a report that list all Active-Like numbers in a 1K block (NPA-NXX-X) for a block holder, for NPAC personnel using the NPAC Administrative Interface and Service Provider personnel using the NPAC SOA Low-tech Interface. (Previously R-30)          RR9-10   Pooled Number Reports – Active-Like TNs in a NPA-NXX-X Report Data Elements    NPAC SMS shall support a report that lists all Active-Like numbers in a 1K Block for a block holder, where the status is active/partial failure/old with a Failed SP List/disconnect pending, that contains the following data elements: (Previously R-40)  TN (primary sort) LNP Type Activation Start Time Stamp SP Name Status          RR9-11   Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report    NPAC SMS shall support a report, used for NPA-NXX-X and Block Creation, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where no active Subscription Version exists, or have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the Subscription Version is a Port-to-Original port, for NPAC personnel using the NPAC Administrative Interface. (Previously R-70)          RR9-12   Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report Data Elements    NPAC SMS shall support a report, used for NPA-NXX-X and Block Creation, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where no active Subscription Version exists, or have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the Subscription Version is a Port-to-Original port, that contains the following data elements: (Previously R-80)  TN Old Service Provider SPID New Service Provider SPID Due Date Status          RR9-13   Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report Sort Priority    NPAC SMS shall sort the report listed in RR9-12, in the following order: (Previously R-81)      New Service Provider SPID (primary sort)      TN (secondary sort)          RR9-14   Pooled Number Reports – Pending-Like No-Active and Pending-Like Port-to-Original Subscription Versions Report Page Break    NPAC SMS shall page break the report listed in RR9-12, for every change in SPID. (Previously R-82)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            RR9-15   Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report    NPAC SMS shall support a report, used for de-pooling, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the currently active Subscription Version is LNP Type of POOL, for NPAC personnel using the NPAC Administrative Interface. (Previously R-130)          RR9-16   Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report Data Elements    NPAC SMS shall support a report, used for de-pooling, that contains a list of all numbers in a 1K Block, that currently have a Subscription Version with a status of pending/conflict/cancel-pending/failure, and where the currently active Subscription Version is LNP Type of POOL, that contains the following data elements: (Previously R-140)  TN Old Service Provider SPID New Service Provider SPID Due Date Status          RR9-17   Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report Sort Priority    NPAC SMS shall sort the report listed in RR9-16, in the following order: (Previously R-141)       New Service Provider SPID (primary sort)       TN (secondary sort)          RR9-18   Pooled Number Reports – Pending-Like With Active POOL Subscription Versions Report Page Break    NPAC SMS shall page break the report listed in RR9-16, for every change in new SPID. (Previously R-142)  9.3.2 Cause Code Reports          RR9-19   Logging Cause code usage by SPID Reporting    NPAC SMS shall log the following information when an Old Service Provider places a Subscription Version into conflict: date, time, New SPID, Old SPID, cause code value. (previously NANC 375, Req 4)          RR9-20   Cause Code Usage Log Report via OpGUI    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Cause Code Usage Log Report on cause code usage log data for conflict situations. (previously NANC 375, Req 5)          RR9-21   Cause Code Usage Log Report Monthly Generation    NPAC SMS shall produce a monthly Cause Code Usage Log Report on cause code usage log data for conflict situations. (previously NANC 375, Req 6)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            RR9-22   Cause Code Usage Log Report Sort Criteria    NPAC SMS shall separate out the Cause Code Usage Log Report into two sections when generating the Cause Code Usage Log Report on cause code usage log data for conflict situations. The first section will use sort criteria of Old SPID (primary) and New SPID (secondary), the second section will reverse the order and use sort criteria of New SPID (primary) and Old SPID (secondary). (previously NANC 375, Req 7)          RR9-23   Cause Code Usage Log Report Selection Criteria    NPAC SMS shall use selection criteria of month and year when generating the Cause Code Usage Log Report on cause code usage log data for conflict situations. (previously NANC 375, Req 8)          RR9-24   Cause Code Usage Log Report Display    NPAC SMS shall display the Cause Code Usage Log Report data with headers as specified in the example below. A page break will separate out every change of SPID that is in the primary sort. (previously NANC 375, Req 9)  9.3.3 Resend Excluded Service Provider Report          RR9-25   Subscription Version Failed SP List – Excluded Service Provider Log Data Availability for the Excluded Service Provider Report    NPAC SMS shall allow the Excluded Service Provider log data to be available for the Excluded Service Provider Report. (previously NANC 227/254, Req 4)          RR9-26   Subscription Version Failed SP List – Resend Excluded Service Provider Report by Current SPID via OpGUI    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Current SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 5)          RR9-27   Subscription Version Failed SP List – Resend Excluded Service Provider Report by Current SPID Request    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and current SPID option (of either an individual SPID or all SPIDs) when generating the Resend Excluded Service Provider Report by Current SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 6)          RR9-28   Subscription Version Failed SP List – Resend Excluded Service Provider Report by Current SPID Request Sort Criteria    NPAC SMS shall use the following sort order when generating the Resend Excluded Service Provider Report by Current SPID on Excluded Service Provider log data:       1.   current SPID (ascending)                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability         2.   TN (ascending)        3.   date/time (earliest date/time to latest date/time)        4.   excluded SPID (ascending)        5.   SVID (ascending)    (previously NANC 227/254, Req 7)           RR9-29   Subscription Version Failed SP List –Resend Excluded Service Provider Report by Excluded SPID via OpGUI    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 8)          RR9-30   Subscription Version Failed SP List – Resend Excluded Service Provider Report by Excluded SPID Request    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and excluded SPID option (of either an individual SPID or all SPIDs) when generating the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 227/254, Req 9)          RR9-31   Subscription Version Failed SP List –Resend Excluded Service Provider Report by Excluded SPID Request Sort Criteria    NPAC SMS shall use the following sort order when generating the Excluded Service Provider Report on Excluded Service Provider log data:       1.   excluded SPID (ascending)        2.   TN/NPA-NXX-X (ascending)        3.   date/time (earliest date/time to latest date/time)        4.   currentSPID/Blockholder SPID (ascending)        5.   SVID/Number Pool Block -ID (ascending)    (previously NANC 227/254, Req 10)           RR9-32   Number Pool Block Failed SP List – Excluded Service Provider Log Data Availability for the Excluded Service Provider Report    NPAC SMS shall allow the Excluded Service Provider log data to be available for the Excluded Service Provider Report. (previously NANC 300, Req 4)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            RR9-33   Number Pool Block Failed SP List –Resend Excluded Service Provider Report by Current SPID/Blockholder SPID via OpGUI    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Current SPID/Blockholder SPID on Excluded Service Provider log data. (previously NANC 300, Req 5)          RR9-34   Number Pool Block Failed SP List – Resend Excluded Service Provider Report Request by Current SPID/Blockholder SPID    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and Current SPID/Blockholder SPID option (of either an individual SPID or all SPIDs in the failed SP list) when generating the Resend Excluded Service Provider Report by Current SPID/Blockholder SPID on Excluded Service Provider log data. (previously NANC 300, Req 6)          RR9-35   Number Pool Block Failed SP List – Resend Excluded Service Provider Report by Current SPID/Blockholder SPID Request Sort Criteria    NPAC SMS shall use the following sort order when generating the Resend Excluded Service Provider Report by Current SPID/Blockholder SPID on Excluded Service Provider log data:       1.   Current SPID/Blockholder SPID (ascending)        2.   TN/NPA-NXX-X (ascending)        3.   date/time (earliest date/time to latest date/time)        4.   excluded SPID (ascending)        5.   SVID/Number Pool Block -ID (ascending)    (previously NANC 300, Req 7)           RR9-36   Number Pool Block Failed SP List –Resend Excluded Service Provider Report by Excluded SPID via OpGUI    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to generate the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 300, Req 8)          RR9-37   Number Pool Block Failed SP List – Resend Excluded Service Provider Report by Excluded SPID Request    NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to specify time range and excluded SPID option (of either an individual SPID or all SPIDs) when generating the Resend Excluded Service Provider Report by Excluded SPID on Excluded Service Provider log data. (previously NANC 300, Req 9)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            RR9-38   Number Pool Block Failed SP List –Resend Excluded Service Provider Report by Excluded SPID Request Sort Criteria    NPAC SMS shall use the following sort order when generating the Excluded Service Provider Report on Excluded Service Provider log data:       1.   excluded SPID (ascending)        2.   TN/NPA-NXX-X (ascending)        3.   date/time (earliest date/time to latest date/time)        4.   Current SPID/Blockholder SPID (ascending)        5.   SVID/Number Pool Block -ID (ascending)    (previously NANC 300, Req 10)   Note: The TN and SVID attributes were added to requirements 7 & 10 in this change order because of the corresponding change order (NANC 227/254) for SVs in Release 3.3.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    9-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006            Performance and Reliability            10.   Performance and Reliability    This section defines the reliability, availability, performance and capacity requirements for the NPAC SMS. The NPAC SMS will be designed for high reliability, including fault tolerance and data integrity features, symmetrical multi-processing capability, and allow for economical and efficient system expansion.  Note that throughout this section, “downtime” refers to the unavailability of the NPAC service. This is to be distinguished from cases where users can still switch to a backup machine.  The following are the availability, reliability, performance and capacity requirements for the NPAC SMS system.          10.1   Availability and Reliability    R10-1  System Availability  NPAC SMS shall be available 24 hours a day, 7 days a week with the exception of scheduled downtime and unscheduled downtime within the time frame defined in R10-3 and R10-5.          R10-2   System Reliability    NPAC SMS shall be 99.9 percent reliable. This applies to functionality and data integrity.          R10-3   Unscheduled Downtime    NPAC SMS shall have unscheduled downtime per year less than or equal to 9 hours.          R10-4   Mean Time to Repair for Unscheduled Downtime    NPAC SMS shall support a mean time to repair of less than or equal to 1 hour, for unscheduled downtime.          R10-5   Scheduled Downtime    NPAC SMS shall have NPAC initiated, scheduled downtime of less than or equal to 24 hours per year.          AR10-1   Scheduled Downtime    NPAC initiated downtime as defined in R10-5 does not include downtime needed for software release updates initiated by or collectively agreed to by the Service Providers.          R10-6.1   Communication Link Monitoring    NPAC shall be capable of monitoring the status of all of its communication links.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    10-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            R10-6.2   Detecting Communication Link Failures    NPAC shall be capable of detecting and reporting all communication link failures.          R10-7   Detecting Single Bit Data Transmission Errors    NPAC SMS shall be capable of detecting and correcting single bit errors during data transmission between hardware components (both internal and external).          R10-8   Continue Transaction Processing After Downtime    NPAC SMS shall complete processing of all sending transactions at the time of system failure when the NPAC SMS resumes processing.          R10-9.1   Self Checking Logic    NPAC SMS shall support functional components with on board automatic self checking logic for immediate fault locating.          R10-9.2   Continuous Hardware Checking    NPAC SMS shall support continuous hardware checking without any performance penalty or service degradation.          R10-9.3   Duplexing of Hardware    NPAC SMS shall support duplexing of all major hardware components for continuous operation in the event of a system hardware failure.          R10-9.4   Transparent Hardware Fault Tolerance    NPAC SMS shall support hardware fault tolerance that is transparent to the Service Providers.          R10-10.1   Service Provider Notification of System Unavailability    NPAC SMS shall notify Service Providers of the system unavailability via both the NPAC SMS to Local SMS interface and the SOA to NPAC SMS interface if the system becomes unavailable for normal operations due to any reason, including both scheduled and unscheduled maintenance.          R10-10.2   System Availability Notification Method    NPAC SMS shall notify Service Providers via their contact numbers if electronic communication is not possible.          R10-10.3   System Availability Notification Contents    NPAC SMS shall include the following information in the notification:     •   The reason for the downtime       •   When the down time will start       •   When the down time will stop                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    10-12  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability       •   An NPAC contact number            R10-11   Updates Highest Priority    NPAC SMS shall ensure the capability of receiving, processing and broadcasting updates will be given the highest priority during any maintenance, if resources allow only partial functionality.          R10-12.1   Tolerance to Communication Link Outages    NPAC SMS shall provide tolerance to communication link outages and offer alternate routing for such outages.          R10-12.2   Alternate routing    NPAC SMS shall offer alternate routing during communication link outages.          R10-13.1   Switch to Backup or Disaster Recovery Machine    NPAC SMS shall, in cases where Service Providers have been switched to a backup or disaster recovery machine, adhere to a maximum time to repair of 4 hours for the primary machine.          R10-13.2   Time to Switch Machines    NPAC SMS shall ensure that the time to switch the Service Providers to another machine and provide full functionality must not exceed the mean time to repair.          R10-13.3   Total Disaster Recovery    NPAC SMS shall restore the capability of receiving, processing and broadcasting updates within 24 hours in the event of a disaster that limits the ability of both the NPAC and NPAC SMS to function.          R10-13.4   Full Functionality Restored    NPAC SMS shall restore full functionality within 48 hours, in the event of a disaster that limits both the NPAC and NPAC SMS ability to function.          R10-14   Reports on Reliability    NPAC shall provide reliability reports documenting the following:     •   Schedule down time       •   Unscheduled down time       •   Mean time to repair       •   System availability on a monthly basis to the Service Provider                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    10-13  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability      10.2       Capacity and Performance          R10-16   Capacity    NPAC SMS will have the capacity to support a user group in the NPAC sized for the region they service.          R10-18   History File Data Storage    NPAC SMS shall ensure that the data storage of the History file must keep track of all transactions made for a tunable parameter period of time (default of one year).          R10-19   Broadcast Update Response Time    NPAC SMS shall ensure that from the time an activation notice, modification or deletion request is received from a Service Provider until the time the broadcast of the update is started to all Service Provider local SMS will be less than 60 seconds.          R10-20   Request/Transaction Response Time    NPAC SMS, under normal operating conditions, shall ensure that the response time from when a request or transaction is received in the system to the time an acknowledgment is returned will be less than 3 seconds for 95% of all transactions. This does not include the transmission time across the interface to the Service Providers’ SOA or Local SMS.          R10-21   Future System Growth    NPAC SMS shall be expandable to handle future growth due to circumstances described as follows:     •   Added areas of portability       •   Added Service Providers      10.3 Requirements in RFP Not Given a Unique ID          RN10-2   Return to the Primary Machine SOA Notification    NPAC SMS shall send an electronic notification to the Service Provider’s SOA indicating the time the NPAC will switch them back to the primary machine.          RN10-3   Return to the Primary Machine Local SMS Notification    NPAC SMS shall send an electronic notification to the Service Provider’s Local SMS indicating the time the NPAC will switch them back to the primary machine.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    10-14  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            RN10-4   Database Sync After Return to the Primary Machine    NPAC SMS shall sync up the database in its primary SMS with any updates sent to the backup or disaster recovery machine during the downtime.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    10-15  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability    1.1       Billing          A11-2   Accounting Measurements Will Not Degrade the Basic System Performance    The resource accounting measurements will not cause degradation in the performance of the basic functions of the NPAC.     11.1       User Functionality          R11-1   Toggling the Generation of Usage Measurements    NPAC SMS shall allow the NPAC administrator to turn on and off the recording of Service Provider usage statistics for the service elements.     11.2       System Functionality          R11-2   Generating Usage Measurements for NPAC Resources    NPAC SMS shall measure and record the usage of NPAC resources on a per Service Provider basis.          R11-3   Generating Usage Measurements for Allocated Connections    NPAC SMS shall generate usage measurements for allocated connections for each Service Provider.          R11-4   Generating Usage Measurements for Allocated Mass Storage    NPAC SMS shall generate usage measurements for the allocated mass storage (number of records stored) for each Service Provider.          R11-5   Generating Usage Measurements for the Number of Messages Processed by type    NPAC SMS shall measure the number of messages processed by type for each Service Provider.          R11-6   Generating Usage Measurements for the Number of Messages Downloaded    NPAC SMS shall measure the number of messages downloaded to each Service Provider.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    11-1  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Performance and Reliability            R11-8   Generating Detailed Usage Measurement Reports    NPAC shall produce detailed NPAC usage reports for the contracting entity.          R11-9   Billing Report Types    NPAC SMS shall be capable of creating the following billing reports:     •   Login Session Per Service Provider       •   Allocated Mass Storage       •   Messages Processed by type (to include download data and data resent by request)       •   Audits Requested and Processed       •   Requested Report Generation       •   Service Establishment (to include Service Provider establishment, user login ID addition to the NPAC SMS, and mechanized Interface Activation)            R11-10   Full Billing Report    The NPAC SMS shall be capable of creating a full billing report, with all of the report types in R11-9 included.          R11-11   Billing Report Creation by NPAC Personnel    NPAC SMS shall allow NPAC personnel to create billing reports for all Service Provider usage. For all report types in R11-9 and R11-10, the NPAC personnel will be able to specify whether the report is an aggregation/summary of stored data or a detailed report containing every item stored for the report type.          R11-12   Billing Report Creation by Service Provider    NPAC SMS shall allow Service Providers to gather billing report data on only their NPAC SMS usage. Service Providers will not be able to create reports on any other Service Provider’s usage. For all report types in R11-9 and R11-10, the NPAC SMS shall create an aggregation/summary of stored data for the report type.          R11-13   NPAC Personnel Billing Report Destination    NPAC SMS shall allow NPAC personnel to determine the output destination of the billing report. The destinations will include: on-line (on screen), printer, file, or FAX. The default selection is on-line.          R11-14   Service Provider Billing Report Destination    NPAC SMS shall allow Service Provider users to determine the output destination of the billing report. The destinations will include: on-line (on screen) or file. The default selection is on-line.          R11-15   NPAC Personnel Only Can Access Billing System    The NPAC billing system shall be accessible only to NPAC personnel.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    11-2  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flow Diagrams    Appendix A. Business Process Flow Diagrams  This appendix contains pictorial representations of the business process flows discussed in Section 2, Business Process Flows, on page 2-1.  [Graphic Omitted: NPAC Business Process Flows Legend]  [Graphic Omitted: NPAC SMS Provision Service Process]  [Graphic Omitted: NPAC SMS Subscription Version Creation Process]  [Graphic Omitted: NPAC SMS Activate and Data Download Process]  [Graphic Omitted: NPAC SMS Disconnect Process]                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    A-1  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Business Process Flow Diagrams    [Graphic Omitted: NPAC SMS Repair Process]  [Graphic Omitted: Conflict Process]  [Graphic Omitted: NPAC SMS Disaster Recovery Process]  [Graphic Omitted: Cancellation Process]  [Graphic Omitted: Audit Process]  [Graphic Omitted: Report Process]                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    A-2  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Glossary    Appendix B. Glossary  This glossary provides a comprehensive list of definitions and acronyms that apply to NPAC SMS.                Active-like SVs    SVs that contain a status of active, sending, partial failure, old with a Failed SP List, or disconnect pending.           Block    A range of 1000 pooled TNs within the NPA-NXX, beginning with a station of n000, and ending with n999, where n is a value between 0 and 9.           Block Holder    The recipient Service Provider of a 1K Block from the code holder. Also defined as the NPA-NXX-X holder in the LERG Routing Guide.           Cascading Delete    A delete of an NPA-NXX-X where the NPAC sends deletes of Pooled SV data to non-EDR LSMSs, and sends deletes of Block data to EDR LSMSs. Once all LSMSs have successfully deleted the Pooled data, the status of SVs and the Block is Old, and both Failed SP Lists are empty, the NPA-NXX-X is deleted.           Central Time (standard/daylight)    This is the time in the central time zone, that includes daylight savings time. It changes twice a year based on standard time and daylight savings time. The NPAC SMS runs on hardware that uses this time.           CLASS    Custom Local Area Signaling Services. Premium local service features, such as call forwarding or automatic callback.           CMIP    Common Management Information Protocol           CMISE    Common Management Information Service Element           CNAM    Caller Id with Name           Code Holder    The code holder is the LERG Routing Guide assignee of the NPA-NXX.           Contaminated Number    An unavailable number (e.g., working), within a 1K Block, at the time the 1K Block is donated to the Pooling Administrator.           De-Pool    Return of a 1K pooled block to the Number Administrator. Also referred to as “un-allocation of the block”, or “reclamation” (INC definition).           Default Routing Restoration    Reinstatement of the default routing for the TN as defined in the applicable block information, in order to provide vacant number treatment.           DPC    Destination Point Code           EDR (Efficient Data Representation)    The ability to represent 1000 TNs as a range.           EDR within the NPAC    A storage mechanism where a 1K range of TNs is represented, stored and communicated as a Range entity.           Effective Date    The date that is considered to be the “ownership switchover” date for the 1K Block from the Code Holder (NPA-NXX owning SP) to the Block Holder ( NPA-NXX-X owning SP). This is the date published in the LERG Routing Guide, and is also used by the Pooling Administrator and the NPAC.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    B-1  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Glossary                  FR    Frame Relay           GDMO    Guideline for Definition of Managed Objects           GMT    Greenwich Mean Time           GTT    Global Title Translation           ICC    Illinois Commerce Commission           ISO    International Organization of Standardization           ISVM    Inter-Switch Voice Mail           LERG    Refers to the TelcordiaTM LERGTM Routing Guide           LIDB    Line Information Database           LNP    Local Number Portability           Local Time (in the GUI)    The time zone of the local user. Most time representations in the NPAC OP GUI are represented in the user’s local time zone based on the PC’s clock being set to the correct time. The time zone label is included in time display in the GUI.                EST for Eastern Time Zone                CST for Central Time Zone                MST for Mountain Time Zone                PST for Pacific Time Zone           LRN    Location Routing Number. A routing number in the same form as a TN used to identify the TN’s serving switch when the TN is a ported number.           LSMS    Local Service Management System           LISP    Local Intra-Service Provider Portability. Movement of end-user TN from one switch to another, but within the same Service Provider’s Network.           LSPP    Local Service Provider Portability. Movement of end user TN from one Service Provider to another Service Provider.           MAC    Media Access Control           MD5    Message Digest (Version 5)           NANP    North American Numbering Plan. A 10-digit numbering scheme used in North America to uniquely identify a directory number.           NPA    An NPA code is the first three digits of the 10-digit destination number for all inter-NPA calls within the North America Numbering Plan Area.           NPA-NXX-X    A range of 1000 pooled TNs within the NPA-NXX, beginning with a station of n000, and ending with n999, where n is a value between 0 and 9.           NPAC Customer    Any customer of the NPAC SMS.           NPAC SMS    Number Portability Administration Center and Service Management System                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    B-2  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Glossary                  NSAP    Network Layer Service Access Point           Number Pooling Block Holder Information    Data in the NPAC SMS that contains the first 7-digits of a 1K range of TNs, default routing for a block of TNs, and the activation timestamp of the TNs within the 1K range.           Number Pooling NPA-NXX-X Holder Information    Data in the NPAC SMS that contains the first 7-digits of a range of TNs, the block holder (service provider), and the effective date of the block. According to the NPAC definition, this is considered Network data.           NXX    A code normally used as a central office code. It may also be used as an NPA code or special NPA code.           OCN    Operating Company Number           OSI    Open Systems Interconnect           Pending-like SVs    SVs that contain a status of pending, conflict, cancel-pending, or failed.           PKCS    Public Key Crypto System           Port on Demand    Porting of a single TN or range of TN’s from the code holder to the block holder at a time desired by the block holder that is on, or after the effective date of the pool. This is NOT supported by the National Number Pooling architecture.           Ported TN    A TN ported to a switch that is not the NANP-assigned switch.           PPP    Point-To-Point Protocol           Pre-Port    Porting of an entire block of TN’s from the code holder to the block holder on, or after, the effective date of the pool. This is supported by the National Number Pooling architecture.           PSAP    Presentation Layer Service Access Point           Roll-Up Activity    The consolidation/closure of a broadcast event in the NPAC, and feedback (responses, non-responses) from each Service Provider, such that the status and failed-list for an SV or NPB will be updated.           RFP    Request for Proposal           RSA    A popular encryption algorithm whose name is derived from the initials of its inventors: Rivest, Shamir, and Adelman.           Schedule/Re-Schedule of Block Create Event    A process within the NPAC SMS that allows NPAC Personnel to create a Scheduled Event in the NPAC SMS, for a Block Create. The Event can be immediately kicked-off, or scheduled for a future date (pending validation edits in both of these cases).           SCP    Service Control Point           SIC-SMURF    Selection Input Criteria SPID Migration Update Request Files. Files created by the NPAC SMS and used by NPAC and Service Providers to update their databases during a SPID Migration Update.           SMS    Service Management System           Snapback    Notification for TN reassignment.           SOA    Service Order Activation           SP    Service Provider. Generally refers to a facilities-based user of the NPAC SMS.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    B-3  North American Numbering Council (NANC)        Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Glossary                  SSAP    Session Layer Service Access Point           SSN    Subsystem Number           TN    Telephone Number           TSAP    Transport Layer Service Access Point           Unique Alarmable Error Message (Code)    An individual error message in the NPAC SMS that is only used by the NPAC for the individual Number Pooling requirement where the error message is listed. Alarming of the error message is configurable (i.e., it can either be turned ON or turned OFF).           Vacant Number    A non-working number.           Vacant Number Treatment    A recorded announcement played to the calling party, when the NPA-NXX of the TN they have dialed is valid, but the 10-digit TN is not a working number.           Version    Time-sensitive or status-sensitive instance of a subscription.           WSMSC    Wireless Short Message Service Center                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    B-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             System Tunables    Appendix C. System Tunables  This appendix provides a comprehensive list of tunables identified throughout the FRS and their default values.  SUBSCRIPTION TUNABLES                          Default            Tunable Name   Value   Units   Valid Range         Long Initial    9     business    1-72   Concurrence Window        hours                       The hours subsequent to the time the subscription version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider port and at least one of the Service Providers are using “Long” timers. (T1 timer)                   Long Final Concurrence    9     business    1-72   Window        hours                       The number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider port and at least one of the Service Providers are using “Long” timers. (T2 timer)                   Short Initial    1     business    1-72   Concurrence Window        hours                       The hours subsequent to the time the subscription version was initially created by which both Service Providers are expected to authorize transfer of service if this is an Inter-Service Provider port and both of the Service Providers are using “Short” timers. (T1 timer)                   Short Final Concurrence    1     business    1-72   Window        hours                       The number of hours after the concurrence request is sent by the NPAC SMS by which time both Service Providers are expected to authorize transfer of subscription service for an Inter-Service Provider port and both of the Service Providers are using “Short” timers. (T2 timer)                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    SUBSCRIPTION TUNABLES                              Default            Tunable Name   Value   Units   Valid Range         Conflict Expiration    30     calendar    1-180   Window            days                           The length of time conflict subscriptions will remain in the conflict state before cancellation.                       Maximum Subscription    50     records    10-150   Query                                       The maximum number of subscription versions returned by a query to the NPAC.                       Pending Subscription    90     calendar    1-180   Retention            days                           The length of time pending subscriptions will remain in the pending state before cancellation.                       Conflict Restriction    17:00     HH:MM    00:00-24:00   Window    UTC                  daylight                  savings                  time                                      18:00                  UTC                  standard                  time                                 The time on the business day prior to the New Service Provider due date that a Subscription version is no longer allowed to be set to conflict by the Old Service Provider provided that the Create Subscription Version Final Concurrence Window (T2) timer has expired. The Conflict Restriction Window does not apply for short timers.                       Long Conflict Resolution    6       business    1-72   New Service Provider            hours       Restriction                                       The number of business hours after the subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the new Service Provider using long timers.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    SUBSCRIPTION TUNABLES                          Default            Tunable Name   Value   Units   Valid Range         Short Conflict    6     Business    1-72   Resolution New Service        hours       Provider Restriction                               The number of business hours after the subscription version is put into conflict that the NPAC SMS will prevent it from being removed from conflict by the new Service Provider using short timers.                   Long Cancellation-    9     Business    1-72   Initial Concurrence        hours       Window                               The numbers of hours after the version is set to cancel pending by which both Service Providers using long timers are expected to acknowledge the pending cancellation.                   Short Cancellation-    9     Business    1-72   Initial Concurrence        hours       Window                               The numbers of hours after the version is set to cancel pending by which both Service Providers using short timers are expected to acknowledge the pending cancellation.                   Long Cancellation-    9     business    1-72   Final Concurrence        hours       Window                               The number of hours after the second cancel pending notification is sent by which both Service Providers using long timers are expected to acknowledge the pending cancellation.                   Short Cancellation-    9     business    1-72   Final Concurrence        hours       Window                               The number of hours after the second cancel pending notification is sent by which both Service Providers using short timers are expected to acknowledge the pending cancellation.                   Old Subscription    18     calendar    1-36   Retention        months                       The length of time old subscriptions will be retained.                   Cancel-Pending    90     calendar    1-360   Subscription Retention        days                               Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    SUBSCRIPTION TUNABLES                          Default            Tunable Name   Value   Units   Valid Range         The length of time canceled subscriptions, with last status of pending, will be retained.                   Cancel-Conflict    30     calendar    1-360   Subscription Retention        days                       The length of time canceled subscriptions, with last status of conflict, will be retained.                   Short Business Day    12     calendar    1-24   Duration        hours                       The number of hours from the tunable business day start time for short business days.                   Long Business Day    12     calendar    1-24   Duration        hours                       The number of hours from the tunable business day start time for long business days.                   Short Business Day Start    13:00    hh:mm    00:00 — 24:00   Time    UTC                daylight                savings                time                                14:00                UTC                standard                time                           The start of the business day for short business days. The value is specified by the contracting region.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    SUBSCRIPTION TUNABLES                          Default            Tunable Name   Value   Units   Valid Range         Long Business Day Start    9:00AM    hh:mm    00:00 — 24:00   Time    Local                Time                (in the                predomi                nant                time                zone)                within                each                region,                stored                in UTC                           The start of the business day for long business days in that region. The value is specified by the contracting region                   Short Business Days    Monday    Days    Monday –        - Friday        Sunday                   The business days available for Service Providers using short business days.                   Long Business Days    Sunday    Days    –Sunday –        - Saturday        Saturday                   The business days available for Service Providers using long business days.                   Regional NPAC NPA-    TRUE        True/False   NXX Live Indicator                               Tunable that indicates whether or not the NPA-NXX Live TimeStamp functionality will be supported by the NPAC SMS for a particular NPAC Region.                   Regional Automatic    TRUE        True/False   Conflict Cause Code                               Tunable that indicates whether or not the Automatic Conflict Cause Code functionality will be supported by the NPAC SMS for a particular NPAC Region.                   Regional Prevent    TRUE        True/False   Conflict Resolution               50/51 Tunable                                       Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    SUBSCRIPTION TUNABLES                          Default           Tunable Name   Value   Units   Valid Range         Tunable that indicates whether or not the prevention of conflict resolution for cause code 50 or 51 by the New Service Provider is supported by the NPAC SMS for a particular NPAC Region.     Table C- 1 — Subscription Tunables  COMMUNCIATIONS TUNABLES                          Default       Valid   Tunable Name   Value   Units   Range         Subscription Activation    3     attempts    1-10   Retry Attempts                               The number of times a new subscription version will be sent to a Local SMS which has not acknowledged receipt of the activation request.                   Subscription Activation    2     minutes    1-60   Retry Interval                               The delay between sending new Subscription Versions to a Local SMS that has not acknowledged receipt of the activation request.                   Subscription    3     attempts    1-10   Modification Retry               Attempts                               The number of times a modified active subscription version will be sent to a Local SMS which has not acknowledged receipt of the modification request.                   Subscription    2     minutes    1-60   Modification Retry               Interval                               The delay between sending modified active subscription versions to a Local SMS that has not acknowledged receipt of the modification request.                   Subscription Disconnect    3     attempts    1-10   Retry Attempts                                       Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    COMMUNCIATIONS TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         The number of times the NPAC SMS will resend a subscription disconnect message to an unresponsive Local SMS.                   Subscription Disconnect    2     minutes    1-60   Retry Interval                               The amount of time that shall elapse between subscription disconnect retries.                   Local SMS Retry    3     attempts    1-10   Attempts                               The default number of times the NPAC SMS will resend a message to an unresponsive Local SMS.                   Local SMS Retry    2     minutes    1-60   Interval                               The default delay between sending messages to an unresponsive Local SMS.                   SOA Retry Attempts    3     attempts    1-10                   The default number of times the NPAC SMS will resend a message to an unresponsive SOA.                   SOA Retry Interval    2     minutes    1-60                   The default delay between sending messages to an unresponsive SOA.                   Failed Login Attempts    3     attempts    0-10                   The number of allowable incorrect logon attempts                   Failed Login Shutdown    60     seconds    0-300   Period                               The amount of time the NPAC SMS will wait to restart the logon process after a user has exceeded the Failed_Login_Attempts tunable.                   Unused User Id Disable Period   60     days    1-360                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    COMMUNCIATIONS TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         The number of days for which a userId has not been used before the NPAC SMS disables that userId.                   Password Age Limit    90     days    1-360                   The amount of time for password aging.                   Password Expiration    7     days    1-30   Notice                               The amount of time prior to a password expiring that the NPAC SMS will notify a user.                   Post Expiration Logins    2     logins    0-10                   The number of logins a user is permitted after the user’s password has expired.                   Password Reuse Limit    6     months    1-36                   The amount of time in which a password cannot be reused.                   Record Logons After    10     attempts    0-100   Failure                               The threshold for consecutive failed logon attempts after which logon attempts will be recorded in the audit log.                   Non-Use Disconnect    60     minutes    1-1440                   The amount of idle (non-use) time before the NPAC SMS will disconnect a user’s logon session.                   Maximum Number of Download Records    10000     records    1-200000                   The maximum number of SV records for a single data download for a TN-based recovery request.                   Also, the maximum number of records for a single data download for a network data recovery request.                   Refer to the NPAC Customer Data Model, section 3.1.2, for information on the maximum for timestamp-based SV recovery requests.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    COMMUNCIATIONS TUNABLES                          Default       Valid   Tunable Name   Value   Units   Range         Maximum Download    60     minutes    1-1440   Duration                               The maximum time range allowed for a data download.                   Maximum Number of    2000     records    1-2000   Download Notifications                               The maximum number of notifications for a single notification recovery download.                   Service Provider and    50     objects    1-2000   Network Data Linked               Replies Blocking Factor                               The maximum number of objects in a single service provider or network data recovery linked reply response.                   Subscription Data    50     objects    1-2000   Linked Replies Blocking               Factor                               The maximum number of objects in a single subscription data recovery linked reply response.                   Notification Data Linked    50     notifications    1-2000   Replies Blocking Factor                               The maximum number of notifications in a single notifications recovery linked reply response.                   Number Pool Block Data    50     Objects    1-2000   Linked Replies Blocking               Factor                               The maximum number of objects in a single number pool block data recovery linked reply response.                   Service Provider and Network Data Maximum Linked Recovered Objects    10000     objects    1-10000                   The maximum number of objects sent in a service provider or network data recovery response, when the SOA/LSMS supports Linked Replies.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    COMMUNCIATIONS TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         Subscription Data    10000     objects    1-10000   Maximum Linked               Recovered Objects                               The maximum number of objects sent in a subscription data recovery response, when the LSMS supports Linked Replies.                   Notification Data    2000     notifications    1-10000   Maximum Linked               Recovered Notifications                               The maximum number of notifications sent in a notification recovery response, when the SOA/LSMS supports Linked Replies.                   Number Pool Block Data    10000     objects    1-10000   Maximum Linked               Recovered Objects                               The maximum number of objects sent in a number pool block data recovery response, when the LSMS supports Linked Replies.                   SOA SWIM Maximum    50000     objects    10000 — 100000   Tunable                               The maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery.                   LSMS SWIM Maximum    50000     objects    10000 — 100000   Tunable                               The maximum number of messages that will be stored by the NPAC for Service Providers that support SWIM recovery.                   Out-Bound Flow    100     Messages    50 — 500   Control Upper               Threshold Tunable                               The number of non-responsive messages sent to a SOA/LSMS before Out-Bound Flow Control is invoked.                   Out-Bound Flow    75     Messages    1 — 500   Control Lower               Threshold Tunable                                       Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    COMMUNCIATIONS TUNABLES                          Default       Valid   Tunable Name   Value   Units   Range         The number of non-responsive messages sent to a SOA/LSMS that is in a Flow Control state before normal processing is resumed, on a per association basis.                   Roll-Up Activity — Single    15     Minutes    1 — 60   Tunable                               The number of minutes before roll-up activity is initiated for an event involving a single SV.                   Roll-Up Activity Timer    60     Minutes    1 — 60   Expire SVRange               Tunable                               The number of minutes before roll-up activity is initiated for an event involving a range of SVs.                   Abort Processing    60     Minutes    1 — 180   Behavior Upper               Threshold Tunable                               The number of minutes before an NPAC abort will occur for a SOA/LSMS that has at least one outstanding message with a delta between the origination time and the current time that is equal to or greater than the tunable window, regardless of whether the SOA/LSMS has incurred any other activity (request or response).                   Regional NPAC NPA    False    Boolean    True/False   Edit Flag Indicator                               An indicator as to whether or not NPA edits will be enforced by the NPAC SMS for a particular NPAC region.                   NPAC SMS Application    15     Minutes    5 — 60   Level Heartbeat Tunable                               Defines the period of quiet time (no interface traffic) the NPAC should wait after the receipt of any interface traffic (request or response), before sending an Application Level Heartbeat message to the SOA/Local SMS.                   NPAC SMS Application    1     Minutes    1 — 5   Level Heartbeat               Timeout Tunable                                       Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    COMMUNCIATIONS TUNABLES                          Default       Valid   Tunable Name Value   Units   Range         The period of time the NPAC should wait after sending an Application Level Heartbeat message to the SOA/Local SMS, and not receiving a response from the SOA/Local SMS, before aborting the association.     Table C- 2 — Communications Tunables  AUDIT TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         Canceled Audit    30     days    1-360   Retention Period                               The length of time canceled audits will be retained.                   Data Integrity Sample    1000     SVs    1-5000   Size                               The number of active Subscription Versions in a sample to be monitored by the NPAC SMS.                   Data Integrity Sample    7     Days    1-90   Frequency                               The interval in days between Data Integrity Samples conducted by the NPAC SMS.                   Subscription Query    50     Subscriptions    1-5000   Record Limit                               The maximum number of records that can be returned from a query.     Table C- 3 — Audit Tunables                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-12    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    LOGS TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         Local SMS Activation    90     days    1-360   Log Retention Period                               The number of days Local SMS activation responses will remain in the log.                   Audit Log Retention    90     days    1-360   Period                               The length of time audit logs will be retained.                   Error Log Retention    90     days    1-360   Period                               The length of time system error logs will be retained.                   History File Data    365     days    1-365   Storage                               The length of time history logs will be retained.                   Usage Log Retention    90     days    1-360                   The length of time usage logs will be retained.     Table C- 4 — Logs Tunables  KEYS TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         Key Change Interval   365    days   1-365       How often the key is changed automatically.     Table C- 5 — Keys Tunables                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-13    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    BLOCK TUNABLES                          Default       Valid    Tunable Name   Value   Units   Range         NPA-NXX Availability – First Usage Effective Date Window    5     days    5-360                   The minimum length of time between the Creation date (exclusive) and the effective date/due date (inclusive), when creating a NPA-NXX-X or Subscription Version for the first time within that NPA-NXX.     Table C- 6 — Block Tunables                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-14    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables    SOA Notification Priority Tunables  Many notifications are sent to both the Old Service Provider and the New Service Provider. As indicated in the table below, some of these notifications can have different priorities based on whether the Service Provider is acting as the Old Service Provider or the New Service Provider for the port. During the notification evaluation process this option was not given to all notifications that are sent to both the Old Service Provider and the New Service Provider for one or more reasons. Some of those reasons were:       •   volume of the particular notification was very small        •   importance of the particular notification was determined to be equal whether a Service Provider was acting as the Old Service Provider or the New Service Provider for the port                    #   Notification Name   Priority     L-1.0    NPAC SMS Operational Information Notification    MEDIUM               L-2.0    Subscription Audit Discrepancy Report    MEDIUM               L-3.0    Subscription Audit Results    MEDIUM               L-4.0    Subscription Version Cancellation Acknowledge Request    MEDIUM               A    Scenario A: the OLD SP is requesting cancellation and no concurrence from New SP.                   L-4.0    Subscription Version Cancellation Acknowledge Request    MEDIUM               B    Scenario B: the New SP is requesting cancellation and no concurrence from Old SP.                   L-6.0    Subscription Version — Donor SP — Customer Disconnect Date Notification    MEDIUM               L-7.0    Subscription Version Local SMS Action Results    N/A               L-8.0    Subscription Version New NPA-NXX Notification    MEDIUM (to SOA)               L-9.0    Subscription Version New SP Create Request Notification (T1 timer expiration for New SP concurrence)    MEDIUM               L-10.0    Subscription Version Old SP Concurrence Request Notification (T1 timer expiration for Old SP concurrence)    MEDIUM               L-11.0    Subscription Version Status Attribute Value Change Notification – Activates – To the New Service Provider    MEDIUM               A1    When an INTER or INTRA SV has been created in the Local SMSs (or ‘activated‘ by the SOA) and the SV status has been set to: Active or Partial-Failure. The notification is sent to both SOAs: Old and New. If the status has been set to Partial-                               Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-15    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006                             #   Notification Name   Priority          Failure, this notification contains the list of Service Providers (SP) LSMSs that have failed to receive the broadcast.                        Note: See L-11.0 E for Deletes and L-11.0 F for Modify Actives                   L-11.0    Subscription Version Status Attribute Value Change Notification – Activates – To the Old Service Provider    MEDIUM               A1.5    When an INTER or INTRA SV has been created in the Local SMSs (or ‘activated‘ by the SOA) and the SV status has been set to: Active or Partial-Failure. The notification is sent to both SOAs: Old and New. If the status has been set to Partial-Failure, this notification contains the list of Service Providers (SP) LSMSs that have failed to receive the broadcast.                        Note: See L-11.0 E for Deletes and L-11.0 F for Modify Actives                   L-11.0    Subscription Version Status Attribute Value Change Notification – re-sends to fail list – To The New Service Provider    MEDIUM               A2    Intermediate Notification for Partial Failure. Every time a SP is removed from the Failed SP-List, the NPAC re-sends the notification to both SOAs. This iteration happens until the last SP is cleared from the fail-list.                   L-11.0    Subscription Version Status Attribute Value Change Notification – re-sends to fail list – To The Old Service Provider    MEDIUM               A2.5    Intermediate Notification for Partial Failure. Every time a SP is removed from the Failed SP-List, the NPAC re-sends the notification to both SOAs. This iteration happens until the last SP is cleared from the fail-list.                   L-11.0    Subscription Version Status Attribute Value Change Notification – clear Fail List – To The New Service Provider    MEDIUM               A3    Final Notification associated with a Partial Failure. Upon clearing the Failed SP-List, the NPAC sends the same notification to both SOAs but with an SV status of active and empty fail-list.                   L-11.0    Subscription Version Status Attribute Value Change Notification – clear Fail List – To The Old Service Provider    MEDIUM               A3.5     Final Notification associated with a Partial Failure. Upon clearing the Failed SP-List, the NPAC sends the same notification to both SOAs but with an SV status of active and empty fail-list.           L-11.0    Subscription Version Status Attribute Value Change Notification – total failure    MEDIUM               B    When an SV has failed to be created (or ‘activated’) in ALL LSMSs and the SV status has been set to Failed. The notification is sent to both SOAs: Old and New.                   L-11.0    DELETED                               Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-16    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006                             #   Notification Name   Priority     C                       L-11.0    Subscription Version Status Attribute Value Change Notification – re-sends    MEDIUM               D1    When the NPAC re-sends Modify Active or Deletes to the LSMSs for SVs with statuses of Active or Old, with a Fail SP List (the notification is sent regardless of the final status of the SV) The notification is sent to the Current (New) SOA.                   L-11.0    Subscription Version Status Attribute Value Change Notification – set to OLD    MEDIUM               E    When the SV status has been set to old. (Port to Original, port-of-a port, port to original of a Pool TN (or snap back), disconnect, disconnect of a ported Pool TN). The notification is received only by those SOAs that actually have the SV in their local DB. It varies with the scenario.                        Note: See L-11.0 A1.5 for Activates and L-11.0 F for Modify Actives                   L-11.0    Subscription Version Status Attribute Value Change Notification – Modify active    MEDIUM               F    When an Active SV has been modified in the LSMS or there has been a cancellation of a Disconnect-Pending SV and the status of the SV has been re-set to Active (with or without a Fail-SP-List). The notification is sent only to the current SOA.                        Note: See L-11.0 A1 for Activates and L-11.0 E for Deletes                   L-11.0    Subscription Version Status Attribute Value Change Notification – cancel pending    MEDIUM               G    When a Pending or Conflict SV has been cancelled by the Old or New SP and the NPAC SMS has set the SV status to Cancel-Pending. Also, when a Cancel-Pending SV is modified back (un-do) to Pending.The notification is sent to both SOAs: Old and New.                   L-11.0    Subscription Version Status Attribute Value Change Notification — cancel    MEDIUM               H1    When the NPAC SMS has set the status of a, cancel-pending, SV to CANCEL after concurrence and cancellation acknowledgment by both SOAs has been received in the NPAC The notification is sent to both SOAs: Old and New.                   L-11.0    Subscription Version Status Attribute Value Change Notification — cancel    MEDIUM               H2    When the NPAC SMS has set the status of a, cancel-pending, SV to CANCEL after the New Service Provider has cancelled the Pending SV but the Old Service Provider has not acknowledged the cancellation by the time the Cancellation Acknowledgement Final Concurrence Timer has expired. The notification is sent to both SOAs: Old and New.                   L-11.0    Subscription Version Status Attribute Value Change Notification — cancel    MEDIUM               H3    When the NPAC SMS has set the status of a pending SV to CANCEL after cancellation request by the originating SOA with no concurrence from the other                               Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-17    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006                             #   Notification Name   Priority          SOA. (Only one create action has been received in the NPAC and the same provider sends the cancellation request before the second provider send a create request.) The notification is sent to both SOAs: Old and New.                   L-11.0    Subscription Version Status Attribute Value Change Notification — cancel    MEDIUM               H4    When the NPAC SMS has set the status of a conflict SV to CANCEL after the Conflict Cancellation Window expires, if no resolution has been reached for the conflict, the NPAC automatically cancels the Conflict SV. The notification is sent to both SOAs: Old and New.           L-11.0    Subscription Version Status Attribute Value Change Notification – Disconnect pending    MEDIUM               I    When an active SV is being disconnected with an Effective Release Date in the NPAC and the SV status is set to Disconnect-Pending. Only the current SOA receives the notification.                   L-11.0    Subscription Version Status Attribute Value Change Notification – Fail disconnect    MEDIUM               J    When the NPAC attempts to delete an Active SV and the request fails to ALL LSMSs and the SV status is re-set to Active. Only the Current SOA receives the notification.                   L-11.0    Subscription Version Status Attribute Value Change Notification — Conflict    MEDIUM               K1    When the status of a Pending SV is set to conflict. The notification is sent to both SOAs: Old and New.                   L-11.0    Subscription Version Status Attribute Value Change Notification — Conflict    MEDIUM               K2    When the status of a Cancel-Pending SV is set to conflict. Cancel-Pending to Conflict is when the Old Service Provider has cancelled the Pending SV but the New Service Provider has not acknowledged the cancellation by the time the Cancellation Acknowledgement Final Concurrence Timer has expired. The notification is sent to both SOAs: Old and New.                   L-11.0    Subscription Version Status Attribute Value Change Notification    MEDIUM               L    After Conflict Resolution, when the status of the Conflict SV is re-set to Pending. The notification is sent to both SOAs: Old and New.                   L-12.0    Subscription Version Old SP Final Concurrence Timer Expiration Notification    MEDIUM                    (T2 expiration for Old SP concurrence)                   L-13.0    Number Pool Block Status Attribute Value Change Notification    MEDIUM               A    The Pool Block has being created in the LSMSs (EDR and Non_EDR) and the Block Status has being set to Active or Partial Failure;                               Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-18    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006                             #   Notification Name   Priority     L-13.0    Number Pool Block Status Attribute Value Change Notification    MEDIUM               B    The creation of the Pool Block has failed in all the LSMSs (EDR and Non-EDR) and the Block Status has been set to Failed.                   L-13.0    Number Pool Block Status Attribute Value Change Notification    MEDIUM               C    The NPAC attempts to re-send a failed Pool Block or failed SVs to SP in the fail-SP-List of the Block and the Block status changes to Active, Partial Failure or Failure.                   L-13.0    Number Pool Block Status Attribute Value Change Notification    MEDIUM               D    The attributes in the Pool Block have been modified in the LSMSs (EDR and Non-EDR) and the Block Status has been re-set to Active (with or without fail-sp-list).                   L-13.0    Number Pool Block Status Attribute Value Change Notification    MEDIUM    E    When a Pool Block has been ‘de-pooled’ from the LSMSs (EDR and Non-EDR) and the Block Status has been set to Old (with or without fail-sp-list).                   L-13.0    Number Pool Block Status Attribute Value Change Notification    MEDIUM               F    When the NPAC SMS has attempted to ‘de-pool’ a block but the request has failed to ALL LSMSs (EDR and Non-EDR) and the Block Status has been reset to Active with a Failed-SP-list.                   L-14.0    Subscription Version New SP Final Create Window Expiration Notification    MEDIUM                    It will be sent after T2 expiration to both SPs SOAs (old and new) to inform them that the T2 timer has expired and the new SP hasn’t send its create request yet. The SV will remain in status of Pending until the New SP sends the Create or the NPAC cancels it.                   S-1.00    Object Creation    MEDIUM               S-2.00    Object Deletion    MEDIUM               S-3.00    Attribute Value Change   MEDIUM               A    For pending SVs                    S-3.00    Attribute Value Change   MEDIUM               B    For Pool Blocks                      Table C- 7 – SOA Notification Priority Tunables                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-19    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             System Tunables                                                    Release 3.3: © 1997 — 2006 NeuStar, Inc.    C-20    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Encryption Key Exchange    Appendix D. Encryption Key Exchange  The mechanized interface to NPAC SMS requires an exchange of the encryption keys used to verify digital signatures. This exchange will consist of a file containing the 1000 key list, and an acknowledgment of receipt of the list will consist of a file containing the MD5 checksum value of each key in the list. The formats for these files is described here.  Key Exchange File  The following table shows the format of the encryption key exchange file. This file consists of some header information, followed by 1000 instances of key information. There are no separators of any kind between the individual fields, between the header and key data, or between each set of key data.  ENCRYPTION KEY EXCHANGE FILE FORMAT                              Field                   Number   Field Name   Type   Size (bytes)   Format         1    NPAC Customer Id    ASCII      4     Character String                           2    File Creation Date    ASCII      14     MMDDYYYYHHmmSS                           3    List Id    Binary      2     16 bit integer                           4    Key Size (in bits)    Binary      4     32 bit integer                           5    Key Id    Binary      2     16 bit integer                           6    public exponent size    Binary      2     16 bit integer                           7    public exponent    Binary    variable1    integer                           8    public modulus    Binary    variable2    integer              1. The size of the public exponent is determined by the previous field of the key data, public exponent size.                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    D-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Encryption Key Exchange                                Field                    Number   Field Name   Type   Size (bytes)   Format         9    Key Id    Binary      2     16 bit integer                           10    public exponent size    Binary      2     16 bit integer                           11    public exponent    Binary    variable    integer                           12    public modulus    Binary    variable    integer                           .    . . .    . . .      . . .     . . .                           4001    Key Id    Binary      2     16 bit integer                           4002    public exponent size    Binary      2     16 bit integer                           4003    public exponent    Binary    variable    integer                           4004    public modulus    Binary    variable    integer                             Table D- 1 — Encryption Key Exchange File Format             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 — 2006 NeuStar, Inc.    D-2    North American Numbering Council (NANC)          Functional Requirements Specification Release 3.3.2a               Freely distributable subject to the terms of the GNU GPL, see inside cover notice. March 9, 2006             Encryption Key Exchange         Key Acknowledgment File  Before a key list may be used, the sender must receive a key acknowledgment file. The key acknowledgment file serves two purposes:     1.   Verify that the key list has been received by the intended recipient.      2.   Verify the correctness of each key in the list.    Furthermore, the need for an acknowledgment of this kind is specified in requirement R7-108.2. Once this file has been received, the sender of the key list can put the list into active use.  Table D-1 below shows the format of the encryption key acknowledgment file. This file consists of some header information, followed by 1000 instances of key hash information. There are no separators of any kind between the individual fields, between the header and key hash data, or between each set of key hash data. The MD5 hash value will be calculated from the public modulus value of the key.  ENCRYPTION KEY ACKNOWLEDGEMENT FILE FORMAT                          Field                   Number   Field Name   Type   Size (bytes)   Format     1    NPAC Customer Id    ASCII    4     Character String                       2    File Creation Date    ASCII    14     MMDDYYYYHHmmSS                       3    List Id    Binary    2     16 bit integer                       4    Key Id    Binary    2     16 bit integer                       5    Key’s MD5 hash    Binary    16     128 bit integer                       6    Key Id    Binary    2     16 bit integer                        7    Key’s MD5 hash    Binary    16     128 bit integer                       . . .     . . .     . . .     . . .     . . .                        2002    Key Id    Binary    2     16 bit integer                       2003    Key’s MD5 hash    Binary    16     128 bit integer     Table D- 2 — Encryption Key Acknowledgement File Format                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    D-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Encryption Key Exchange         Key Exchange using PGP  LNP Key exchange can be accomplished via email, ftp or an exchange of physical media using PGP for security. Using PGP, a Service Provider will generate a pair of keys, one private and one public. The Service Provider will transmit the public key to the NPAC. This may be done via email or ftp, or any other mechanism of exchanging files. The key in this file is then saved by the NPAC’s PGP program. This key can now be used to encrypt files that only the Service Provider may decrypt, even if the key is intercepted by someone, it will not matter, they cannot use it to do anything other than encrypt messages for the Service Provider.  At this point, the NPAC can encrypt a file containing the keys for the Service Provider. This file may be emailed, put on the ftp site, or put on a disk for the Service Provider.  For LNP key lists that the Service Provider must provide to the NPAC, the reverse procedure would apply. First the NPAC would send a public key to the Service Provider. The Service Provider then encrypts their key list using the public key, and somehow gets the encrypted file to the NPAC.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    D-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         Appendix E. Download File Examples  The NPAC can generate Bulk Data Download files for Network Data (including SPID, LRN, NPA-NXX and NPA-NXX-X), Subscription Versions (including Number Pool Blocks) and Notifications.  All fields within files discussed in the following section are variable length. The download reason in all “Active-like” download files is always set to new. The download reason in all “Latest View” download files is set to the appropriate download reason based on activation/modification/deletion activity. ASCII 13 is the value used as the value for carriage return (CR) in the download files.  All Time Stamps contained within the download files and SMURF files, and file names are in GMT (Greenwich Mean Time). Files that contain three timestamps reference the time the files is created, and start and end time range. When the time range is not specified, the default start timestamp is 00-00-0000000000 and the default end timestamp is 99-99-9999999999.  Subscription Download File  The following table describes each field of the sample subscription download file. This download file example contains data for three subscriptions, with three lines for each subscription. Each subscription is one record in the file, pipe delimited, with a carriage return ( CR ) between each subscription. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  Table E-1 describes the entries for subscription 1: The “Value in Example” column directly correlates to the values for subscription 1 in the download file example, as seen in Figure E-1.  If the Bulk Data Download input selection criteria specifies Latest View of Subscription Version Activity, the file will include all subscription versions with a Broadcast Timestamp that falls within a specified time range. If the Bulk Data Download input selection criteria specifies Active/Disconnect Pending/Partial Failure Subscription Versions Only, the file will include subscription versions with a status of Active, Disconnect Pending or Partial Failure or a status of Sending with a download reason of New or Modify that have an Activation timestamp that occurs at or before the time that the BDD request begins to be processed. File data is further narrowed when the input selection criteria includes a TN range. This will result in a file that includes information only on those subscription versions that fall within that TN range.  The file name for the Subscriptions download file will be in the format:  NPANXX-NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSSThe NPANXX-NPANXX values map to the selection criteria. The first timestamp is the time the request begins processing, the second timestamp is the beginning timestamp for the time range and the third timestamp is the ending timestamp for the time range. For active-like views the second and third timestamp will be set by default.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         The Subscriptions file given in the example would be named:       303123-303125.25-12-1996081122.25-12-1996080000.25-12-1996125959    0001|3031231000|1234567890|0001|19960916152337|  123123123|123|123123123|123|123123123|123|123123123|123|  123456789012|12|0001|0|0(CR)           (end of subscription 1)  0002|3031241000|1234567891|0001|19960825011010|  123123123|123|123123123|123|123123123|123|123123123|123|  123456789013|13|0001|0|0(CR)           (end of subscription 2)  0003|3031251000|1234567892|0001|19960713104923|  123123123|123|123123123|123|123123123|123|123123123|123|  123456789014|13|0001|0|0(CR)           (end of subscription 3)   Figure E- 1 — Subscription Download File Example  EXPLANATION OF THE FIELDS IN THE SUBSCRIPTION DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Version Id   0000000001               2   Version TN   3031231000               3   LRN   1234567890               4   New Current Service Provider Id   0001               5   Activation Timestamp   19960916152337  (yyyymmddhhmmss)               6   CLASS DPC   123123123 (This value is 3 octets)               7   CLASS SSN   123 (This value is 1 octet and usually set to 000)               8   LIDB DPC   123123123 (This value is 3 octets)               9   LIDB SSN   123 (This value is 1 octet and usually set to 000)               10   ISVM DPC   123123123 (This value is 3 octets)               11   ISVM SSN   123 (This value is 1 octet and usually set to 000)                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                               Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE FIELDS IN THE SUBSCRIPTION DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     12   CNAM DPC   123123123 (This value is 3 octets)               13   CNAM SSN   123 (This value is 1 octet and usually set to 000)               14   End user Location Value   123456789012               15   End User Location Type   12               16   Billing Id   0001               17   LNP Type   0               18   Download Reason   0               19   WSMSC DPC   Not present if LSMS or SOA does not support the WSMSC DPC as shown in this example.  If it were present the value would be in the same format as other DPC data.       20   WSMSC SSN   Not present if LSMS or SOA does not support the WSMSC SSN as shown in this example. If it were present the value would be in the same format as other SSN data.       21   SV Type   Not present if LSMS or SOA does not support the SV Type as shown in this example.  If it were present the value would be as defined in the SV Data Model.       22   Alternative SPID   Not present if LSMS or SOA does not support the Alternative SPID as shown in this example.  If it were present the value would be as defined in the SV Data Model.     Table E- 1 — Explanation of the Fields in The Subscription Download File  Network Download File  The following tables describe each field of the network download files. This series of download file examples contain data for one Service Provider that has three NPA-NXXs and three LRNs.  If the Bulk Data Download input selection criteria specifies Latest View of Network Data Activity, the files will include data with a Broadcast Timestamp that falls within the specified time range (NPA-NXX and LRN will use Creation Timestamp for a match and NPA-NXX-X data will use Modified Timestamp for a                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         match). If the Bulk Data Download input selection criteria specifies All Network Data, the files will include a representation of all network data as it exists on the NPAC SMS. All SPID data is included all of the time, regardless of selection criteria.  The Service Provider block contains one record in the file, individual fields are pipe delimited, with a carriage return(CR) after the Service Provider Id/Name. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  The “Value in Example” column in Table E-2 directly correlates to the values for the Service Provider in the download file example, as seen in Figure E-2.  The file name for the Service Provider download file will be in the format:            SPID.DD-MM-YYYYHHMMSS (The “SPID” portion is the literal string “SPID”.)  The Service Provider file given in the example would be named:            SPID.13-10-1996081122  EXPLANATION OF THE FIELDS IN THE NETWORK SERVICE PROVIDER DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Service Provider Id   0001               2   Service Provider Name   AMERITECH               3   Service Provider Type   Not present if the Service Provider does not support SP TYPE.     Table E- 2 — Explanation of the Fields in the Network Service Provider Download File    0001|AMERITECH|0(CR)                     (Service Provider Id/Name/SP Type)   Figure E- 2 — Network Service Provider Download File Example, SP Supports SP Type    0001|AMERITECH(CR)                     (Service Provider Id/Name)                         Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         Figure E-2a — Network Service Provider Download File Example, SP Does Not Support SP Type                                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         NPA/NXX Download File  The NPA/NXX download block contains three records in the file, individual fields are pipe delimited, with a carriage return( CR ) after each NPA-NXX record. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  The “Value in Example” column in Table E-3 directly correlates to the values for the first NPA/NXX in the download file example, as seen in Figure E-3.  The file name for the NPA-NXX download file will be in the format:       NPANXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The NPANXX portion is the literal string “NPANXX”.)  The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively. In the case of the All Network Data view, the second and third time stamps are set by default as no time range may be set by the user for this view.  The NPA-NXX file given in the example would be named:       NPANXX.13-10-1996081122.12-10-1998080000.13-10-1998133022  EXPLANATION OF THE FIELDS IN THE NETWORK NPA/NXX DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1    Service Provider Id    0001               2    NPA-NXX Id    2853               3    NPA-NXX Value    303123               4    Creation TimeStamp    19960101155555               5    Effective TimeStamp    19960105000000               6    Download Reason    0     Table E- 3 — Explanation of the Fields in the Network NPA/NXX Download File                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples                     0001|2853|303-123|19960101155555|19960105000000|0(CR)(NPA-NXX 1)            0001|2864|303-124|19960101155556|19960105000000|0(CR)(NPA-NXX 2)            0001|2870|303-125|19960101155557|19960105000000|0(CR)          (NPA-NXX 3)   Figure E- 3 — Network NPA-NXX Download File Example  LRN Download File  The LRN download block contains three records in the file, individual fields are pipe delimited, with a carriage return( CR ) after each LRN record. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  The “Value in Example” column in Table E-4 directly correlates to the values for the first LRN in the download file example, as seen in Figure E-4.  The file name for the LRN download file will be in the format:       LRN.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The LRN portion is the literal string “LRN”.)  The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively. In the case of the All Network Data view, the second and third time stamps are set by default as no time range may be set by the user for this view.  The LRN file given in the example would be named:  LRN.13-10-1996081122.12-10-1998080000.13-10-1998133022  EXPLANATION OF THE FIELDS IN THE NETWORK LRN DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Service Provider Id   0001               2   LRN Id   1624               3   LRN Value   1234567890               4   Creation TimeStamp   19960101155559               5   Download Reason   0     Table E- 4 — Explanation of the Fields in the Network LRN Download File                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples                     0001|1624|1234567890|19960101155559|0(CR)              (LRN 1)            0001|1633|1234567891|1996010115570010|0(CR)          (LRN 2)            0001|1650|1234567892|1996010115580505|0(CR)          (LRN 3)   Figure E- 4 — Network LRN Download File Example  NPA-NXX-X Download File  The following table describes the sample NPA-NXX-X download file which contains two records in the file, individual fields are pipe delimited, with a carriage return ( CR ) after each NPA-NXX-X record. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  The “Value in Example” column in Table E-5 directly correlates to the values for the first NPA-NXX-X in the download file example, as seen in Figure E-5.  The file name for the NPA-NXX-X download file will be in the format:       NPANXXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The NPANXXX portion is the literal string “NPANXXX”, and the timestamp maps to the current time [GMT].)  The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively. In the case of the All Network Data view, the second and third time stamps are set by default as no time range may be set by the user for this view.  The NPA-NXX-X file given in the example would be named:       NPANXXX.02-11-1998133022.12-10-1998080000.13-10-1998133022  EXPLANATION OF THE FIELDS IN THE NETWORK NPA-NXX-X DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Service Provider Id   0001               2   NPA-NXX-X Id   2853               3   NPA-NXX-X Value   303-123-6                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-8    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE FIELDS IN THE NETWORK NPA-NXX-X DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     4   Creation TimeStamp   19980101155555               5   Effective TimeStamp   19980105000000               6   Modified TimeStamp   19980105001111               7   Download Reason   0     Table E- 5 — Explanation of the Fields in the Network NPA-NXX-X Download File               0001|2853|303-123-6|19980101155555|19980105000000|19980105001111|0(CR)          (NPA-NXX-X 1)             0001|2864|303-124-4|19980101155556|19980105000000|19980105001111|0(CR)          (NPA-NXX-X 2)   Figure E- 5 — Network NPA-NXX-X Download File Example                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-9    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         Block Download File  The following table describes each field of the sample Block download file. This download file example contains data for three Blocks, with three lines for each Block. Each Block is one record in the file, pipe delimited, with a carriage return( CR ) between each Block. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  Table E-6 describes the entries for Block 1: The “Value in Example” column directly correlates to the values for Block 1 in the download file example, as seen in Figure E-6.  Blocks in the download file are selected by a combination of NPA-NXX-X begin and end, as well as TIME begin and end range. The TIME Range is keyed off the Broadcast Timestamp. The file name for the Block download file will be in the format:  NPANXXX-NPANXXX.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS  The NPANXXX-NPANXXX values map to the NPA-NXX-X selection criteria, the first stamp maps to the current time (when the file is generated), the second time stamp maps to the begin time range, and the third time stamp maps to the end time range. All three time stamps are represented in GMT.  The Block file given in the example would be named:       3031235-3031252.17-09-1996153344.11-07-1996091222.17-09-1996153344  The files available for LSMS compares will be defined as one or more NPA-NXX-Xs per file.              1|3031231|1234567890|0001|19960916152337|123123123|123|123123123|            123|123123123|123|123123123|123|||0(CR)          (end of Block 1)            2|3031241|1234567891|0001|19960825011010|123123123|123|123123123|            123|123123123|123|123123123|123|||0(CR)          (end of Block 2)            3|3031251|1234567892|0001|19960713104923|123123123|123|123123123|            123|123123123|123|123123123|123|||0(CR)          (end of Block 3)   Figure E- 6 — Block Download File Example  EXPLANATION OF THE FIELDS IN THE BLOCK DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Block Id   1                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-10    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE FIELDS IN THE BLOCK DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     2   NPA-NXX-X   3031231               3   LRN   1234567890               4   New Current Service Provider Id   0001               5   Activation Timestamp   19960916152337  (yyyymmddhhmmss)               6   CLASS DPC   123123123 (This value is 3 octets)               7   CLASS SSN   123 (This value is 1 octet and usually set to 000)               8   LIDB DPC   123123123 (This value is 3 octets)               9   LIDB SSN   123 (This value is 1 octet and usually set to 000)               10   ISVM DPC   123123123 (This value is 3 octets)               11   ISVM SSN   123 (This value is 1 octet and usually set to 000)               12   CNAM DPC   123123123 (This value is 3 octets)               13   CNAM SSN   123 (This value is 1 octet and usually set to 000)               14   WSMSC DPC   Not present if LSMS or SOA does not support the           WSMSC DPC as shown in this example.  If it were           present the value would be in the same format as           other DPC data.               15   WSMSC SSN   Not present if LSMS or SOA does not support the           WSMSC SSN as shown in this example.  If it were           present the value would be in the same format as           other SSN data.               16   Download Reason   0               17   SV Type   Not present if LSMS or SOA does not support the           SV Type as shown in this example.  If it were           present the value would be as defined in the SV           Data Model.               18   Alternative SPID   Not present if LSMS or SOA does not support the           Alternative SPID as shown in this example.  If ti           were present the value would be as defined in the           SV Data Model.     Table E- 6 — Explanation of the Fields in The Block Download File                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-11    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         Notifications Download File  The Notification download file contains records for notifications as they are defined in the IIS. Each record contains required and optional attributes and data is logged at the time of notification generation based on the reason the notification was generated as well as NPAC Customer profile settings. The inclusion of TN/TN Range/NPA-NXX-X in respective notifications is not dependent on the NPAC Customer settings for Subscription Version TN Attribute Flag and Number Pool Block NPA-NXX-X Attribute Flag indicators.  The Notifications download file example (Figure E- 8 — Notification Download File Example, below) contains two records in the file, individual fields are pipe delimited, with a carriage return( CR ) after each Notification record. The breaks in the lines and the parenthesized comments are solely for ease of reading and understanding.  The “Value in Example” column in Table E-7 directly correlates to the values for the hypothetical Notification in the download file example, as seen in Figure E-8.  The file name for the Notifications download file will be in the format:       Notifications.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS.DD-MM-YYYYHHMMSS (The Notifications portion is the literal string “ Notifications”.)  The first timestamp in the filename is the time the download begins. The second and third timestamps are the beginning and ending time ranges respectively.  The Notifications file given in the example would be named:       Notifications.15-10-2004081122.12-10-2004080000.13-10-2004133022  In the download file each notification can be identified by the combination of the Notification ID and Object ID fields. LNP specific notifications are defined with a unique Notification ID in the GDMO however some notifications sent across the interface are CMIP primitives and do not have unique Notification IDs. In order to uniquely identify these notifications in the download file, the original CMIP primitive Notification ID has been augmented with a 1000-series number to create a unique Notification ID/Object ID combination. For example, the subscriptionVersionNPAC-ObjectCreation notification is a CMIP primitive notification that uses a Notification ID of (6) and Object ID of (21) across the interface. At the same time the LNP specific notification, subscriptionVersionDonorSP-CustomerDisconnectDate as defined in the GDMO uses the same Notification ID and Object ID. In order to uniquely identify the subscriptionVersionNPAC-ObjectCreation notification for the download file we have augmented the Notification ID to a 1000-series number of, (1006). The Object ID remains the same (21). The affected notifications are:       •   SubscriptionVersionNPAC-ObjectCreation (Notification ID 1006, Object ID 21)        •   SubscriptionVersionNPAC-attributeValueChange (Notification ID 1001, Object ID 21)        •   SubscriptionAudit-objectCreation (Notification ID 1006, Object ID 19)        •   Subscription Audit-objectDeletion (Notification ID 1007, Object ID 19)        •   NumberPoolBlock-objectCreation (Notification ID 1006, Object ID 30)        •   NumberPoolBlock-attributeValueChange (Notification ID 1001, Object ID 30)                          Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-12    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF FIELDS IN A HYPOTHETICAL NOTIFICATIONS DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1    Creation TimeStamp    The time the notification was created.                        For example: 19960101155555               2    Service Provider Id    1111                3    System Type (SOA=0, LSMS=1)    0                4    Notification ID    1                5    Object ID    18                6    WSMSC DPC    Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported WSMSC DPC at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support the WSMSC DPC at the time of notification generation as shown in this example. If it were present the value would be in the same format as other DPC data (for example, 123123123 (This value is 3 octets)).                        Value in example:               7    WSMSC SSN    Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported WSMSC SSN at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support the WSMSC SSN at the time of notification generation as shown in this example. If it were present the value would be in the same format as other SSN data (for example, 123 (This value is 1 octet and usually set to 000)).                        Value in example:               8    Subscription Timer Type    Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported Timer Type at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support Timer Type at the time of notification generation. (1) for Short or (0) for Long.                        Value in example: 1                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-13    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF FIELDS IN A HYPOTHETICAL NOTIFICATIONS DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     9    Subscription Business Type    Data for this attribute is included if the attribute was included in the original notification which depends on whether or not the Service Provider supported Business Type at the time of notification generation. This field (empty pipes) will still be present but data is not present if LSMS or SOA did not support Business Type at the time of notification generation. (0) for Short or (1) for Long.                        Value in example: 0                10    Range Type (consecutive list=1, non-consecutive list =2)    1                         NOTE: This field is only present in range notifications and included here for field definition and illustration purposes only.               11    Attribute 1    1234                12    Attribute 2    303123                13    Attribute 3    20040915000000                14    Attribute 4    0                15    Attribute 5    20040831173545                N    Attribute n          Table E- 7 — Explanation of the Fields in the Notifications Download File              19960101155555|1111|0|1|18|||1|0|1|1234|303123|20040915000000|0|20040831173545(CR) (Notification 1)            19960101155555|1111|0|1|18|||1|0|1|1235|303242|20040915000000|0|20040831173549(CR) (Notification 2)   Figure E- 8 — Notification Download File Example  The format for each potential notification type is provided in the following table.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-14    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     SOA Notifications               subscriptionVersionCancellationAcknowledgeRequest               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    1003                3    System Type    0                4    Notification ID    4                5    Object ID    21                6    Version TN    3031231000                7    Version ID    1234567899                          subscriptionVersionRangeCancellationAcknowledgeRequest (* if a consecutive list)                           1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    18                5    Object ID    14                6    Range Type Format    1                7    Starting Version TN    3031231000                8    Ending Version TN    3031232000                9    Starting Version ID    1200000001                10    Ending Version ID    1200001002                          subscriptionVersionRangeCancellationAcknowledgeRequest (* if not a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-15    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     2    Service Provider ID    0001                3    System Type    0                4    Notification ID    18                5    Object ID    14                6    Range Type Format    2                7    Starting Version TN    3031231000                8    Ending Version TN    3031231009                9    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 10).       10    Version ID    1230000001                11    Version ID    1230000004                12    Version ID    1230000006                13    . . . Version ID “n”    1230000009                subscriptionVersionDonorSP-CustomerDisconnectDate               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    6                5    Object ID    21                6    Customer Disconnect Date    20050530230000                7    Effective Release Date    20050530230000                8    Version TN    3031231000                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-16    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     9    Version ID    1234567899                          subscriptionVersionRangeDonorSP-CustomerDisconnectDate (* if a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    17                5    Object ID    14                6    Customer Disconnect Date    20050530230000                7    Effective Release Date    20050530230000                8    Range Type Format    1                9    Starting Version TN    3032201000                10    Ending Version TN    3032201009                11    Starting Version ID    1234000000                12    Ending Version ID    1234000008                          subscriptionVersionRangeDonorSP-CustomerDisconnectDate (* if not a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    17                5    Object ID    14                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-17    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     6    Customer Disconnect Date    20050530230000                7    Effective Release Date    20050530230000                8    Range Type Format    2                9    Starting Version TN    1232201000                10    Ending Version TN    1232201010                11    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 11).               12    Version ID    1234000099                13    Version ID    1234000103                14    ... Version ID “n”    1234000119                subscriptionVersionNewSP-CreateRequest               1    Creation TimeStamp    For example: 19960101155555               2    Service Provider ID    0001                3    System Type    0                4    Notification ID    9                5    Object ID    21                6    Old Service Provider ID    1003                7    Old Service Provider Due Date    20050530230000                8    Old Service Provider Authorization    0                9    Old Service Provider Authorization Time Stamp    20050520125032                10    Subscription Status Change Cause Code    50                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-18    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     11    Subscription Timer Type    0                12    Subscription Business Type    1                13    Version TN    1232201999                14    Version ID    1234000099                      subscriptionVersionRangeNewSP-CreateRequest (* if a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    19                5    Object ID    14                6    Old Service Provider ID    0002                7    Old Service Provider Due Date    20050530230000                8    Old Service Provider Authorization    0                9    Service Provider Authorization Time Stamp    20050520123045                10    Subscription Status Change Cause Code    50                11    Subscription Timer Type    0                12    Subscription Business Type    1                13    Range Type Format    1                14    Starting Version TN    3032201999                15    Ending Version TN    3032202012                16    Starting Version ID    1234000000                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-19    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     17    Ending Version ID    1234000013                          subscriptionVersionRangeNewSP-CreateRequest (* if not a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    19                5    Object ID    14                6    Old Service Provider ID    0234       7    Old Service Provider Due Date    20050530230000                8    Old Service Provider Authorization    0                9    Service Provider Authorization Time Stamp    200505220231632                10    Subscription Status Change Cause Code    50                11    Subscription Timer Type    0                12    Subscription Business Type    1                13    Range Type Format    2                14    Starting Version TN    3033301600                15    Ending Version TN    3033301699                16    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 100).               17    Version ID    2340000000                18    Version ID    2340000016                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-20    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     19    ... Version ID “n”    2340000023        subscriptionVersionOldSP-ConcurrenceRequest               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    10                5    Object ID    21                6    New Current Service Provider ID    2003                7    Service Provider Due Date    20050530230000                8    New Service Provider Creation Time Stamp    20050518231625                9    Subscription Timer Type    0                10    Subscription Business Type    1                11    Version TN    3033301000                12    Version ID    1234560000                          subscriptionVersionRangeOldSP-ConcurrenceRequest (* if a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    20                5    Object ID    14                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-21    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     6    New Current Service Provider ID    2003                7    Service Provider Due Date    20050530230000                8    New Service Provider Creation Time Stamp    20050518231625                9    Subscription Timer Type    0                10    Subscription Business Type    1                11    Range Type Format    1                12    Starting Version TN    3033301000                13    Ending Version TN    3033301009                14    Starting Version ID    1000000001                15    Ending Version ID    1000000010                  subscriptionVersionRangeOldSP-ConcurrenceRequest (* if not a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    20                5    Object ID    14                6    New Current Service Provider ID    2003                            7    Service Provider Due Date    20050530230000                8    New Service Provider Creation Time Stamp    20050518231625                9    Subscription Timer Type    0                10    Subscription Business Type    1                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-22    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     11    Range Type Format    2                12    Starting Version TN    3033300000                13    Ending Version TN    3033300099                14    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 100).               15    Version ID    1000000001                16    Version ID    1000000009                17    ... Version ID “n”    1000001011                subscriptionVersionStatusAttributeValueChange       1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    0001                3    System Type    0                4    Notification ID    11                5    Object ID    21                6    Subscription Version Status    1                7    Subscription Version Status Change Cause Code    0                8    Version TN    3033301290                9    Version ID    1234500009                10    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 3).                        Note: If there aren’t any Service Providers on the Failed list then the last field will be the VersionID.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-23    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     11    (failed list) Service Provider ID - - Service Provider Name    2003-TelCo               12    (failed list) Service Provider ID - - Service Provider Name    2910-Tel S               13    ...    1034-Tel M                         subscriptionVersionRangeStatusAttributeValueChange (* if a consecutive list)               1    Creation TimeStamp    For example: 19960101155555               2    Service Provider ID    1001                3    System Type    0               4    Notification ID    14                5    Object ID    14                6    Subscription Version Status    1                7    Subscription Version Status Change Cause Code    0                8    Range Type Format    1                9    Starting Version TN    3034401000                10    Ending Version TN    3034401001                11    Starting Version ID    4420000097                12    Ending Version ID    4420000098                13    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 2).                        Note: If there aren’t any Service Providers on the Failed list then the last field will be the Ending VersionID.               14    (failed list) Service Provider ID - - Service Provider Name    2003-TelCo                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-24    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     15    (failed list) Service Provider ID - - Service Provider Name    2910-Tel S                         subscriptionVersionRangeStatusAttributeValueChange (* if not a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    1001                3    System Type    0                4    Notification ID    14                5    Object ID    14                6    Subscription Version Status    1                7    Subscription Version Status Change Cause Code    0                8    Range Type Format    2                9    Starting Version TN    3034401012                10    Ending Version TN    3034401019                11    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 8).               12    Version ID    1000050090                13    Version ID    1000050096                14    Version ID    1000050099                15    ... Version ID “n”    1000005100                16    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 3).                        Note: If there aren’t any Service Providers on the Failed list then the last field will be the VersionID “n”.                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-25    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     17    (failed list) Service Provider ID - - Service Provider Name    2003-TelCo               18    (failed list) Service Provider ID - - Service Provider Name    2910-Tel S               19    ...    1034-Tel M       subscriptionVersionNPAC-ObjectCreation               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    1001                3    System Type    0                4    Notification ID    1006                5    Object ID    21                6    New Service Provider Creation Time Stamp    20050518231625                7    New Service Provider Due Date    20050530230000                8    Old Service Provider Authorization Time Stamp                   9    Old Service Provider Due Date                   10    Old Service Provider Authorization                   11    New Current Service Provider ID    1001                12    Old Service Provider ID    1003                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-26    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     13    Conflict Time Stamp                   14    Status Change Cause Code                   15    Subscription Version Status    1                16    Version TN    3034401000                17    Version ID    1239999909                          subscriptionVersionRangeObjectCreation (* if a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    1003                3    System Type    0                4    Notification ID    16                5    Object ID    14                6    New Service Provider Creation Time Stamp    20050518231625                7    New Service Provider Due Date    20050530230000                8    Old Service Provider Authorization Time Stamp                   9    Old Service Provider Due Date                               Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-27    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     10    Old Service Provider Authorization                   11    New Current Service Provider ID    0001                12    Old Service Provider ID    1003                13    Conflict Time Stamp                   14    Status Change Cause Code                   15    Subscription Version Status    1                16    Range Type Format    1                17    Starting Version TN    3034401000                18    Ending Version TN    3034402000                19    Starting Version ID    1234500001                20    Ending Version ID    1234501002                          subscriptionVersionRangeObjectCreation (* if not a consecutive list)               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    1003                3    System Type    0                4    Notification ID    16                5    Object ID    14                6    New Service Provider Creation Time Stamp    20050518231625                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-28    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     7    New Service Provider Due Date    20050530230000                8    Old Service Provider Authorization Time Stamp                   9     Old Service Provider Due Date                   10    Old Service Provider Authorization                   11    New Current Service Provider    0001                12    Old Service Provider ID    1003                13    Conflict Time Stamp                   14    Status Change Cause Code                   15    Subscription Version Status    1                16    Range Type Format    2                17    Starting Version TN    3034401000                18    Ending Version TN    3034401097                19    Variable Field Length    Indicates the number of dynamic values for the following field (e.g. 98).               20    Version ID    2050505050                21    Version ID    2050505059                            Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-29    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     22    ... Version ID “n”    2050507019                subscriptionVersionNPAC-attributeValueChange               1    Creation TimeStamp    For example: 19960101155555                2    Service Provider ID    1003                3    System Type    0                4    Notification ID    1001                5    Object ID    21                6    New Service Provider Creation Time Stamp    20050518231625                7    New Service Provider Due Date    20050530230000                8    Old Service Provider Authorization Time Stamp                   9    Old Service Provider Due Date                   10    Old Service Provider Authorization                   11    Conflict Time Stamp                   12    Version TN    3034401000                13    Version ID    1234567890                          subscriptionVersionRangeAttributeValueChange (* if a consecutive list)                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-30    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     15               5    Object ID     14               6    New Service Provider Creation Time Stamp     20050518231625               7    New Service Provider Due Date     20050530230000               8    Old Service Provider Authorization Time Stamp                   9    Old Service Provider Due Date                   10    Old Service Provider Authorization                   11    Conflict Time Stamp                   12    Range Type Format     1               13    Starting Version TN     3034401000               14    Ending Version TN     3034401009               15    Starting Version ID     1000000000               16    Ending Version ID     1000000009                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-31    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value               subscriptionVersionRangeAttributeValueChange (* if not a consecutive list)               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     15               5    Object ID     14               6    New Service Provider Creation Time Stamp     20050518231625               7    New Service Provider Due Date     20050530230000               8    Old Service Provider Authorization Time Stamp                   9    Old Service Provider Due Date                   10    Old Service Provider Authorization                   11    Conflict Time Stamp                   12    Range Type Format     2               13    Starting Version TN     3034401000               14    Ending Version TN     3034401009                       Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-32    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     15    Variable Field Length     Indicates the number of dynamic values for the following field (e.g. 10).               16    Version ID     1000000000               17    Version ID     1000000013               18    ... Version ID “n”     1000000016               subscriptionAudit-DiscrepancyRpt                   1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     2               5    Object ID     19               6    Service Provider ID     0001               7    Audit Failure Reason     2               8    Audit Discrepancy TN     3034401212               9    Version ID     1000000009               subscriptionAuditResults                   1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     3               5    Object ID     19               6    Audit Results Status     2                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-33    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     7    Number of Discrepancies     1               8    Time of Completion     20050521121419               9    Variable Field Length     Indicates the number of dynamic values for the following field (e.g. 3)                         Note: If there aren’t any Service Providers on the Failed list then the last field will be Time of Completion.               10    Failed Service Provider ID – Failed Service Provider Name     2091-TelX               11    Failed Service Provider ID – Failed Service Provider Name     3124-TelN               12    Failed Service Provider ID – Failed Service Provider Name     3092-TelY               subscriptionAudit-objectCreation                   1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     1006               5    Object ID     19               6    Audit ID     5303               subscription Audit-objectDeletion                   1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     1007                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-34    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     5    Object ID     19               6    Audit ID     5049               lnpNPAC-SMS-Operational-Information               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     0001               3    System Type     0               4    Notification ID     1               5    Object ID     12               6    Maintenance Start Time     20050530020000               7    Maintenance End Time     20050530060000               8    NPAC Contact Number     8883321000               9    Additional Downtime Information     (graphic string 255)               subscriptionVersionNewNPA-NXX               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     0001               3    System Type     0               4    Notification ID     8               5    Object ID     (21/12)                         * If this notification is generated by a subscription, then object ID= 21. If this notification is generated by a number pool block, then object ID=12.               6    NPA-NXX ID     2853               7    NPA-NXX     303440                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-35    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     8    NPA-NXX Effective Time Stamp     19960101155555               9    Service Provider ID     1003               subscriptionVersionOldSPFinalConcurrenceWindowExpiration               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     0001               3    System Type     0               4    Notification ID     12               5    Object ID     21               6    Subscription Timer Type     0               7    Subscription Business Type     1               8    Version TN     3034401000               9    Version ID     1234567890                         subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration (* if a consecutive list)               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     21               5    Object ID     14               6    Subscription Timer Type     0               7    Subscription Business Type     1               8    Range Type Format     1               9    Starting Version TN     3034401000                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-36    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     10    Ending Version TN     3034401009               11    Starting Version ID     1234567000               12    Ending Version ID     1234567010                         subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration (* if not a consecutive list)               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     21               5    Object ID     14               6    Subscription Timer Type     0               7    Subscription Business Type     1               8    Range Type Format     2               9    Starting Version TN     3034401000               10    Ending Version TN     3034401009               11    Variable Field Length     Indicates the number of dynamic values for the following field (e.g. 10).               12    Version ID     1230000000               13    Version ID     1230000012               14    Version ID     1230000019               15    ... Version ID “n”     1230000024               numberPoolBlock-objectCreation               1    Creation TimeStamp     For example: 19960101155555                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-37    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     2    Service Provider ID     1003               3    System Type     0               4    Notification ID     1006               5    Object ID     30               6    Number Pool Block Creation Time Stamp     20050501122000               7    Number Pool Block ID     4421               8    Number Pool Block NPA-NXX-X     3033005               9    Block Holder SPID     0001               10    SOA Origination     1               11    LRN     7193000000               12    CLASS DPC     123123123 (This value is 3 octets)               13    CLASS SSN     123 (This value is 1 octet and usually set to 000)               14    LIDB DPC     123123123 (This value is 3 octets)               15    LIDB SSN     123 (This value is 1 octet and usually set to 000)               16    CNAM DPC     123123123 (This value is 3 octets)               17    CNAM SSN     123 (This value is 1 octet and usually set to 000)               18    ISVM DPC     123123123 (This value is 3 octets)               19    ISVM SSN     123 (This value is 1 octet and usually set to 000)               20    WSMSC DPC     123123123 (This value is 3 octets)               21    WSMSC SSN     123 (This value is 1 octet and usually set to 000)               22    Number Pool Block Status     1                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-38    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     numberPoolBlock-attributeValueChange               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     1001               5    Object ID     30               6    Number Pool Block ID     1290               7    Number Pool Block NPA-NXX-X     3033006               8    SOA Origination     1               9    LRN     7193000000               10    CLASS DPC     123123123 (This value is 3 octets)               11    CLASS SSN     123 (This value is 1 octet and usually set to 000)               12    LIDB DPC     123123123 (This value is 3 octets)               13    LIDB SSN     123 (This value is 1 octet and usually set to 000)               14    CNAM DPC     123123123 (This value is 3 octets)               15    CNAM SSN     123 (This value is 1 octet and usually set to 000)               6    ISVM DPC     123123123 (This value is 3 octets)               17    ISVM SSN     123 (This value is 1 octet and usually set to 000)                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-39    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     18    WSMSC DPC     123123123 (This value is 3 octets)               19    WSMSC SSN     123 (This value is 1 octet and usually set to 000)               numberPoolBlockStatusAttributeValueChange               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     13               5    Object ID     30               6    Number Pool Block ID     3240               7    Number Pool Block NPA-NXX-X     3033006               8    Block Status     4               9    Variable Field Length     Indicates the number of dynamic values for the following field (e.g. 3).                         Note: If there aren’t any Service Providers on the Failed list then the last field will be the Block Status.               10    (failed list) Service Provider ID — Service Provider Name     2003-TelCo               11    (failed list) Service Provider ID — Service Provider Name     2910-Tel S               12    ...     1034-Tel M               subscriptionVersionNewSP-FinalCreateWindowExpiration               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     0001                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-40    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     3    System Type     0               4    Notification ID     23               5    Object ID     21               6    New Current Service Provider ID     1234               7    Old Service Provider ID     2001               8    Old Service Provider Due Date     20050530230000               9    Old SP Authorization     0               10    Old SP Authorization Time Stamp     20050520125032               11    Status Change Cause Code     50               12    Subscription Timer Type     0               13    Subscription Business Type     1               14    Version TN     1232201999               15    Version ID     1234567890                         subscriptionVersionRangeNewSP-FinalCreateWindow (* if a consecutive list)               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     22               5    Object ID     14               6    New Current Service Provider ID     1234               7    Old Service Provider ID     2001               8    Old Service Provider Due Date     20050530230000                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-41    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     9    Old Service Provider Authorization     0               10    Old Service Provider Authorization Time Stamp     20050520123045               11    Status Change Cause Code     50               12    Subscription Timer Type     0               13    Subscription Business Type     1               14    Range Type Format     1               15    Starting Version TN     3034401000               16    Ending Version TN     3034401009               17    Starting Version ID     1234567000               18    Ending Version ID     1234567010                         subscriptionVersionRangeNewSP-FinalCreateWindowExpiration (* if not a consecutive list)               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     0               4    Notification ID     22               5    Object ID     14               6    New Current Service Provider ID     1234               7    Old Service Provider ID     2001               8    Old Service Provider Due Date     20050530230000               9    Old Service Provider Authorization     0               10    Old Service Provider Authorization TimeStamp     20050530231632                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-42    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     11    Status Change Cause Code     50               12    Subscription Timer Type     0               13    Subscription Business Type     1               14    Range Type Format     2               15    Starting Version TN     3034401000               16    Ending Version TN     3034401009               17    Variable Field Length     Indicates the number of dynamic values for the following field (e.g. 10).               18    Version ID     2340000000               19    Version ID     2340000016               20    ... Version ID “n”     2340000023               LSMS Notifications                   lnpNPAC-SMS-Operational-Information               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     0001               3    System Type     1               4    Notification ID     1               5    Object ID     12               6    Maintenance Start Time     20050530020000               7    Maintenance End Time     20050530060000               8    NPAC Contact Number     8883321000               9    Additional Download Time Information     (graphic string 255)                           Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-43    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         EXPLANATION OF THE POTENTIAL NOTIFICATION FIELDS IN THE NOTIFICATIONS DOWNLOAD FILE  Notification                  Field           Number   Field Name   Sample Value     subscriptionVersionNewNPA-NXX               1    Creation TimeStamp     For example: 19960101155555               2    Service Provider ID     1003               3    System Type     1               4    Notification ID     8               5    Object ID     (21/12) (If this notification is generated by a subscription version, then Object ID=21. If this notification is generated by a pooled block, then Object ID=12.               6    NPA-NXX ID     1239               7    NPA-NXX     303400               8    NPA-NXX Effective Time Stamp     050501120019               9    Service Provider ID     0001     Figure E- 8 — Notification Download File Example                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-44    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         SIC-SMURF NPA-NXX Download File  The SIC-SMURF NPA-NXX download file is used as input to the SPID migration update process in the NPAC SMS and all SOAs/LSMSs, to convert NPA-NXX data from the Old SPID to the New SPID. This file contains individual fields that are pipe delimited, with a carriage return (CR) after each SIC-SMURF NPA-NXX record.  The file name for the SIC-SMURF NPA-NXX download file will be in the format:       SIC-SMURF-NPANXX.OldSPID.NewSPID.DD-MM-YYYYHHMMSS (The SIC-SMURF-NPANXX portion is the literal string “SIC-SMURF-NPANXX”. The OldSPID is the four digit ID of the Old Service Provider. The NewSPID is the four digit ID of the New Service Provider.)  The SIC-SMURF NPA-NXX file given in the example would be named:        SIC-SMURF-NPANXX.0001.0002.25-12-1996081122  EXPLANATION OF THE FIELDS IN THE SIC-SMURF NPA-NXX DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Old Service Provider Id   0001               2   New Service Provider Id   0002               3   NPA-NXX Value   312382     Example File:                                0001|0002|312382(CR)                     (end of NPA-NXX 1)                                0001|0002|312383(CR)                     (end of NPA-NXX 2)                                0001|0002|312386(CR)                     (end of NPA-NXX 3)                                0001|0002|312382(CR)                     (end of NPA-NXX 4)                                0001|0002|312392(CR)                     (end of NPA-NXX 5)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-45    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         SIC-SMURF LRN Download File  The SIC-SMURF LRN download file is used as input to the SPID migration update process in the NPAC SMS and all SOAs/LSMSs, to convert LRN, Block (SOA/LSMS optional), Subscription Version, and scheduled event for Block (NPAC only) data from the Old SPID to the New SPID. This file contains individual fields that are pipe delimited, with a carriage return (CR) after each SIC-SMURF LRN record.  The file name for the SIC-SMURF LRN download file will be in the format:       SIC-SMURF-LRN.OldSPID.NewSPID.DD-MM-YYYYHHMMSS (The SIC-SMURF-LRN portion is the literal string “SIC-SMURF-LRN”. The OldSPID is the four digit ID of the Old Service Provider. The NewSPID is the four digit ID of the New Service Provider.)  The SIC-SMURF-LRN file given in the example would be named:        SIC-SMURF-LRN.0001.0002.25-12-1996081122  EXPLANATION OF THE FIELDS IN THE SIC-SMURF LRN DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Old Service Provider Id   0001               2   New Service Provider Id   0002               3   LRN Value   3123820000     Example File:                                0001|0002|3123820000 (CR)                      (end of LRN 1)                                0001|0002|3123830000 (CR)                      (end of LRN 2)                                0001|0002|3123860000 (CR)                      (end of LRN 3)                                0001|0002|3123820000 (CR)                      (end of LRN 4)                                0001|0002|3123920000 (CR)                      (end of LRN 5)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-46    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Download File Examples         SIC-SMURF NPA-NXX-X Download File  The SIC-SMURF NPA-NXX-X download file is used as input to the SPID migration update process in the NPAC SMS and all SOAs/LSMSs, to convert NPA-NXX-X data (SOA/LSMS optional) from the Old SPID to the New SPID. This file contains individual fields that are pipe delimited, with a carriage return (CR) after each SIC-SMURF NPA-NXX-X record.  The file name for the SIC-SMURF NPA-NXX-X download file will be in the format:       SIC-SMURF-NPANXXX.OldSPID.NewSPID.DD-MM-YYYYHHMMSS (The SIC-SMURF-NPANXXX portion is the literal string “SIC-SMURF-NPANXXX”. The OldSPID is the four digit ID of the Old Service Provider. The NewSPID is the four digit ID of the New Service Provider.)  The SIC-SMURF-NPA-NXX-X file given in the example would be named:        SIC-SMURF-NPANXXX.0001.0002.25-12-1996081122  EXPLANATION OF THE FIELDS IN THE SIC-SMURF NPA-NXX-X DOWNLOAD FILE                  Field           Number   Field Name   Value in Example     1   Old Service Provider Id   0001               2   New Service Provider Id   0002               3   NPA-NXX-X Value   3123820     Example File:                                0001|0002|3123820(CR)                     (end of NPA-NXX-X 1)                                0001|0002|3123824(CR)                     (end of NPA-NXX-X 2)                                0001|0002|3123862(CR)                     (end of NPA-NXX-X 3)                                0001|0002|3123868(CR)                      (end of NPA-NXX-X 4)                                0001|0002|3123928(CR)                      (end of NPA-NXX-X 5)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    E-47    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Midwest Region Number Pooling         Appendix F. Midwest Region                            Number Pooling  This section, Appendix F: Midwest Region Number Pooling is deleted in version 3.0.0 of this document with NPAC Release 3.0.0.                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    F-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         Appendix G. Deleted Requirements  This section contains a list of assumption/constraint/requirement numbers that have been deleted over the lifetime of this document.  AR5-1 (Duplicates R5-25) AR4-1.1 AR6-1 AR6-2 A10-1 A10-2 A10-3 A11-1 CN1-1 R3-l R3-2 RX3-2 R3-4.1 (Duplicate — refer to R4-1) R3-4.2 (Duplicate — refer to R4-3) R3-5 (Duplicate — refer to R4-2) RR3-11 (Replaced with RR3-229, RR3-230, RR3-231, and RR3-232) RR3-30 (Replaced with RR3-233, RR3-234, RR3-235, and RR3-236) R3-6.1 (Duplicate – refer to R3-7.2) R3-12 (Duplicate – refer to R5-18) RN3-4.10 RN3-4.3 RN3-4.36 RN3-4.37 RN 3-4.4 RN3-4.5 RN3-4.19 RN 3-4.29 RN3-4.33 RN3-4.34 RN3-4.35 RR3-51.1                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         RR3-51.2 RR3-64 RR3-90 RR3-91 RR3-92 RR3-98 RR3-99 RR3-100 RR3-141.2 RR3-167 RR3-168 RR3-178 RR3-179 RR3-208 (Merged into R3-7.1) RR3-209 (Merged into R3-7.1) RR3-226 RR3-470 RR3-471 R4-12 (Duplicate – refer to R4-2) R4-18.1 R4-18.2 R4-18.3 R4-19 (Duplicate – refer to R4-3) R4-23 (Duplicate – refer to R4-5.2) R4-30.3 R4-30.4 R4-30.5 R4-30.7 R5-1.2 – (Duplicate refer to R5-20.3, R5-30.2, R5-53), R5-54, moved refer to R5-54.2) R5-3.7 R5-3.8 R5-3.9 R5-4 (Duplicate – refer to RN5-1) RR5-6.3 R5-8.2 (Duplicate – refer to R5-25) RN5-9                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-2    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         RR5-10.4 RR5-10.5 RN5-11 (Duplicate – refer to R5-42 and R5-43) RR5-12.2 RR5-13.1 RR5-13.2 RR5-15.1 RR5-15.2 RR5-16.1 R5-17.1 (Duplicate – refer to R5-18.8 and R5-20.1) R5-17.2 (Duplicate – refer to R5-18.8 and R5-20.1) RR5-16.2 RR5-17.1 RR5-17.2 RR5-17.3 RR5-17.4 RR5-18.1 RR5-18.2 R5-18.3 RR5-18.3 RR5-19 RR5-20 R5-21.5 (Duplicate – refer to R5-21.1) R5-23.4 R5-24.1 (Duplicate – refer to R5-27 and R5-28) R5-24.2 (Duplicate – refer to R5-27 and R5-28) R5-24.3 (Duplicate – refer to R5-27 and R5-28) RR5-26.2 R5-27.5 (Duplicate – refer to RR5-42.1) RR5-28.2 R5-29.2 R5-31.1 R5-31.2 R5-32 (Duplicate – refer to R5-31.3) R5-33 (Duplicate – refer to R5-35 and R5-36) R5-34                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-3    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         R5-40.2 (Duplicate – refer to R5-34) RR5-43 Activation with Old Service Provider Authorization RR5-44 RR5-45 RR5-46 RR5-47 R5-48 RR5-48 RR5-49 R5-49.1 R5-49.2 RR5-54 R5-54.1 R5-54.2 R5-56 (Duplicate – refer to R5-57.1) R5-64.2 R5-64.3 R5-64.4 R5-64.5 R5-64.6 R5-64.7 R5-65.3 R5-66.1 R5-71.1 (Superseded – refer to RR5-28) R5-71.7 RR5-131 RR5-132 RR5-133 RR5-134 RR5-135 RR5-146 RR5-148 R6-1 R6-2.1 R6-2.2 R6-3                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-4    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         RX6-3.1 RR6-6 (Duplicate – refer to R10-10.1) RR6-7 (Duplicate – refer to R10-10.1) RR6-10 RR6-11 (Duplicate — refer to RX6-2.5) RR6-12 (moved to RX6-2.6) R6-10.1 R6-10.2 R6-10.3 R6-11 R6-12 R6-13 R6-14.1 R6-14.2 R6-15.1 R6-15.2 R6-15.3 R6-16.1 R6-16.2 R6-17.1 R6-17.2 R6-17.3 R6-18.1 R6-18.2 R6-18.3 R6-19 R6-20.1 R6-20.2 R6-20.3 R6-21 R6-29.1 R6-30.3 R6-31 R6-32 R6-33 R6-34                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-5    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         R6-4.1 R6-4.2 R6-4.3 R6-5.1 R6-5.2 R6-6.1 R6-6.2 R6-7.1 R6-7.2 R6-8.1 R6-8.2 R6-9.1 R6-9.2 R6-9.3 RR6-119 RR6-120 RR6-121 RR6-181 R7-11 (Duplicate – refer to R7-10) R7-17 (Duplicate – refer to R7-15) R7-30 (Duplicate – refer to R7-10) R7-45 (Duplicate – refer to R7-47) R7-59 (Duplicate – refer to R7-53.3) R7-62.1 (Duplicate – refer R7-12) R7-62.2 (Duplicate – refer to R7-12) R7-71.1 R7-101.1 R7-101.2 (Duplicate – refer to R7-91.1) R7-101.3 (Duplicate – refer to R7-91.2) R7-101.4 (Duplicate – refer to R7-91.3) R7-101.5 (Duplicate – refer to R7-91.4) R7-105.1 (Duplicate – refer to R7-97 and R7-98) R7-110.2 (Duplicate – refer to R7-107.2) R8-2.2 R8-5.2 R8-6.2                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-6    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Deleted Requirements         R8-7.1 R8-7.2 R8-7.3 R8-8 R8-13 R8-14.1 R8-14.2 R8-16.2 R8-16.3 R8-16.4 R8-18 (Duplicate – refer to R8-7.3) R8-24 (Duplicate – refer to R9-2) R9-7 R9-8 (Duplicate – refer to R9-2) R9-12.3 (Duplicate – refer to RX9-5 number 20) R9-13 (Duplicate – refer to R9-2) RR9-5 RR9-6 RN10-1 R10-15 R10-17 R11-7 (Duplicate – refer to RX11-5)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    G-7    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             Release Migration         Appendix H. Release Migration  This section contains a list of requirements (in the format Rel3-seq #) that are specific to the NPAC SMS migration from Release 2.0 to Release 3.0. Once the NPAC SMS has migrated all applicable production data to the new release, these requirements will expire, and will no longer be required functionality for the NPAC SMS.  Rel3-1 National Number Pooling Migration – Conversion of Blocks for 1.4 Pooling  NPAC SMS shall provide a mechanism for Pooled Data in a pre-EDR environment, to be converted to Pooled Data in an EDR environment, prior to the live date for the National Number Pooling Release in the NPAC SMS.  Note: The Subscription Versions with LNP Type of POOL will remain in the NPAC SMS, and a corresponding NPA-NXX-X and EDR Block will be created in the NPAC SMS, but will not be broadcast over the Interface. (Previously M-10)  Rel3-2 National Number Pooling Migration – Setting of NPA-NXX-X Indicators  NPAC SMS shall provide a mechanism for the NPAC Customer SOA NPA-NXX-X Indicator and the NPAC Customer LSMS NPA-NXX-X Indicator, in the NPAC Customer Data Model, to be set for all Service Providers, prior to the live date for the National Number Pooling Release in the NPAC SMS. (Previously M-20)  Rel3-3 National Number Pooling Migration – Setting of EDR Indicators  NPAC SMS shall provide a mechanism for the NPAC Customer LSMS EDR Indicator, in the NPAC Customer Data Model, to be set for all Service Providers, prior to the live date for the National Number Pooling Release. (Previously M-30)                        Release 3.3: © 1997 — 2006 NeuStar, Inc.    H-1    North American Numbering Council (NANC)            Functional Requirements Specification Release 3.3.2a                   Freely distributable subject to the terms of the GNU GPL, see inside cover notice.    March 9, 2006             EX-99.2 15 w17665exv99w2.htm EX-99.2    exv99w2       Exhibit 99.2    NPAC SMS INTEROPERABLE INTERFACE SPECIFICATION  NANC Version 3.3.2a  Prepared for: The North American Numbering Council (NANC)   March 9, 2006     Release 3.3: © 1997 — 2006 NeuStar, Inc.  The Work is subject to the terms of the GNU General Public License (the “GPL”), a copy of which may be found at ftp://prep.ai.mit.edu/pub/gnu/GPL. Any use of this Work is subject to the terms of the GPL. The “Work” covered by the GPL by operation of this notice and license is this document and any and all modifications to or derivatives of this document. Where the words “Program,” “software,” “source code,” “code,” or “files” are used in the GPL, users understand and agree that the “Work” as defined here is substituted for purposes of this notice and license.           This page intentionally left blank.          Table of Contents    Table Of Contents                    1 Introduction     1                 1.1 Document Overview     1                 1.2 How To Use This Document     1                 1.3 Document Numbering Strategy     1                 1.4 Document Version History     2     1.4.1 Release 1.0     2     1.4.2 Release 2.0     2     1.4.3 Release 3.0     3     1.4.4 Release 3.1     3     1.4.5 Release 3.2     3     1.4.6 Release 3.3     3                 1.5 References     4     1.5.1 Standards     4     1.5.2 Related Publications     5                 1.6 Abbreviations/Definitions     6                 2 Interface Overview     9                 2.1 Overview     9                 2.2 OSI Protocol Support     9                 2.3 SOA to NPAC SMS Interface     10     2.3.1 Subscription Administration     10     2.3.2 Audit Requests     10     2.3.3 Notifications     11     2.3.4 Service Provider Data Administration     12     2.3.5 Network Data Download     12     2.3.6 Number Pool Block Administration     12                 2.4 NPAC SMS to Local SMS Interface     12     2.4.1 Subscription Version, Number Pool Block and Network Data Download     13     2.4.2 Service Provider Data Administration     13     2.4.3 Notifications     13                 3 Hierarchy Diagrams     15                 3.1 Overview     15     3.1.1 Managed Object Model Inheritance Hierarchy     15     3.1.2 Log Record Managed Object Hierarchy     16     3.1.3 NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS     17     3.1.4 NPAC SMS to Local SMS Naming Hierarchy for the Local SMS     18     3.1.5 SOA to NPAC SMS Naming Hierarchy for the NPAC SMS     19     3.1.6 NPAC SMS to SOA Naming Hierarchy for the SOA     20                 4 Interface Functionality to CMIP Definition Mapping     21                 4.1 Overview     21     4.1.1 Primary NPAC Mechanized Interface Operations     21     4.1.2 Managed Object Interface Functionality     25     4.1.3 Action Interface Functionality     29                                 March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.  1                   Table of Contents                      4.1.4 Notification Interface Functionality     30                 4.2 Scoping and Filtering Support     34     4.2.1 Scoping     34     4.2.2 Filtering     34     4.2.3 Action Scoping and Filtering Support     37                 4.3 lnpLocal-SMS-Name and lnpNPAC-SMS-Name Values     37                 4.4 OID Usage Information     37     4.4.1 OIDs Used for Bind Requests     37     4.4.2 Other OIDs of Interest     38                 4.5 Naming Attributes     38                 4.6 Subscription Version M_DELETE Messages     38                 4.7 Number Pool Block M_DELETE Messages     38                 4.8 Subscription Version Queries     38                 5 Secure Association Establishment     41                 5.1 Overview     41                 5.2 Security     41     5.2.1 Authentication and Access Control Information     41     5.2.1.1 System Id     43     5.2.1.2 System Type     43     5.2.1.3 User Id     43     5.2.1.4 List Id     43     5.2.1.5 Key Id     44     5.2.1.6 CMIP Departure Time     45     5.2.1.7 Sequence Number     45     5.2.1.8 Association Functions     45     5.2.1.9 Recovery Mode     47     5.2.1.10 Signature     47     5.2.2 Association Establishment     47     5.2.3 Data Origination Authentication     49     5.2.4 Audit Trail     51                 5.3 Association Management and Recovery     52     5.3.1 Establishing Associations     52     5.3.1.1 NpacAssociationUserInfo     52     5.3.1.2 Unbind Requests and Responses     52     5.3.1.3 Aborts     53     5.3.1.4 NPAC SMS Failover Behavior     53     5.3.1.5 Service Provider SOA and Local SMS Procedures     53     5.3.2 Releasing or Aborting Associations     54     5.3.3 Error Handling     55     5.3.3.1 NPAC SMS Error Handling     55     5.3.3.2 Processing Failure Error     55     5.3.3.3 NPAC SMS Detailed Error Codes     56     5.3.4 Recovery     56     5.3.4.1 Local SMS Recovery     61     5.3.4.2 SOA Recovery     61     5.3.4.3 Linked Action Replies during Recovery     61                 5.4 Congestion Handling     63                                 March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.      2                   Table of Contents                      5.4.1 NPAC SMS Congestion     63     5.4.2 NPAC Handling of Local SMS and SOA Congestion     63     5.4.3 Out-Bound Flow Control     64                 5.5 Abort Processing Behavior     64                 5.6 Single Association for SOA/LSMS     65                 5.7 Separate SOA Channel for Notifications     65                 6 GDMO Definitions     67                 7 General ASN.1 Definitions     69                 8 LNP XML Schema     70                 9 Subscription Version Status     71                 10 Number Pool Block Status     75                 Appendix A: Errors     A-1     Appendix B: Message Flow Diagrams     B-1                                 March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.      3                   Introduction    1 Introduction  [Graphic Omitted: 1]     1.1   Document Overview    The NPAC SMS Interoperable Interface Specification contains the information model for the Number Portability Administration Center and Service Management System (NPAC SMS) mechanized interfaces. Both Service Order Activation (SOA) and Local Service Management System (LSMS or Local SMS) interfaces to the NPAC SMS are described in this document.     1.2   How To Use This Document    The NPAC SMS Interoperable Interface Specification contains the following sections:  Section 1 Introduction — This section describes the conventions and organization of this document. It also lists related documentation.  Section 2 Interface Overview — This section contains an overview of protocol requirements and a brief description of the functionality provided in each interface.  Section 3 Hierarchy Diagrams — This section contains the class hierarchy diagrams for all managed objects defined in the interoperable interface.  Section 4 Interface Functionality to CMOP Definition Mapping — This section contains the mapping of the interface functionality to the managed objects, attributes, actions, and notifications.  Section 5 Secure Association Establishment— This section contains information on secure association establishment  Section 6 GDMO Definitions — This section contains the GDMO interface definitions supporting the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface  Section 7 General ASN.1 Definitions — This section contains the ASN.1 definitions that support the GDMO definitions in Section 7.  Section 8 Subscription Version Status — This section contains a Subscription Version Status diagram, which illustrates the transition from one subscription version state to another.  Appendix A Errors — This appendix contains the valid errors associated with CMISE confirmed primitives used in the interoperable interface definitions.   Appendix B Message Flow Diagrams — This appendix contains the message flow diagrams.  Appendix C Midwest Region Number Pooling Message Flow Diagrams — This appendix is deleted in Release 3.0.0.     1.3   Document Numbering Strategy    Starting with Release 2.0 the documentation number of the IIS document will be Version X.Y.Z as follows:       X –    will only be incremented when a new major release of the NPAC SMS system is authorized. It will contain only the Change Orders that have been authorized for                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  1                   Introduction           inclusion in this new major release.         Y –    will only be incremented when a new sub-release of an existing release X is authorized. It will contain only the Change Orders that have been authorized for inclusion in this new sub-release.        Z –    will be incremented when documentation only clarifications and/or backward compatibility issues or other deficiency corrections are made in the IIS and/or FRS. This number will be reset to 0 when Y is incremented.    For example, the first release of the Release 2 IIS will be numbered 2.0.0. If documentation only clarifications are introduced in the next release of the IIS document it will be numbered 2.0.1. If requirements are added to Release 2.0 that require NPAC SMS software changes then the next release of the IIS document will be numbered 2.1.0.  Starting with Release 3.2, the documentation number of the FRS document will include a “lowercase letter” following the Z designation. This “lowercase letter” will essentially serve as a version indicator for the release of the documentation, such that the X.Y.Za will be a unique identifier. It will be used for both drafts and final versions. For example, the first release using this new convention will be 3.2.0a, followed by 3.2.0b, and so on. . The “lower case letter” shall be reset to ‘a’ when Z is incremented.  This number scheme is intended to make the mapping between NPAC SMS and the FRS and IIS documentation consistent.     1.4   Document Version History      1.4.1   Release 1.0    NANC Version 1.0, released on 04/07/97, contains changes from the ICC Subcommittee IIS Version 1.1.5.  NANC Version 1.1, released on 05/08/97, contains changes from the NANC IIS Version 1.0.  NANC Version 1.2, released on 05/25/97, contains changes from the NANC IIS Version 1.1.  NANC Version 1.3, released on 07/09/97, contains changes from the NANC IIS Version 1.2.  NANC Version 1.4, released on 08/08/97, contains changes from the NANC IIS Version 1.3.  NANC Version 1.5, released on 09/09/97, contains changes from the NANC IIS Version 1.4.  NANC Version 1.6, released on 11/12/97, contains changes from the NANC IIS Version 1.5.  NANC Version 1.7, released on 12/12/97, contains changes from the NANC IIS Version 1.6.  NANC Version 1.8, released on 2/11/98, contains changes from the NANC IIS Version 1.7.  NANC Version 1.9, released on 5/13/98, contains changes from the NANC IIS Version 1.8.  NANC Version 1.10, released on 7/8/98, contains changes from the NANC IIS Version 1.9.     1.4.2   Release 2.0    NANC Version 2.0.0, released on 12/14/98, contains changes from the NANC IIS Version 1.10.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  2                   Introduction    NANC Version 2.0.1, released on 2/25/99, contains changes from the NANC IIS Version 2.0.0.  NANC Version 2.0.2, released on 9/1/99, contains changes from the NANC IIS Version 2.0.1.     1.4.3   Release 3.0    NANC Version 3.0.0, released on 1/28/00 and 2/14/00 (revised version), contains changes from the NANC IIS Version 2.0.2.  NANC Version 3.0.1, released on 6/6/00, contains changes from the NANC IIS Version 3.0.0.  NANC Version 3.0.2, released on 9/11/00, contains changes from the NANC IIS Version 3.0.0.     1.4.4   Release 3.1    NANC Version 3.1.0, released on 8/24/01, contains changes from the NANC IIS Version 3.0.2.     1.4.5   Release 3.2    NANC Version 3.2.0, released on 8/27/02, contains changes from the NANC IIS Version 3.1.0  NANC Version 3.2.1a, released on 7/28/03, contains changes from the NANC IIS Version 3.2.0  NANC Version 3.2.2a, released on 6/30/04, contains changes from the NANC IIS Version 3.2.1a.  1.4.6 Release 3.3  NANC Version 3.3.0a, released on 4/25/05, contains changes from the NANC IIS Version 3.2.2a.  NANC Version 3.3.0b, released on 5/27/05, contains changes from the NANC IIS Version 3.3.0a.  NANC Version 3.3.0c, released on 6/22/05, contains changes from the NANC IIS Version 3.3.0b.  NANC Version 3.3.0d, released on 7/29/05, contains changes from the NANC IIS Version 3.3.0c.  NANC Version 3.3.1a, release on 10/14/05 contains documentation changes from the NANC IIS Version 3.3.0d.  NANC Version 3.3.2a, release on 3/9/2006 contains the following documentation changes from the NANC IIS Version 3.3.1a:       •   Documentation only changes contained in Change Order NANC 407 NPAC Range Operations and Associated Notifications                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  3                   Introduction            Documentation only changes contained in Change Order NANC 410 Doc Only Change Order: IIS    NOTE: With Release 3.3 of the NPAC SMS, new functionality related to SV Type and Optional Data (Alternative SPID) for a subscription version and number pool block, is implemented but is currently inactive in all NPAC Regions. Many existing flows in the IIS are impacted with the implementation of SV Type and Alternative SPID and can be identified by references “SVType” and “AlternativeSPID”. Until NAPM LLC approval, this functionality will remain inactive in the NPAC SMS system.     1.5   References      1.5.1   Standards    ANSI T1.224-1992, Operations, Administration, Maintenance, and Provisioning (OAM&P) — Protocols for Interfaces between Operations Systems in Different Jurisdictions.  ANSI T1.243-1995, Telecommunications, Operations, Administration, Maintenance and Provisioning (OAM&P) — Baseline Security Requirements for the Telecommunications Management Network (TMN).  ANSI T1.246, Operations, Administration, Maintenance and Provisioning (OAM&P) — Information Model and Services for Interfaces between Operations Systems across Jurisdictional Boundaries to Support Configuration Management - - Customer Account Record Exchange (CARE).  Bellcore TA- 1253, Generic Requirements for Operations Interfaces Using OSI Tools: Network Element Security Administration.  Committee T1 Technical Report No, 40, Security Requirements for Electronic Bonding Between Two TMNs.  ISO/IEC 11183-1:1992, Information Technology — International Standardized Profiles AOM ln OSI Management — Management Communications — Part 1 Specification of ACSE, Presentation and Session Protocols for the use by ROSE and CMISE.  ISO/IEC 11183-2:1992, Information Technology — International Standardized Profiles AOM ln OSI Management — Management Communications — Part 2: CMISE/ROSE for AOM12 — Enhanced Management Communications.  ISO/IEC 11183-3:1992, Information Technology — International Standardized Profiles AOM ln OSI Management — Management Communications — Part 3: CMISE/ROSE for AOM12 — Basic Management Communications.  ITU X.509, Information Technology — Open Systems Interconnection — The Directory Authentication Framework.  ITU X.690/ISO IS 8825-1 Annex D, ASNI/BER Encoding of Digital Signatures and Encrypted Cyphertext.  ITU X.741, OSI Systems Management, Objects and Attributes for Access Control  ITU X.803, Upper Layers Security Model.  NMF Forum 016, Issue 1.0, 1992, OMNIPoint 1 Specifications and Technical Reports, Application Services Security of Management.  OIW Stable Implementation Agreement, Part 12, 1995.  Rec. M.3100:1992 & 1995 draft, Generic Network Information Model.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  4                   Introduction    Rec. X.701 | ISO/IEC 10040:1992, Information Technology — Open System Interconnection — Common Management Overview.  Rec. X.710 | ISO/IEC 9595:1990, Information Technology — Open System Interconnection — Common Management Information Service Definitions.  Rec. X.711 | ISO/IEC 9596-1:1991, Information Technology — Open System Interconnection — Common Management Information Protocol — Part 1: Specification.  Rec. X.720 | ISO/IEC 10165-1:1991, Information Technology — Open System Interconnection — Structure of Management Information — Part 1 Management Information Model.  Rec. X.721 | ISO/IEC 10165-2:1992, Information Technology — Open System Interconnection — Structure of Management Information: Guidelines for the Definition of Managed Objects.  Rec. X.722 | ISO/IEC 10165-4:1992, Information Technology — Open System Interconnection — Structure of Management Information: Guidelines for the Definition of Managed Objects.  Rec. X.730 | ISO/10164-1:1992, Information Technology — Open System Interconnection — System Management — Part 1: Object Management Function.  Rec. X.734 | ISO/10164-5:1992, Information Technology — Open System Interconnection — System Management — Part 5: Event Report Management Function.  Rec. X.735 | ISO/10164-6:1992, Information Technology — Open System Interconnection — System Management — Part 6: Log Control Function.  Rec. X.209: 1988, Specification for Basic Encoding Rules for Abstract Syntax Notation One (ANS.1).  Rec. X.690: 1994, ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER).  Rec. X.208: 1988, Specification of Abstract Syntax Notation One (ASN.1).  Rec. X.680 | ISO/IEC 8824-1: 1994, Information Technology — Abstract Syntax Notation One (ASN.1) — Specification of Basic Notation.  Rec. X.680 Amd.1 | ISO/IEC 8824-1 Amd.1, Information Technology — Abstract Syntax Notation One (ASN.1) — Specification of Basic Notation 1 Amendment 1: Rules of Extensibility.  ITU-T Recommendations are available from the US Department of Commerce, National Technical Information Service, 5285 Port Royal Road, Springfield, VA 22161. ISO standard are available from the American National Standards Institute, 11 West 42nd Street, New York, NY 10036.     1.5.2   Related Publications    Illinois Commerce Commission Number Portability Administration Center and Service Management System Request for Proposal (ICC NPAC/SMS RFP), February 6, 1996.  Lockheed Martin Team Response to the Illinois Commerce Commission Number Portability Administration Center and Management System Request for Proposal, March 18, 1996.  Scoggins, Sophia and Tang, Adrian 1992. Open networking with OSI. Englewood Cliffs, NJ, Prentice-Hall.  Stallings, William 1993. SNMP, SNMPv2, and CMIP, The Practical Guide to Network-Management Standards, Reading Massachusetts, Addison-Wesley.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  5                   Introduction    North American Number Council (NANC) Functional Requirements Specification, Number Portability Administration Center (NPAC), Service Management System (SMS), Version 3.3.2a March 9, 2006.  CTIA Report on Wireless Portability Version 2, July 7, 1998     1.6   Abbreviations/Definitions                           A-PDU    Application Protocol Data Unit        ASN.1    Abstract Syntax Notation 1        BER    Basic Encoding Rules        CARE    Customer Account Record Exchange        Central Time    This is the time in the central time zone, which includes daylight savings time.        (standard/daylight)    It changes twice a year based on standard time and daylight savings time. The NPAC SMS runs on hardware that uses this time.        CER    Canonical Encoding Rules        CLASS    Custom Local Area Signaling Services        CME    Conformance Management Entity        CMIP    Common Management Information Protocol        CMISE    Common Management Information Service Element        CNAM    Caller Id with Name        GDMO    Generalized Definitions of Managed Objects        DER    Distinguished Encoding Rules        DES    Data Encryption Standard        FR    Frame Relay        IEC    International Electrotechnical Commission        ISO    International Organization of Standardization        ISVM    Inter-Switch Voice Mail        Local Time    The time zone of the local user. Most time representations in the NPAC OP GUI are represented in the user’s local time zone based on the PC’s clock setting. The time zone label is included in time display in the GUI.                        EST for Eastern Time Zone                        CST for Central Time Zone                        MST for Mountain Time Zone                        PST for Pacific Time Zone                    LIDB    Line Information Database        LNP    Local Number Portability        LRN    Location Routing Number        LSMS    Local Service Management System        LSPP    Local Service Provider Portability        MAC    Media Access Control        MD5    Message Digest (Version 5)        MIB    Management Information Base        NE    Network Element        NMF    Network Management Forum        NPAC SMS    Number Portability Administration Center and Service Management System        NPA    Numbering Plan Area        NXX    Exchange        OCN OSI    Operating Company Number Open Systems Interconnect        PPP    Point-To-Point Protocol        RFP    Request for Proposal        RSA    Encryption Scheme                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  6                   Introduction                           SOA    Service Order Activation        SMS    Service Management System        TMN    Telecommunications Management Network        TN    Telephone Number        WSMSC    Wireless Short Message Service Center                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      7                   Interface Overview    2 Interface Overview  [Graphic Omitted: 2]     2.1   Overview    This specification defines the interfaces between the NPAC SMS and the service providers’ Service Order Entry System and Local SMS. The interfaces, defined using the CMIP protocol, are referred to as the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface respectively. CMISE M-CREATE, M-DELETE, M-SET, M-GET, M-EVENT-REPORT, and M-ACTION primitives are fully supported in a confirmed mode. Thus, the sequencing of operations is implied by the receipt of the confirmation or operation response, and NOT by the sequence that the operation request is received. The relationship from the SOA to the NPAC SMS and from the Local SMS to NPAC SMS is a manager to agent or an agent to manager relationship depending on the function being performed. The SOA and Local SMS interfaces are defined by Association Functions. These functions allow each association to define the services it supports. Association establishment from the SOAs and Local SMSs to the NPAC SMS, Association Function and security for each of these interfaces is discussed in Section 5, Secure Association Establishment.  Note: The M-CANCEL-GET primitive may not be supported in some NPAC SMS implementations due to the fact that this functionality was not determined necessary for the interface defined.  The sections that follow provide an overview of protocol requirements and a brief description of the functionality provided in each interface. Complete functional descriptions for the interfaces are provided in the process flow diagrams in Appendix B, Message Flow Diagrams, as well as the behavior for the managed objects.  The interface between the SOA and the NPAC SMS is called the “SOA to NPAC SMS interface”. The interface between the Local SMS and the NPAC SMS is called the “NPAC SMS to Local SMS interface”. No direction for operations is implied by the names of these interfaces.  All timestamps (GeneralizedTime fields) that are sent over the SOA to NPAC SMS interface and NPAC SMS to Local SMS interface, shall use Greenwich Mean Time (GMT). The universal time format (YYYYMMDDHHMMSS.0Z) is used. The default value is a non-specific format of 00000000000000.0Z.     2.2   OSI Protocol Support    The SOA to NPAC SMS and NPAC SMS to Local SMS interfaces must be implemented over the protocol stack shown in Exhibit 1.  Exhibit 1. NPAC/SMS Primary Network Protocol Stacks                  Layer   Mechanized Interface   Function              CMIP Agent Server    User   7    CMISE, ACSE, ROSE    Application   6    ANSI T1.224    Presentation   5    ANSI T1.224    Session   4    TCP, RFC1006, TPO    Transport   3    IP    Network                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.  8                   Interface Overview                      2    PPP, MAC, FRAME Relay, ATM (IEEE 802.3)    Link   1    DS-1, DS-0 x n, ISDN, V.34    Physical     Multiple associations per service provider to the NPAC SMS can be supported when using different function masks. The secure association establishment is described in Section 5.  2.3 SOA to NPAC SMS Interface  The SOA to NPAC SMS interface, which allows communication between a service provider’s Service Provisioning Operating Systems and/or Gateway systems and the NPAC SMS, supports the retrieval and update of subscription, service provider, and network information. The following transactions occur to support local number portability functionality:       •   SOA requests for subscription administration to the NPAC SMS and responses from the NPAC SMS to the SOA.        •   Audit requests from the SOA to the NPAC SMS and responses from the NPAC SMS to the SOA.        •   Notifications from the NPAC SMS to the SOA of subscription version data and number pool block data changes, needed for concurrence or authorization for number porting, conflict-resolution, cancellation, outage information, customer disconnect dates, or the first use of an NPA-NXX.        •   Network data from the NPAC SMS to SOA.        •   Service provider data administration from the SOA to the NPAC SMS.        •   SOA requests for number pool block administration (creation and modification) to the NPAC SMS and responses from the NPAC SMS to the SOA.    Mapping of this functionality into the CMIP Definitions is provided in Section 4 (see Exhibit 8.) The NPAC SMS currently uses a 32-bit signed integer for the Naming ID Value. The maximum value is ([2**31] – 1) or 2.14B. It is anticipated that all Service Providers will be able to successfully handle Naming ID Values up to this maximum. Additionally, it should be noted that there is NOT any rollover strategy (NANC 147), once this number is attained within the NPAC SMS.     2.3.1   Subscription Administration    Service provider subscription administration functionality includes the capability to:       •   Create a subscription version or range of versions        •   Cancel a subscription version        •   Acknowledge cancellation of a subscription version        •   Modify a subscription version or range of versions        •   Retrieve a specific subscription version or range of versions        •   Activate a version or range of versions        •   Disconnect a subscription version or range of versions        •   Place a subscription into conflict        •   Remove a subscription version from conflict       2.3.2   Audit Requests                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.  9                   Interface Overview    Audit functionality allows the SOAs to request audits for a subscription version or group of subscription versions based on a Telephone Number (TN) for a specified service provider or all service provider networks. The requesting SOA receives discrepancy reports as they are found in the network. Upon audit completion it receives a notification of the success or failure of the audit and the total number of discrepancies found.     2.3.3   Notifications    SOAs are sent notifications to ensure that they are fully informed of relevant events for their subscriptions. Notification of creation, deletion, or data value changes for subscription versions will be sent to the SOA as they occur. Notification will be sent to the SOA if the service provider has not authorized transfer of service for a TN in the amount of time specified in the “Service Provider Concurrence Interval” defined on the NPAC. This notification will indicate to the service provider that authorization is needed for the pending subscription version. If the service provider has not acknowledged version cancellation within a timeframe specified by the NPAC SMS, notifications will be sent requesting cancellation acknowledgment. The donor service provider SOA is notified of the customer’s disconnect date. SOA systems are also sent notifications to ensure they are aware of planned down time in the NPAC SMS. Notification of data value changes and object creations are sent for number pool block objects.  First usage notifications are also sent to the SOA when the first use of an NPA-NXX occurs from a subscription version or number pool block creation.  Each SOA notification is assigned a priority of high, medium, low or none. The category of none indicates that a Service Provider does not want to receive a particular notification. Notifications are then sent in order of priority from high to low.  SOA Service Providers can receive single or range versions of some notifications. If the service provider’s TN Range Notification Indicator is turned OFF in their service provider profile on the NPAC SMS, the following notifications will be sent:  Attribute Value Change for subscriptionVersionNPAC objects Object Creation for subscriptionVersionNPAC objects subscriptionVersionCancellationAcknowledgeRequest subscriptionVersionDonorSP-CustomerDisconnectDate subscriptionVersionNewSP-CreateRequest subscriptionVersionNewSP-FinalCreateWindowExpiration subscriptionVersionOldSP-ConcurrenceRequest subscriptionVersionOldSPFinalConcurrenceWindowExpiration subscriptionVersionStatusAttributeValueChange  If the service provider’s TN Range Notification Indicator is turned ON, the following notifications will be sent:  subscriptionVersionRangeAttributeValueChange for subscriptionVersionNPAC objects  subscriptionVersionRangeCancellationAcknowledgeRequest subscriptionVersionRangeDonorSP-CustomerDisconnectDate subscriptionVersionRangeNewSP-FinalCreateWindowExpiration subscriptionVersionRangeNewSP-CreateRequest  subscriptionVersionRangeObjectCreation for subscriptionVersionNPAC objects  subscriptionVersionRangeOldSP-ConcurrenceRequest subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration  subscriptionVersionRangeStatusAttributeValueChange  Notifications can be recovered by the SOA from the NPAC SMS. Notifications to be recovered are requested by time range and are recovered in the order the NPAC SMS                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      10                   Interface Overview    attempted to sent them. Alternatively, notifications can be recovered using SWIM (Send What I Missed) recovery.  In situations where Subscription Versions are initially created in ranges, then have subsequent activity (modify, activate, disconnect, cancel) performed in singles, TN Range Notifications may changes. Specifically, if subsequent activity on a TN ranges does not equal the initial TN range (subsequent activity is either singles or a subset of the TN range), then initial and final timers (T1, T2) will result in single TN Notifications. TN range requests after the timers would still have the potential to generate TN Range Notifications for Service Providers that support this feature     2.3.4   Service Provider Data Administration    Service providers can use, read, and update their service provider information on the NPAC SMS using the SOA. Service providers can update some information in the service provider profile as well as add and delete their own network data. Changes to network data that result in mass updates are prevented from the SOA to the NPAC. Mass changes must be initiated by the service provider contacting the NPAC personnel directly.     2.3.5   Network Data Download    When network data (NPA-NXX, NPA-NXX-X , Service Provider, or LRN data for service providers) is created, modified, or deleted on the NPAC SMS, the data is automatically downloaded from the NPAC SMS to the SOA. The SOA may request that data be recovered using a recovery request that is sent from the SOA to the NPAC SMS. The SOA then receives the data to be recovered in the request response. Network data to be recovered can be requested based on a time range, SWIM data, service provider or all service providers, an NPA-NXX range or all NPA-NXX data, an NPA-NXX-X range or all NPA-NXX-X data, an LRN range or all LRN data, or all network data can be requested. If all network data is specified and the “NPAC Customer SOA NPA-NXX-X Indicator” has been set to TRUE in the service provider’s profile on the NPAC SMS, then NPA-NXX-X object data will be included in the recovery response.  Service providers can also directly read data they wish to download from the NPAC SMS MIB.     2.3.6   Number Pool Block Administration    Number pool blocks are a set of 1000 TNs represented by a 7 digit NPA-NXX-X (i.e. 555-333-1 represents 555-333-1000 through 1999). Service providers can create and modify the number pool blocks for which they are the block holder. Service providers can query all number pool block objects. Only the NPAC Personnel can initiate the removal of a number pool block object.     2.4   NPAC SMS to Local SMS Interface    The NPAC SMS to Local SMS interface is used for communications between a service provider’s Local SMS and the NPAC SMS for support of LNP network element provisioning. The following transactions occur to support Local Number Portability:       •   Subscription version, number pool block and network data from the NPAC SMS to the Local SMS.        •   Service provider data administration from the Local SMS to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: ©1997 — 2006 NeuStar, Inc.  11                   Interface Overview         •   Notifications from the NPAC SMS to the Local SMS of planned NPAC SMS outages and the first use of a new NPA-NXX.    Mapping of this functionality into the CMIP Definitions is provided in Section 4 (see Exhibit 8.) The NPAC SMS currently uses a 32-bit signed integer for the Naming ID Value. The maximum value is ([2**31] – 1) or 2.14B. It is anticipated that all Service Providers will be able to successfully handle Naming ID Values up to this maximum. Additionally, it should be noted that there is NOT any rollover strategy (NANC 147), once this number is attained within the NPAC SMS.     2.4.1   Subscription Version, Number Pool Block and Network Data Download    When network data (NPA-NXX, NPA-NXX-X or LRN data for service providers) or subscription data or number pool block data is created, modified, or deleted on the NPAC SMS, the data is automatically downloaded from the NPAC SMS to the Local SMS. The Local SMS may request that data be recovered using a recovery request that is sent from the Local SMS to the NPAC SMS. The Local SMS then receives the data to be recovered in the request response. Subscription data to be recovered can be requested based on time range, SWIM recovery, a TN, or a TN range. If the “NPAC Customer LSMS EDR Indicator” is set to TRUE in the service provider’s profile on the NPAC SMS, only number pool block data will be sent and no subscription versions with LNP type set to ‘pool’ will be sent. Number pool block data to be recovered can be requested by time-range, SWIM recovery, NPA-NXX-X or NPA-NXX-X range. Network data to be recovered can be requested based on a time range, SWIM recovery, service provider or all service providers, an NPA-NXX range or all NPA-NXX data, an NPA-NXX-X range or all NPA-NXX-X data, an LRN range or all LRN data, or all network data can be requested. If all network data is specified and the “NPAC Customer LSMS NPA-NXX-X Indicator” has been set to TRUE in the service provider’s profile on the NPAC SMS, then NPA-NXX-X object data will be included in the recovery response.  Service providers can also directly read data they wish to download from the NPAC SMS MIB.     2.4.2   Service Provider Data Administration    Service providers can use, read, and update their service provider information on the NPAC SMS using the Local SMS to NPAC SMS interface. Service providers can update some information in the service provider profile as well as add and delete their own network data. Changes to network data that result in mass updates are prevented by the NPAC SMS to Local SMS interface. Mass changes must be initiated by the service provider contacting the NPAC personnel directly.     2.4.3   Notifications    Local SMSs are sent notifications to ensure they are aware of planned down time in the NPAC SMS. Local SMSs are also sent notifications when a new NPA-NXX is to be used for the first time in a subscription version or number pool block by a serviceProvNPA-NXX-X creation.  Notifications can be recovered by the Local SMS from the NPAC SMS. Notifications to be recovered are requested by time range. Alternatively, notifications can be recovered using SWIM recovery.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3:©1997 - 2006 NeuStar, Inc.      12                   Hierarchy Diagrams    3 Hierarchy Diagrams  [Graphic Omitted: 3]     3.1   Overview    The following five exhibits show the class hierarchy diagram for all managed objects (Exhibit 2), Log Record Objects (Exhibit 3), the Local SMS (Exhibit 4), the NPAC SMS naming hierarchies for the Local SMS (Exhibit 5), the SOA (Exhibit 6.), and the NPAC SMS naming hierarchies for the SOA. (Exhibit 7). These exhibits will help the user gain a better understanding of the structure of the interface definitions provided.     3.1.1   Managed Object Model Inheritance Hierarchy    The Managed Object Model Inheritance Hierarchy shows the inheritance hierarchy used for object definitions in the NPAC SMS to Local SMS and the SOA to NPAC SMS interfaces.  [Graphic Omitted: . The Managed Object Model Inheritance Hierarchy]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: ©1997 — 2006 NeuStar, Inc.  13                   Hierarchy Diagrams       3.1.2   Log Record Managed Object Hierarchy    The Log Record Managed Object Hierarchy shows the inheritance hierarchy of the log records used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces.  [Graphic Omitted: . Log Record Managed Object Hierarchy]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.  14                   Hierarchy Diagrams       3.1.3   NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS    The NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS shows the naming hierarchy used in the NPAC SMS to instantiate objects defined in the NPAC SMS to Local SMS interface.  Shaded objects are instantiated at NPAC SMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the NPAC SMS or from actions taken while the NPAC SMS is running.  Each object class belongs to one or more Association Functions.  Refer to Section 5.2.1.8, Association Functions.  [Graphic Omitted: The NPAC SMS to Local SMS Naming Hierarchy for the NPAC SMS.]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      15                   Hierarchy Diagrams       3.1.4   NPAC SMS to Local SMS Naming Hierarchy for the Local SMS    The NPAC SMS to Local SMS Naming Hierarchy for Local SMS shows the naming hierarchy used in the Local SMS to instantiate objects defined in the NPAC SMS to Local SMS interface.  Shaded objects are instantiated at Local SMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the Local SMS or from actions taken while the Local SMS is running.  Each object class belongs to one or more Association Functions.  Refer to Section 5.2.1.8, Association Functions.  [Graphic Omitted: The NPAC SMS to Local SMS Naming Hierarchy for the Local SMS.]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      16                   Hierarchy Diagrams       3.1.5   SOA to NPAC SMS Naming Hierarchy for the NPAC SMS    The SOA to NPAC SMS Naming Hierarchy for the NPAC SMS shows the naming hierarchy used in the NPAC SMS to instantiate objects defined in the SOA to NPAC SMS interface.  Shaded objects are instantiated at NPAC SMS start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the NPAC SMS or from actions taken while the NPAC SMS is running.  Each object class belongs to one or more Association Functions.  Refer to Section 5.2.1.8, Association Functions.  [Graphic Omitted:. The SOA to NPAC SMS Naming Hierarchy for the NPAC SMS]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.  17                   Hierarchy Diagrams       3.1.6   NPAC SMS to SOA Naming Hierarchy for the SOA    The NPAC SMS to SOA Naming Hierarchy for SOA shows the naming hierarchy used in the SOA to instantiate objects defined in the SOA to NPAC SMS interface.  Shaded objects are instantiated at SOA start-up and are not created via M-CREATE or M-DELETE requests. All other objects are created at start-up from a persistent object store on the SOA or from actions taken while the SOA is running.  Each object class belongs to one or more Association Functions.  Refer to Section 5.2.1.8, Association Functions.  [Graphic Omitted: NPA SMS to SOA Naming Hierarchy for the SOA]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: ©1997 - 2006 NeuStar, Inc.  18                   Interface Functionality to CMIP Definition Mapping    4 Interface Functionality to CMIP Definition Mapping  [Graphic Omitted: 4]     4.1   Overview    The following tables, Exhibits 8-12, contain the mapping of the interface functionality to managed objects, attributes, actions, and notifications.     4.1.1   Primary NPAC Mechanized Interface Operations    The primary interface functions in support of the NPAC requirements are described in the table below, as well as their corresponding Common Management Information Exchange (CMISE) operation and referenced object type for that operation. This table does not include miscellaneous operations, such as service provider network data querying or downloading, etc. These functions are described in the object behaviors in the GDMO source below.  Exhibit 2. Primary NPAC Mechanized Interface Operations Table                          Direction       Referenced   Function   (To/From)   CMIP Operation   Object Type     Abort/Cancel Audit Request   from SOA   M-DELETE   subscriptionAudit                   Audit Complete   to SOA   M-EVENT-REPORT:   subscriptionAudit                subscriptionAuditResults                       Audit Discrepancy   to SOA   M-EVENT-REPORT:   subscriptionAudit                subscriptionAudit-DiscrepancyRpt                       Audit Query   from SOA   M-GET   subscriptionAudit                   Audit Request SOA   from SOA   M-CREATE   subscriptionAudit                   Cancellation   from SOA (new service   M-ACTION:   lnpSubscriptions   Acknowledgement        provider)        subscriptionVersionNewSP-                    CancellationAcknowledge                       Cancellation   from SOA (old service   M-ACTION:   lnpSubscriptions   Acknowledgment        provider)        subscriptionVersionOldSP-      CancellationAcknowledge                       Conflict Removal   from SOA (new service   M-ACTION:   lnpSubscriptions            provider)        subscriptionVersionRemoveFromConflict                       Customer Disconnect   to SOA   M-EVENT-REPORT:   subscriptionVersionNPAC   Date            subscriptionVersionDonorSP-      CustomerDisconnectDate or   or lnpSubscriptions                               subscriptionVersionRangeDonorSP-      Customer DisconnectDate                                   March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      19                   Interface Functionality to CMIP Definition Mapping                            Direction       Referenced   Function   (To/From)   CMIP Operation   Object Type     Final Request for      Version Create    to SOA (old service provider)    M-EVENT-REPORT:      subscriptionVersionOldSPFinalConcurrence      WindowExpiration or      subscriptionVersionRangeOldSPFinalCo ncur      renceWindowExpiration    subscriptionVersionNPAC or lnpSubscriptions                   LSMS Filter NPA-      NXX Create    from LOCAL SMS  or from SOA    M-CREATE    lsmsFilterNPA-NXX                   LSMS Filter NPA-      NXX Delete    from LOCAL SMS or from SOA    M-DELETE    lsmsFilterNPA-NXX                   LSMS Filter NPA-      NXX Query    from LOCAL SMS or from SOA    M-GET    lsmsFilterNPA-NXX                   Network Data      Download    from LOCAL SMS or from SOA    M-ACTION:      lnpDownload or M-GET:    lnpNetwork                 scoped and filtered for intended       serviceProvLRN, serviceProvNPA-NXX       serviceProvNPA-NXX-X, service provider       attributes                       Network Data       Update    from LOCAL SMS or from SOA    M-CREATE    serviceProvLRN,      serviceProvNPA-NXX                   NPA-NXX-X       Create    to LOCAL SMS  or  to SOA    M-CREATE;    serviceProvNPA- NXX-X                   NPA-NXX-X       Delete    to LOCAL SMS  or  to SOA    M-DELETE    serviceProvNPA- NXX-X                   NPA-NXX-X       Modify    to LOCAL SMS  or to SOA    M-SET    serviceProvNPA-NXX-X                   New NPA-NXX    to LOCAL SMS  or  to SOA    M-EVENT-REPORT:      subscriptionVersionNewNPA-NXX    SubscriptionVersionNPAC lnpNPAC-SMS                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      20                   Interface Functionality to CMIP Definition Mapping                            Direction       Referenced   Function        (To/From)   CMIP Operation        Object Type     Number Pool       Block Change        Notification    to SOA    M-EVENT-REPORT attributeValueChange Notification or      numberPoolBlockStatusAttributeValueChange       Notification    numberPoolBlockNPAC                   Number Pool       Block Create    from SOA    M-ACTION: numberPoolBlock-Create    lnpSubscriptions                   Number Pool       Block Create    to LOCAL SMS    M-CREATE: for a single numberPoolBlock    numberPoolBlock                   Number Pool       Block Modify    from SOA    M-SET:  to a single numberPoolBlock    numberPoolBlockNPAC or      lnpSubscriptions                   Number Pool       Block Modify    to LOCAL SMS    MSET:  to a single numberPoolBlock or  scoped and filtered by NPA-NXX-X range for mass update    numberPoolBlock or      lnpSubscriptions                   Number Pool       Block Delete    to LOCAL SMS    M-DELETE: for a single numberPoolBlock    numberPoolBlock                   Number Pool       Block Query    from LOCAL SMS or  SOA    M-GET:  To a single numberPoolBlockNPAC or scoped and filtered for intended numberPoolBlocks    lnpSubscriptions numberPoolBlockNPAC                   Number Pool    to LOCAL SMS    M-GET:             Block Query       scoped and filtered for intended       numberPoolBlock    lnpSubscriptions                   Notification    from LOCAL SMS    M-ACTION:            Recovery    or from SOA    lnpNotificationRecovery    lnpNPAC-SMS                   Recovery       Complete     from LOCAL SMS or    M-ACTION:   lnpNPAC-SMS        from SOA    lnpRecoveryComplete                        Request for      Cancellation      Acknowledg-ment    to SOA    M-EVENT-REPORT:      subscription      VersionCancellationAcknowledgment      Request or      subscriptionVersionRangeCancellationAckn      owledgeRequest    subscriptionVersionNPAC or lnpSubscriptions                   Request for       Version Create    to SOA      (new service       provider)    M-EVENT-REPORT:      subscriptionVersionNewSP-Create      Request or      subscriptionVersionRangeNewSP-CreateRequest    subscriptionVersionNPAC                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.      21                   Interface Functionality to CMIP Definition Mapping                            Direction       Referenced   Function        (To/From)   CMIP Operation        Object Type     Request for    Version Create    to SOA   (old service provider)    M-EVENT-REPORT:      subscriptionVersionOldSP-Concurrence      Request or      subscriptionVersionRangeOldSP-Concurrence Request    subscriptionVersionNPAC or lnpSubscriptions                   Service Provider      Network       Creation    to LOCAL SMS or to SOA    M-CREATE    serviceProvNetwork                   Service Provider      Network       Deletion    to LOCAL SMS or to SOA    M-DELETE    serviceProvNetwork                   Service Provider      Network Service      Provider Name      Change    to LOCAL SMS or to SOA    M-SET:      serviceProvName    serviceProvNetwork                   Subscription      Version Activate    from SOA    M-ACTION:      subscriptionVersionActivate    lnpSubscriptions                   Subscription      Version Cancel    from SOA    M-ACTION      subscriptionVersionCancel    lnpSubscriptions                   Subscription      Version Change      Notification    to SOA    M-EVENT-REPORT:      attributeValueChangeNotification and      subscriptionVersionStatusAttributeValue      Change or      subscriptionVersionRangeAttribute      ValueChange      subscriptionVersionRangeStatusAttribute      ValueChange    subscriptionVersionNPAC or lnpSubscriptions                   Subscription      Version Conflict    from SOA (old service   provider)    M-ACTION:   subscriptionVersionOldSP-Create   setting subscriptionOldSP-Authorization = FALSE    subscriptionVersion                   Subscription      Version Create    to LOCAL SMS    M-ACTION:      subscriptionVersionLocalSMS-Create for       multiple creates (i.e., range operations)      where the data in the subscription versions      is the same    lnpSubscriptions subscriptionVersion              M-CREATE:                     for an individual subscriptionVersion                       Subscription      Version Create    from SOA    M-ACTION:      subscriptionVersionOldSP-Create or      subscriptionVersionNewSP-Create    lnpSubscriptions                   Subscription      Version Delete    to LOCAL SMS    M-DELETE:      scoped and filtered for intended      subscriptionVersion criteria    subscriptionVersion                   Subscription      Version      Disconnect    from SOA    M-ACTION:      subscriptionVersionDisconnect    lnpSubscriptions                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.      22                   Interface Functionality to CMIP Definition Mapping                            Direction       Referenced   Function        (To/From)   CMIP Operation        Object Type     Subscription      Version      Download    to LOCAL SMS    M-ACTION: subscriptionVersionLocalSMS-Create or    lnpSubscriptions            M-CREATE:                     for an individual subscriptionVersion                       Subscription      Version      Download      Request    from LOCAL SMS    M-ACTION:      lnpDownload or    lnpSubscriptions            M-GET:                     scoped and filtered for intended      subscriptionVersionNPAC criteria                       Subscription      Version Modify    from SOA    M-ACTION: subscriptionVersion Modify or    lnpSubscriptions            M-SET:                     on relevant subscriptionVersionNPAC      attributes for pending and conflict      versions                       Subscription      Version Modify    to LOCAL SMS    M-SET:      scoped and filtered for intended      subscriptionVersion criteria setting      relevant attributes    lnpSubscriptions                   Subscription      Version Query    from SOA  from LOCAL SMS    M-GET:      scoped and filtered for intended      subscriptionVersionNPAC criteria       setting relevant attributes    lnpSubscriptions                   Subscription      Version Query    to LOCAL SMS    M-GET:      scoped and filtered for intended       subscriptionVersion criteria    lnpSubscriptions        4.1.2   Managed Object Interface Functionality    The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS managed objects to the interface functionality.  Exhibit 3. Managed Object Interface Functionality Table              Managed Object Name   Interface Functionality Mapping     lnpAudits    Container object used to contain all subscription audit objects on the NPAC SMS and the Local SMS. It is used in the SOA to NPAC SMS interface to support audit functionality.           lnpLocal SMS    Container object used to contain all objects on a Local SMS. It is used in the NPAC SMS to Local SMS interface to support NPAC SMS communication to the service provider Local SMS system.           lnpLogAudit- DiscrepancyRptRecord    Object used to log information from a subscriptionAuditDiscrepancyRpt notification.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 – 2006 NeuStar, Inc.      23                   Interface Functionality to CMIP Definition Mapping                Managed Object Name   Interface Functionality Mapping     lnpLogAuditResultsRecord    Object used to log information from a subscriptionAuditResults notification.           lnpLogCancellation AcknowledgeRequest Record    Object used to log information from a subscriptionVersionCancellationAcknowledgeRequest notification.           lnpLogDonorSP-CustomerDi sconnectDateRecord    Object used to log information from a subscriptionVersionDonorSP-CustomerDisconnectDate notification.           lnpLogLocalSMS-ActionRes ultsRecord    Object used to log information from a subscriptionVersionLocalSMS-ActionResults notification.           lnpLogNewNPA-NXXRecord    Object used to log information from a subscriptionVersionNewNPA-NXX notification.           lnpLogNewSP-CreateReques tRecord    Object used to log information from a subscriptionVersionNewSP-CreateRequest notification.           lnpLogNumberPoolBlockSta tusAttributeValueChangeR ecord    Object used to log information from a numberPoolBlockStatusAttributeValueChange notification.           lnpLogOldSP-ConcurrenceR equestRecord    Object used to log information from a subscriptionVersionOldSP-ConcurrenceRequest notification.           lnpLogOldSP-FinalConcurrenceWindow-Expiration    Object used to log information from a subscriptionVersionOldSPFinalConcurrenceWindowExpiration notification           lnpLogOperational-Inform ationRecord    Object used to log information from a lnpNPAC-SMS-Operational-Information notification.           lnpLogRangeAttributeValu eChangeRecord    Object used to log information from a lnpLogRangeAttributeValueChange notification.           lnpLogRangeObjectCreatio nRecord    Object used to log information from a lnpLogRangeObjectCreation notification.           lnpLogRangeStatusAttribu teValueChangeRecord    Object used to log information from a lnpLogRangeStatusAttributeValueChange notification.           lnpLogRangeDonorSP-Custo merDisconnectDateRecord    Object used to log information from a lnpLogRangeDonorSP-CustomerDisconnectDate notification.           lnpLogRangeCancellationA cknowledgeRecord    Object used to log information from a lnpLogRangeCancellationAcknowledge notification.           lnpLogRangeNewSP-CreateR equestRecord    Object used to log information from a lnpLogRangeNewSP-CreateRequest notification.           lnpLogRangeNewSP-FinalCr eateWindowExpirationRecord     Object used to log information from a lnpLogRangeNewSP-FinalCreateWindowExpiration notification.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      24                   Interface Functionality to CMIP Definition Mapping                Managed Object Name   Interface Functionality Mapping     lnpLogNewSP-FinalCreateW indowExpirationRecord    Object used to log information from a lnpLogNewSP-FinalCreateWindowExpiration notification.           lnpLogRangeOldSP-Concurr enceRequestRecord    Object used to log information from a lnpLogRangeOldSP-ConcurrenceRequest notification.           lnpLogRangeOldSPFinalCon currenceWindowExpiration Record    Object used to log information from a lnpLogRangeOldSPFinalConcurrenceWindowExpiration notification.           lnpLogStatusAttributeVal ueChangeRecord    Object used to log information from a subscriptionVersionStatusAttributeValueChange notification.           lnpLogHeartbeat-Informat ionRecord    Object used to log information from a Heartbeat-Information notification.           lnpLogSwimProcessing-Rec overyResultsRecord    Object used to log information from a swimProcessing-RecoveryResults notification.           lnpNetwork    Container object used to contain all service provider network data on the NPAC SMS, SOA, and Local SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support downloading of network data to the Local SMS and/or SOA and the functionality that allows service providers to create/delete their network data on the NPAC SMS.           lnpNPAC-SMS    Container object used to contain all objects on a NPAC SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support NPAC SMS communication from the service provider Local SMS and the SOA systems.           lnpServiceProvs    Container object used to contain all service provider data on the NPAC SMS. It is used in the NPAC SMS to Local SMS interface and SOA to NPAC SMS interface to support retrieving of service provider data by the Local SMS and/or SOA and the functionality that allows service providers to update their service provider data on the NPAC SMS. Service providers can only retrieve their service provider data.           lnpSOA    Container object used to contain all objects on a SOA It is used in the SOA to NPAC SMS interface to support NPAC SMS communication to the service provider SOA system.           lnpSubscriptions    Container object used to contain all subscription versions and number pool blocks on the NPAC SMS and the Local SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support query of subscription and number pool block data on the NPAC SMS and downloading of subscription and number pool block data to the Local SMS.           lsmsFilterNPA-NXX    Object used to represent the NPA-NXX values for which a service provider does not want to be informed of subscription version broadcasts.           numberPoolBlock    Object used to represent a number pool block on the Local SMS. These objects are used to support number pool block download from the NPAC SMS to the EDR Local SMS using the NPAC SMS to Local SMS interface.                Local SMS may support this object by setting the “NPAC Customer LSMS EDR Indicator” to TRUE in their service provider profile on the NPAC SMS.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      25                   Interface Functionality to CMIP Definition Mapping                Managed Object Name   Interface Functionality Mapping     numberPoolBlockNPAC    Object used to represent a number pool block on the NPAC SMS. These objects are used to support number pool block administration from the SOA using the SOA to NPAC SMS interface. Capability is provided to the SOA for creation and modification. The NPAC SMS can create, modify and delete.           serviceProv    Object used to represent a service provider and its associated data on the NPAC SMS. These objects are used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support retrieving of service provider data and the functionality that allows service providers to update their service provider data on the NPAC SMS except serviceProvId and serviceProvType. Service providers can only retrieve their service provider data.           serviceProvLRN    Object used to represent an LRN associated with a service provider on the NPAC SMS, SOA, or Local SMS. These objects are used to support downloading of network LRN data to the Local SMS and/or SOA and the functionality that allows service providers to create/delete their own network LRN data. The service provider will have to add a new object and delete the old one to modify the data.           serviceProvNetwork    Container object used to contain network data for a service provider on the NPAC SMS, SOA or Local SMS. It is used in the NPAC SMS to Local SMS and SOA to NPAC SMS interfaces to support downloading of network data to the Local SMS and the functionality that allows service providers to update their network data on the NPAC SMS.           serviceProvNPA-NXX    Object used to represent an NPA-NXX associated with a service provider on the NPAC SMS, SOA or Local SMS. These objects are used to support downloading of network NPA-NXX data to the Local SMS and/or SOA and the functionality that allows service providers to create/delete their own network NPA-NXX data. NPA splits are supported only through direct contact with NPAC personnel.           serviceProvNPA-NXX-X    Object used to represent an NPA-NXX-X associated with a service provider on the NPAC SMS, SOA or Local SMS. These objects are used in number pooling to support downloading of network NPA-NXX-X data to the Local SMS or SOA. Only the NPAC SMS is allowed to create, delete and modify a service provider’s NPA-NXX-X data.                Local SMS may support this object by setting the “NPAC Customer LSMS NPA-NXX-X Indicator” to TRUE in their service provider profile on the NPAC SMS.                SOA may support this object by setting the “NPAC Customer SOA NPA-NXX-X Indicator” to TRUE in their service provider profile on the NPAC SMS.           subscriptionAudit    Object used to represent a subscription audit request on the NPAC SMS. These objects are used to support subscription audit requests from the SOA to the NPAC SMS using the SOA to NPAC SMS interface. The object supports notifications for audit discrepancies found and audit completion results. If the subscription version LNP type is equal to ‘pool’, the appropriate number pool block will also be audited.           subscriptionVersion    Object used to represent a subscription version on the Local SMS. These objects are used to support subscription version download from the NPAC SMS to the Local SMS using the NPAC SMS to Local SMS interface           subscriptionVersionNPAC    Object used to represent a subscription version on the NPAC SMS. These objects are used to support subscription administration from the SOA using the SOA to NPAC SMS interface. Capability is provided for version creation, activation, modification, cancellation, disconnect, and query.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      26                   Interface Functionality to CMIP Definition Mapping       4.1.3   Action Interface Functionality    The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS actions to the interface functionality.  Exhibit 4. The Action Interface Functionality Table              Action Name   Interface Requirements Mapping      lnpDownload    This action is used to support the downloading of subscription, number pool block and network data to the Local SMS from the NPAC SMS. It also supports the downloading of network data to the SOA from the NPAC SMS.           lnpRecoveryComplete    This action is used to specify the system has recovered from down time and the transactions performed since the association establishment can now be sent to the Local SMS from the NPAC SMS using the Local SMS to NPAC SMS interface or the SOA from the NPAC SMS using the SOA to NPAC SMS interface.           lnpNotificationRecovery    This action is used to support the downloading of notification data to the SOA and/or Local SMS from the NPAC SMS.           numberPoolBlock-Create    This action is used to support creation of the number pool block object by the block holder service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersionActivate    This action is used to support subscription version activation by the new service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersionCancel    This action is used to support subscription version cancellation by a service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersionDisconnect    This action is used to support subscription version disconnection by the current service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersionLocalSMS-Create    This action can be used by the NPAC SMS to create multiple subscription versions via the Local SMS to NPAC SMS interface.           subscriptionVersionModify    This action is used to support subscription version modification by a service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersionNewSP-CancellationAc knowledge    This action is used to support the acknowledgment of subscription versions with a status of cancel-pending by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersionNewSP-Create    This action is used to support subscription version creation by the new service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.       subscriptionVersionOldSP-CancellationAc knowledge    This action is used to support the acknowledgment of subscription versions with a status of cancel-pending by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      27                   Interface Functionality to CMIP Definition Mapping                Action Name   Interface Requirements Mapping      subscriptionVersionOldSP-Create    This action is used to support subscription version creation by the old service provider from the SOA to the NPAC SMS using the SOA to NPAC SMS interface.           subscriptionVersion RemoveFromConflict    This action is used on the NPAC SMS via the SOA to NPAC SMS interface to set the subscription version status from conflict to pending.           lnpNotificationRecovery    This action is used on the NPAC SMS via the SOA to NPAC SMS or Local SMS to NPAC SMS interface to recover notifications.           subscriptionVersionActivateWithErrorCode    This action is used on the SOA to NPAC SMS interface by the new service provider to activate a subscription version id, TN or range of TNs via the SOA to NPAC SMS interface. This action’s reply contains an optional error code to be returned if the action is not successful.           subscriptionVersionCancelWithErrorCode    The action issued on the SOA to NPAC SMS interface by the SOA to cancel a subscription version. This action’s reply contains an optional error code to be returned if the action is not successful.           subscriptionVersionNewSP- CancellationAc knowledgeWithErrorCode    This action is used on the SOA to NPAC SMS interface by the new service provider to acknowledge cancellation of a subscriptionVersionNPAC with a status of cancel-pending. This action’s reply contains an optional error code to be returned if the action is not successful.           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-CancellationAc knowledgeWithErrorCode    This action is used on the SOA to NPAC SMS interface by the old service provider to acknowledge cancellation of a subscriptionVersionNPAC with a status of cancel-pending. This action’s reply contains an optional error code to be returned if the action is not successful.        4.1.4   Notification Interface Functionality    The table below contains the mapping of the SOA to NPAC SMS and the Local SMS to NPAC SMS notifications to the interface functionality.  Exhibit 5. The Notification Interface Functionality Table              Notification Name   Interface Requirements Mapping     lnpNPAC-SMS-Operational-Information    This notification is used to support the reporting of NPAC SMS scheduled down time. This notification can be issued from the lnpNPAC-SMS object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface or from the NPAC SMS to the Local SMS via the NPAC SMS to Local SMS interface.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      28                   Interface Functionality to CMIP Definition Mapping                Notification Name   Interface Requirements Mapping     numberPoolBlockStatusAttributeValueChange    This notification is issued when the number pool block status is modified and can contain the number pool block status and failed service provider list. This notification is issued over the NPAC SMS to SOA interface from the numberPoolBlockNPAC object.           subscriptionAuditDiscrepancyRpt    This notification is used to support the reporting of audit discrepancies found during audit processing. This notification can be issued from an audit object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.           subscriptionAuditResults    This notification is used to support the reporting of audit processing results. This notification can be issued from an audit object on the NPAC SMS to a SOA via the SOA to NPAC SMS interface.           subscriptionVersionCancellationAcknowledgeRequest or subscriptionVersionRangeNewSP-CancellationAcknow ledge    This notification is issued to new and old service providers to request that a cancellation acknowledgment be sent for a subscription version in a cancel-pending state. This notification is issued via the SOA to NPAC SMS interface if the service provider fails to acknowledge the cancellation after a tunable amount of time specified in the NPAC SMS.                The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate    This notification informs the donor service provider SOA that a subscription version is being disconnected. This notification is issued from the NPAC SMS to a SOA via the SOA to NPAC SMS interface.                The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           subscriptionVersionLocalSMS-ActionResults    This notification contains the results of a subscriptionVersionLocalSMS-Cr eate action once all the create requests have been attempted. It is issued from the Local SMS to the NPAC SMS via the NPAC SMS to Local SMS interface.           subscriptionVersionNew-NPA-NXX    This notification informs the Local SMS or SOA of a pending subscription version or new number pool block involving the first use of an NPA-NXX.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      29                   Interface Functionality to CMIP Definition Mapping                Notification Name   Interface Requirements Mapping     subscriptionVersionNewSP-CreateRequest or subscriptionVersionRangeNewSP-CreateRequest    This notification is issued to the new service provider to request that a create request be sent for the subscription version created by the old service provider to provide authorization and/or porting information. This notification is issued via the SOA to NPAC SMS interface if the new service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS.                The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           subscriptionVersionNewSPFinalCreateWindow Expiration or subscriptionVersionRangeNewSPFinalCreateWindow Expiration    This notification is issued to the new and old service provider, if they support the Final Create Window Expiration Notification in their Service Provider profile, to inform them of the expiration of the Final Concurrence Window on the NPAC SMS. This notification is issued from the NPAC SMS to the SOA via the SOA to NPAC SMS interface.                The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           subscriptionVersionOldSP-ConcurrenceRequest or subscriptionVersionRangeOldSP-ConcurrenceRequest    This notification is issued to the old service provider to request that a create request be sent for the subscription version created by the new service provider to provide concurrence for porting. This notification is issued via the SOA to NPAC SMS interface if the old service provider failed to authorize porting of a number after a tunable amount of time specified in the NPAC SMS.                The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValue Change    This notification is issued when the subscription version status is modified. This notification is issued from the NPAC SMS to the SOA via the SOA to NPAC SMS interface.          The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.     subscriptionVersionOldSPFinalConcurrenceWindow Expiration or subscriptionVersionRangeOldSPFinalConcurrence WindowExpiration    This notification is issued to the old service provider to request for a final time that a create request be sent for the subscription version created by the new service provider to provide concurrence for porting. This notification is issued via the SOA to NPAC SMS interface if the old service provider failed to authorize porting of a number after a tunable amount of time.          The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      30                   Interface Functionality to CMIP Definition Mapping                Notification Name   Interface Requirements Mapping     subscriptionVersionRangeAttributeValueChange    This notification or the Attribute Value Change notification is sent when specified attributes have been updated. This notification is issued via the SOA to NPAC SMS interface.          The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           subscriptionVersionRangeObjectCreation    This notification or the object creation notification is sent when a subscriptionVersionNPAC object has been created. This notification is issued via the SOA to NPAC SMS interface.                The NPAC SMS sends the appropriate notification depending upon the Service Provider’s TN Range Notification Indicator.           ApplicationLevelHeartBeat    This notification implements a SOA or LSMS Application Level Heartbeat function. With this functionality the NPAC SMS will send a periodic Heartbeat message when a quiet period between the SOA/LSMS and the             NPAC SMS exceeds the tunable value.                This notification is prioritized and transmitted according to its SOA Notification Priority tunable in the NPAC SMS when sent over the NPAC SMS to SOA interface.                Optionally, this notification may also be implemented on the SOA or Local SMS. With this functionality the SOA/Local SMS will send a periodic Heartbeat message when a quiet period between the SOA/Local SMS and the NPAC SMS exceeds the tunable value.                This notification can be issued via the NPAC SMS to SOA and NPAC SMS to Local SMS interfaces. Optionally, this notification can also be issued via the SOA to NPAC SMS and LSMS to NPAC SMS interfaces.           swimProcessing-RecoveryResults    This notification contains the recovery results of a SWIM lnpDownload action or SWIM lnpNotificationRecovery action from a SOA/LSMS.                This notification is issued via the SOA to NPAC SMS interface and the Local SMS to NPAC SMS interface.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 - 2006 NeuStar, Inc.      31                   Interface Functionality to CMIP Definition Mapping       4.2   Scoping and Filtering Support    The following section defines the scoping and filtering support for both the SOA to NPAC SMS interface and LSMS to NPAC SMS interface.     4.2.1   Scoping    The NPAC SMS to Local SMS or SOA to NPAC SMS interfaces do not support scoping of CMIP operations of any type by the LSMS or SOA for the following objects:       •   root        •   lnpLocal-SMS        •   lnpNetwork        •   any object with an “empty” filter    NPAC SMS is not required to support Scope other than baseObject Scope for CMIP operations that specify baseManagedObjectClass of one of the following:       •   lnpNPAC-SMS        •   lnpServiceProvs    Scoped operations for subscriptionVersions or numberPoolBlocks to the LSMS must be supported on the baseObject (level 0) or from the lnpSubscriptions object with a non-empty filter.  The limit in scoping and functionality prevents the NPAC, SOA, and the LSMS systems from having to implement functionality or respond to large requests that are not necessary to support LNP over the mechanized interfaces.     4.2.2   Filtering    Filtering on the NPAC SMS is supported as defined in the GDMO. The NPAC SMS requires the Local SMS to support at a minimum the filter criteria specified below.  Limitations:       •   OR and NOT filter support is not required for the Local SMS or SOA.        •   NOT filter support is not required for the NPAC SMS.        •   Filtering requests with a scope will not be issued to the Local SMS or SOA by the NPAC SMS for any object other than the subscriptionVersion and numberPoolBlock objects. No query will be used that requests both subscription versions and number pool blocks at the same time..        •   All authorization rules apply to scoped and filtered operations. For example, a query for data that a service provider is not authorized to view will be failed with a reason of access denied.        •   CMISSync is not supported for any scoped/filtered CMIP operation.    The following table shows the CMISE primitive filtering support required of the Local SMS by the NPAC SMS.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      32                   Interface Functionality to CMIP Definition Mapping    Exhibit 6 — CMISE Primitive Filtering Support for Local System Objects                  CMISE Primitives   Filter Supported   Notes     M-ACTION    N    No filtering is applied to the actions for the subscriptionVersion object.               M-GET    Y    TN Query with greaterOrEqual and lessOrEqual, and equality must be supported for auditing.                        The fields used with greaterOrEqual and lessOrEqual filters are subscriptionTN and subscriptionActivationTimeStamp.                        The field used with equality is subscriptionTN.                         Filters supported contain either a greaterOrEqual and lessOrEqual filter, or equality filter, for subscriptionTN only or a more complex filter.                        The more complex filter uses two criteria for filtering. The first criteria used is greaterOrEqual and lessOrEqual filters with subscriptionTN. The second criteria uses greaterOrEqual and lessOrEqual filters for subscriptionActivationTimeStamp. Both criteria must be matched for the data being queried (logical “and”).                        The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.                        Number Pool Block Query with greaterOrEqual and lessOrEqual, and equality for EDR support.                        The fields used with greaterOrEqual and lessOrEqual filters are numberPoolBlockNPA-NXX-X and numberPoolBlockActivationTimeStamp.                        The field used with equality is number PoolBlockNPA-NXX-X.                        Filters supported contain either a greaterOrEqual and lessOrEqual filter, or equality filter, for numberPoolBlockNPA-NXX-X only or a more complex filter.                        The more complex filter uses two criteria for filtering. The first criteria used is equality filter with numberPoolBlockNPA-NXX-X. The second criteria uses greaterOrEqual and lessOrEqual filters for numberPoolBlockActivationTimeStamp. Both criteria must be matched for the data being queried (logical “and”).                        The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      33                   Interface Functionality to CMIP Definition Mapping                    CMISE Primitives   Filter Supported   Notes     M-SET    Y    TN Modify with greaterOrEqual and lessOrEqual, and equality must be supported for Mass Update or TN range modify requests.                        The field used with greaterOrEqual and lessOrEqual filters is subscriptionTN.                        The fields used with equality are subscriptionTN and subscriptionNewCurrentSP.                        Filters supported contain either a greaterOrEqual and lessOrEqual filter, or equality filter, for subscriptionTN only, or a more complex filter.                        In the case of Modification of TNs for non-EDR number pool block the filter is more complex and uses two criteria for modification. The first criteria uses the subscriptionNewCurrentSP field with equality. The second criteria uses lessOrEqual and greaterOrEqual for subscriptionTN. Both criteria must be matched for the data being set (logical “and”). Additionally, a filter for LNP Type equal to ‘pool’ may be used.                        The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.                        Number Pool Block Modify with greaterOrEqual and lessOrEqual, and equality for EDR support.                        The field used with greaterOrEqual and lessOrEqual is numberPoolBlockNPA-NXX-X.                        The field used with equality is numberPoolBlockNPA-NXX-X.                        The scope for the filters is level 1 only with a base managed object class of lnpSubscriptions.               M-DELETE    Y    TN Delete with greaterOrEqual and lessOrEqual, and equality will be supported.                        The field used with greaterOrEqual and lessOrEqual filters is subscriptionTN.                        The field used with equality is subscriptionTN.               The scope for the filter is level 1 only with a base managed object class of lnpSubscriptions.              In the case of Deletion of TNs for non-EDR number pool block the filter is more complex and uses two criteria for deletion. The first criteria uses the subscriptionNewCurrentSP field with equality. The second criteria uses lessOrEqual and greaterOrEqual for subscriptionTN. Both criteria must be matched for the data being set (logical “and”). Additionally, a filter for LNP Type equal to ‘pool’ may be used.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      34                   Interface Functionality to CMIP Definition Mapping       4.2.3   Action Scoping and Filtering Support    For messages sent to any object, the scope and filter will be checked to ensure it is appropriate for that object class.       •   All M-ACTIONs that relate to subscriptions and number pool blocks are targeted to lnpSubscriptions.        •   The ONLY filters allowed by the GDMO for lnpSubscriptions are “equality” and “present” for the single attribute lnpSubscriptionsName.        •   If any one of the above M-ACTIONs is sent to a subscriptionVerisonNPAC or numberPoolBlockNPAC object you will get a “no such action” error response from that object.        •   If you send a scoped/filtered M-ACTION whose scope includes objects of class subscriptionVersionNPAC or numberPoolBlockNPAC, you will receive an error “no such action” from each object specified by the filter.       4.3   lnpLocal-SMS-Name and lnpNPAC-SMS-Name Values    The following table (Exhibit 13) shows the values to be used for all currently identified NPAC regions for lnpNPAC-SMS-Name in the lnpNPAC-SMS object. The lnpLocal-SMS-Name for the lnpLocal-SMS object will be the service provider ID followed by a dash and the lnpNPA-SMS Name (e.g., 9999-Midwest Regional NPAC SMS).  Exhibit 13 — Defined lnpLocal-SMS-Name and lnpNPAC-SMS-Name Values                  NPAC Customer Ids   NPAC SMS Region   lnpNPAC-SMS-Name     0000    Midwest    Midwest Regional NPAC SMS               0001    Mid-Atlantic    Mid-Atlantic Regional NPAC SMS               0002    Northeast    Northeast Regional NPAC SMS               0003    Southeast    Southeast Regional NPAC SMS               0004    Southwest    Southwest Regional NPAC SMS               0005    Western    West Regional NPAC SMS               0006    West Coast    West Coast Regional NPAC SMS               0007    Canada    Region8 NPAC Canada        4.4   OID Usage Information       4.4.1   OIDs Used for Bind Requests                Value   OID     CMIPUserInfo    2:1:1 (per standards and pp.49 IIS1.5)           CMIPAbortInfo    2:1:1 (per standards and pp.51 IIS1.5)           LnpAccessControl    {lnp-attribute 1} = 1:3:6:1:4:1:103:7:0:0:2:1           UserInfo (NpacAssociationInfo)    1:3:6:1:4:1:103:7:0:0:2:105           Application context    2:9:0:0:2 (per standards)                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      35                   Interface Functionality to CMIP Definition Mapping       4.4.2   Other OIDs of Interest                Value   OID     AccessControl OID as part of a SMI notification    1:3:6:1:4:1:103:7:0:0:8:1           AccessControl as part of LNP notifications    {lnp-attribute 1} = 1:3:6:1:4:1:103:7:0:0:2:1        4.5   Naming Attributes    Non-zero values are not supported in the auto-instance naming attributes for Local Number Portability objects defined in the IIS.     4.6   Subscription Version M_DELETE Messages    M_DELETE commands are not sent for subscription versions set to old as a result of subsequent porting activity. M_DELETEs for subscription versions are only sent as a result of disconnect or port to original processing. Local SMS systems are responsible for deletion of the subscription versions in their Local SMS database due to the fact that some LSMS implementations may choose to retain old subscription versions in their database.     4.7   Number Pool Block M_DELETE Messages    M_DELETE commands are not sent for number pool blocks set to old as a result of subsequent porting activity. M_DELETEs for number pool blocks are only sent as a result of de-pool. Local SMS systems are responsible for deletion of the number pool blocks in their Local SMS database due to the fact that some LSMS implementations may choose to retain old number pool blocks in their database.     4.8   Subscription Version Queries    For Service Providers that support the enhanced SV Query functionality (Service Provider SV Query Indicator tunable parameter set to TRUE), the behavior is defined in this section.  If a subscription version query is requested by the SOA/LSMS, and the results are larger than the Maximum Subscription Query tunable value, the NPAC SMS will return subscription versions up to that max value. The SOA/LSMS would accept this message, then use it’s contents to send another query to the NPAC SMS, starting with the next TN, and so on until all SVs are returned to the SOA/LSMS. It will be up to the SOA/LSMS to manage the data returned from the NPAC SMS and determine the next request to send to the NPAC SMS in order to get the next set of subscription versions.  The NPAC SMS will continue to return subscription versions that meet the selection criteria. However, the NPAC SMS will not return a “count” to the SOA/LSMS for number of records that match the selection criteria. Service providers should modify their systems to support the following subscription version query operations to the NPAC SMS:       1.   When data is returned from a subscription version query and there are exactly n (tunable) records returned, the SP must assume that they didn’t get all the data from their query.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      36                   Interface Functionality to CMIP Definition Mapping         2.   After processing the first n records, they should send a new query that picks up where the data from the prior query ended.        3.   The subscription version data returned from the NPAC SMS for subscription version queries will be sorted by TN and then by subscription version ID so a filter can be created to pick up where the prior query ended.        4.   For example, if a SOA query to the NPAC SMS returns exactly 150 records and the last subscription version returned was TN ‘303-555-0150’ with subscription version ID of 1234. The filter used on the next query would be: All subscription versions where ((TN > 303-555-0150) OR (TN = 303-555-0150 AND subscription version ID > 1234).The NPAC SMS does support OR filters.        5.   Once the results from the NPAC SMS returns less than 150 records, the SP can assume they received all records in the requested query.            Note: In this situation the NPAC SMS follows the linked replies for the subscription query results with an empty reply (this is an indication that the NPAC SMS is finished sending data for this request.    As an example, a Service Provider’s SOA sends a Subscription Version query to the NPAC SMS, There are 225 Subscription Versions that meet the selection criteria. Assuming the Maximum Subscription Query tunable value is set to 150 Subscription Versions, the SOA would receive data from the NPAC SMS in the form of 150 Subscription Versions in 150 linked replies (1 SV per linked reply) followed by a reply (for a total of 151 linked replies). The SOA would then send another query based on the algorithm described above. The SOA would then receive data from the NPAC SMS in the form of 75 Subscription Versions in 75 linked replies (1 SV per linked reply) followed by a reply (for a total of 76 linked replies).  Note: In this situation the NPAC SMS follows the linked replies for the subscription query results with an empty reply (this is an indication that the NPAC SMS is finished sending data for this request).  For Service Providers that DO NOT support the enhanced SV Query functionality (Service Provider SV Query Indicator tunable parameter set to FALSE), a complexityLimitation error is returned when the number of SVs in a query response exceed the Maximum Subscription Query tunable value.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      37                   Secure Association Establishment    5 Secure Association Establishment  [Graphic Omitted: 5]     5.1   Overview    This section describes the security, the association management and recovery procedures for the service provider SOAs and Local SMSs to follow, and how error information will be passed between interfaces.  The first section describes the security and authentication procedures used in the NPAC SMS interface. The second section describes the NPAC SMS’s behavior and error handling and suggests how a service provider SOA or Local SMS should proceed when establishing an association.     5.2   Security    This section describes the security processes and procedures necessary for service provider SOA systems and Local SMSs to establish a secure association and maintain secure communication with the NPAC SMS. Security threats to the NPAC SMS include:       •   Spoofing — An intruder may masquerade as either the SOA, Local SMS, or NPAC SMS to falsely report information.        •   Message Tampering — An intruder may modify, delete, or create messages passed.        •   Denial or Disruption of Service — An intruder may cause denial or disruption of service by generating or modifying messages.        •   Diversion of Resources — An intruder may generate or modify messages that cause resources to be diverted to unnecessary tasks.        •   Slamming — An intruder may generate or modify messages that cause customer’s service to be moved between service providers.    Security threats are prevented in the NPAC SMS by use of the following methods:       •   Strong two way authentication at association.        •   Insuring data integrity by detection of replay, deletion, or modification to a message.        •   Insuring non-repudiation of data by guaranteeing integrity and supporting data origination authentication for each incoming message.        •   Implementation of access control and application level security that allows only authorized parties to cause changes to the NPAC SMS database.    5.2.1 Authentication and Access Control Information  The following access control information definition will be used in the AccessControl field of the association and CMIP PDUs to ensure a secure communication for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface:                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      38                   Secure Association Establishment                                                                             LnpAccessControl ::= SEQUENCE {                systemId    [0]    SystemID,                systemType    [1]    SystemType,                userId    [2]    GraphicString60 OPTIONAL,                listId    [3]    INTEGER,                keyId    [4]    INTEGER,                cmipDepartureTime    [5]    GeneralizedTime,                sequenceNumber    [6]    INTEGER (0...4294967295),                function    [7]    AssociationFunction,                recoveryMode    [8]    BOOLEAN signature                signature    [9]    BIT STRING            }                                                ServiceProvId ::= GraphicFixedString4                                    SystemID ::= CHOICE {               serviceProvID [0] ServiceProvId,               npac-sms [1] GraphicString60            }                                                SystemType ::= ENUMERATED {                soa(0),                        local-sms(1),                       soa-and-local-sms(2), — value not supported                                         npac-sms(3)          —value is only valid for AccessControl definition            }                                                AssociationFunction ::= SEQUENCE {               soaUnits [0] SoaUnits,               lsmsUnits [1] LSMSUnits            }                                                SoaUnits ::= SEQUENCE {               soaMgmt [0] NULL OPTIONAL,               networkDataMgmt [1] NULL OPTIONAL,               dataDownload [2] NULL OPTIONAL               notificationDownload [3] NULL OPTIONAL            }                                                LSMSUnits ::= SEQUENCE {               dataDownload [0] NULL OPTIONAL,               networkDataMgmt [1] NULL OPTIONAL,               query [2] NULL OPTIONAL            }                                                        Exhibit 4. Access Control                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      39                   Secure Association Establishment    5.2.1.1 System Id  The system Id is the unique Id for the system using an interoperable interface and must be specified in the systemId field. For a service provider using the SOA and/or Local SMS interfaces, this is the Service Provider ID. For the NPAC SMS, it is the unique identifier for the regional SMS.  In cases where a service provider is providing SOA services for an associated service provider, the primary service provider must establish the association with their System Id set to their primary Service Provider ID. PDUs that are subsequently sent to the NPAC SMS may contain the primary or associated Service Provider Ids of the requesting service provider. Associated Service Provider Ids are sent in the System Id when actions are being taken on behalf of an associated service provider by the service provider providing SOA services (the primary service provider). The Service Provider ID specified in the access control for PDUs sent after association establishment, whether it’s the primary or secondary Service Provider ID, is considered the requesting service provider and all validations will use this Service Provider ID.  5.2.1.2 System Type  The system type that indicates the type of system using the interoperable interface must be specified in the systemType field. The valid types are SOA and/or Local SMS and NPAC SMS.  5.2.1.3 User Id  The user Id of the user of the interface can optionally be specified in the userId field for the SOA interface. This is the 60 character graphics string user identifier for a user on a SOA system. It is not validated on the NPAC SMS, however, it is used for logging purposes.  5.2.1.4 List Id  The list Id must be specified as an integer in the listId field to identify a key list. This key list is one of the key lists exchanged outside of the interface process that is known to both the NPAC SMS and the Local SMS or SOA system it is communicating with.  NPAC key lists and service provider key lists are to be managed based upon service provider id and presentations layer address (P-selector) of the service provider’s SOA system and/or Local SMS system. Also, a given service provider id and P-selector value can exist for one or more Network Service Access Points (NSAP).  The NPAC SMS must generate and maintain NPAC key lists based upon the service provider’s service provider id and P-selector value of the system(s) that support its SOA and LSMS interfaces. In addition, service providers(SOA systems and Local SMS systems) must also manage the NPAC’s key lists. Each side of the interface must support multiple NPAC key lists per service provider id and P-selector value.  Service providers (SOA system and Local SMS system) must generate and maintain key lists based upon the service provider’s service provider id and P-selector value of the system(s) that support its SOA and LSMS interfaces. Furthermore, the NPAC SMS must also manage the service provider’s key lists.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      40                   Secure Association Establishment    Each side of the interface must support multiple service provider(SOA system and Local SMS) key lists per service provider id and P-selector value.  In cases where a service provider is providing SOA services for an associated service provider, key lists are only exchanged with the primary service provider using the primary service provider id.  5.2.1.5 Key Id  The key Id of a key in the key list must be specified as an integer in the keyId field. This uniquely identifies the key in the key list used to create the digital signature. The size of the modulus for the key is variable between 600 and 2048 bits.  Since key lists are to be managed based upon service provider id and the P-selector value of a service provider’s SOA system and/or Local SMS system, keys are to be treated independently at the presentation layer for an association. By using presentation layer support of a key list, SOA and Local SMS systems can have one key or unique keys to support the SOA and LSMS interfaces. The following situations are supported:       1.   If a service provider has one process supporting the SOA and LSMS interface, then the process has one P-selector value supporting both interfaces. The SOA/Local SMS system would use the same key list and the same key for all associations created for the both the SOA and LSMS interface. The NPAC SMS would in turn have one NPAC key list and key to support both interfaces.        2.   If a service provider has two processes supporting the SOA and LSMS interface, then each process would have different P-selector values. The SOA and Local SMS systems would use separate key lists and keys per interface. In detail, the SOA system would use a key list and key for all associations involving the SOA interface and the Local SMS system would use a different key list and key for all associations involving the LSMS interface. The NPAC SMS would also manage separate key lists and keys per the SOA and LSMS interface. Furthermore, the NPAC SMS would use the same key list and key for all associations within a given interface.        3.   If a service provider has an SOA system or a Local SMS system that consists of multiple processes, then each processes would have different P-selector values. Therefore, each process would manage separate key lists and separate keys per process. The NPAC SMS would also manage separate key lists/keys per process. For example, if a Local SMS system consists of 2 processes (one process supporting subscription data and the other supporting network/query data), the processes would have separate P-selector values and use separate key lists/keys per association. The NPAC SMS would also manage separate key lists and keys per process within the LSMS interface.    Note: In cases where a service provider is providing SOA services for an associated service provider, keys are used from primary service provider key lists  If the service provider determines their key is compromised they should change their own private key and list. If the NPAC determines that their key is compromised then they should change their own private key and list. The NPAC should not invalidate a service provider’s key and vice versa. However, should                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      41                   Secure Association Establishment    either side of the industry interfaces (SOA and Local SMS interface) change keys, the remote side is expected to mark the previously used key as used (key expiration). Previously used keys (ListId/KeyId combinations) are considered expired and result in a security violation across the industry interface when re-used.  5.2.1.6 CMIP Departure Time  The CMIP departure time must be specified in GeneralizedTime in the cmipDepartureTime field as the time the PDU departed the sending system. The universal time format (YYYYMMDDHHMMSS.0Z) is used. In order to ensure data integrity and no-repudiation the NPAC SMS system must be synchronized to within five minutes of the Local SMS and SOA systems that it communicates.  5.2.1.7 Sequence Number  The sequence number is a 32 bit integer that must be specified in the sequenceNumber field. It should be specified as zero at association time and incremented by one for every message sent over the association. Once the sequence number reaches 4294967295 the counter will be reset to one for the association. Please note that each sender independently keeps its own counter for the sequence number of messages sent and received. For example, after association is established, a Local SMS could send three messages to the NPAC SMS with sequence numbers 1, 2, and 3 respectively. The NPAC SMS when sending its first message to the Local SMS would use sequence number 1 not sequence number 4.  5.2.1.8 Association Functions  The Association Function(s) must be specified on the initial association request (AARQ PDU). The following table lists the possible Association Functions that can be specified for each of the Association Request Initiators and the associated bit mask value:  Exhibit 75 Association Functions                                              Association Function Association Request Initiator   SOA     Local SMS       SOA Management (Audit and Subscription Version)   0x02             Classes:                   lnpSubscriptions                   numberPoolBlock                   numberPoolBlockNPAC                   subscriptionAudit                   subscriptionVersion                   subscriptionVersionNPAC                                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      42                   Secure Association Establishment                                                Association Function Association Request Initiator   SOA     Local SMS       Service Provider and Network Data Management     0x02       0x04     Classes:                   lnpNetwork                   lnpNPAC-SMS                   lnpServiceProvs                    lsmsFilterNPA-NXX                   serviceProv                   serviceProvLRN                   serviceProvNetwork                   serviceProv-NPA-NXX                   serviceProvNPA-NXX-X                                        LSMS Network and Subscription Data Download             0x08     Classes:                   lnpNetwork                   lnpSubscriptions                                       SOA Network Data Download     0x20              Classes:                   LnpNetwork                                         Query Outbound from the NPAC SMS             0x10      Classes:                   All                                         SOA Notifications (only applicable for SOAs supporting a separate notification association)     0x40             Classes:                   lnpNPAC-SMS                   lnpSubscriptions                   numberPoolBlockNPAC                   subscriptionAudit                   subscriptionVersionNPAC                     The association functions specified upon association are stored. Then all subsequent operations performed by that associations are then validated against that data to verify that they are ‘legal’. All outbound messages from the NPAC are also validated against the association functions and if a service provider does not have the correct masking set, they will not receive the transmission. Note that the multiple Association Functions can be specified for an association. For example, a Local SMS can establish an association for both the process audit and network and subscription data download association functions.  SOA Notifications have been separated out to support SOAs that wish to implement a separate SOA Channel for Notifications. Based on the Service Provider tunable (SOA Notification Channel Service Provider Tunable), this function may be included in a SOA association, even if the Service Provider does not bind with that function mask. This allows SOA notifications to be sent down a single SOA channel.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      43                   Secure Association Establishment    5.2.1.9 Recovery Mode  The recovery mode flag is set to TRUE when a Local SMS or SOA is establishing a connection after a downtime. This flag indicates to the NPAC SMS to hold all current transactions until the Local SMS or SOA sends the Recovery Complete action. Once an association is established in recovery mode by a Local SMS, the Local SMS should request service provider, subscription and network downloads and notifications that occurred during downtime. Once an association is established in recovery mode by a SOA, the SOA should request service provider and network downloads and notifications that occurred during downtime. After these steps are complete, the Local SMS or SOA should submit the Recovery Complete action. The NPAC SMS will respond to the recovery complete action, send all updates that occurred since association establishment and then normal processing will resume. See Appendix B, Section 7.1.  Service Provider Local SMS and SOA systems recover data independently. SOA systems can recover their information before, after, or concurrently with an LSMS using the same Service Provider Id.  A service provider providing SOA services for associated service providers can recover notifications for the primary and each associated service provider id prior to issuing the Recovery Complete action.  Alternatively, Service Provider Local SMS and SOA systems can recover data using the SWIM method. Refer to section 5.3.4 (Recovery) for more information.  5.2.1.10 Signature  The signature field contains the MD5 hashed and encrypted systemId, the system type, the userId, the cmipDepartureTime, and sequenceNumber without separators between those fields or other additional characters. Before hashing and encryptions, character fields are ASCII format and integer fields are 32 bit big endian. Encryption is done using RSA encryption using the key from the key list specified. Validation of this field ensures data integrity and non-repudiation of data. The following is additional information about how the information should be represented for digital signature encoding:                  Field   Format   Contents     SystemID   ASCII                   SystemType   Integer   e.g. local-sms = 1               UserId   ASCII                   cmipDepartureTime   ASCII   “YYYYMMDDHHMMSS.OZ” format               sequenceNumber   Integer                     5.2.2 Association Establishment  Strong two way authentication at association is done for both the SOA to NPAC SMS interface and the NPAC SMS to Local SMS interface. This secure association establishment is done at the application level using the access control field described                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      44                   Secure Association Establishment    above. The access control information used during association set-up is sent in the association control messages. Association establishment can be done by the SOA to NPAC SMS or Local SMS to NPAC SMS. The NPAC SMS cannot initiate an association. The initiator of the association specifies its information in the AARQ PDU message and the responder in the AARE PDU.  When the SOA or LSMS initiate an association with the NPAC the NSAP and P-selector values will be validated to ensure that they are valid for the service provider initiating the association. The following is an example of the information exchanged in the AARQ and AARE PDUs and the processing involved. Assume for the example:       •   A Local SMS is making an association with the NPAC SMS.        •   The Local SMS systemId is “9999.”        •   The NPAC SMS systemId is “NPAC SMS User Id.”        •   The listId for the key list is 1.        •   The keyId is 32.        •   The key in listId 1 with a keyId of 32 is “ABC123.”        •   The sequence number is 0 (as required).    The Local SMS initiates the association request by creating and sending an AARQ PDU to the NPAC SMS. This AARQ PDU contains the following access control information in the syntax described above:       •   The systemId of “9999”.        •   The listId of 1.        •   The keyId of 32.        •   The current Local SMS GMT time in the cmipDepartureTime.        •   A sequence number of 0.        •   The signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key id 32.        •   And all BOOLEAN items are set to FALSE in the functional groups field, except for the LSMSUnit of Query item which is set to TRUE.    Once the AARQ PDU is sent, the sender (in this case the Local SMS), starts a tunable timer (with a default value of 2 minutes). If the timer expires before the AARE PDU is received then the Local SMS will terminate the association attempt.  When the NPAC SMS receives the association request it validates the data received. The data is validated as follows:       •   Ensure the systemId is present and valid for the association.        •   Ensure the sequence number is 0.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      45                   Secure Association Establishment         •   Ensure the cmipDepartureTime is within 5 minutes of the current NPAC SMS GMT time.        •   Find the key specified and decrypt the signature insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.        •   The functional groups requested are valid for the system type that requested the association. In this example, the system type must be “local-sms(1)” {“soa-andlocal-sms(2)” value is to be removed from a future version of the IIS}.    If validation of the AARQ PDU fails then an A-ABORT will be issued by the NPAC SMS with an error of access denied. If the validation of the AARQ PDU is successful then an AARE PDU would be sent back to the Local SMS. This AARE PDU contains the following access control information in the syntax described above:       •   The systemId of “NPAC SMS User Id.”        •   The listId of 1.        •   The keyId of 32.        •   The current NPAC SMS GMT time in the cmipDepartureTime.        •   A sequence number of 0.        •   And the signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key id 32.    The NPAC SMS may choose to optionally specify a new listId and keyId if for any reason it wants to make a key change. Should either side of the interface change its listId/keyId values, both sides of the interface must mark the previously used keyId as used.  When the Local SMS receives the association response it validates the data received. The data is validated as follows:       •   Ensure the systemId is present and valid for the association. (Note: the userId field is not required for Local SMS and NPAC SMS associations).        •   Ensure the sequence number is 0.        •   Ensure the cmipDepartureTime is within 5 minutes of the current Local SMS GMT time.        •   Find the key specified and decrypt the signature insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.    If validation of the AARE PDU fails then an A-ABORT will be issued by the Local SMS. If validation is successful then a secure association has been established.  5.2.3 Data Origination Authentication  For M-GET, M-SET, M-CREATE, M-DELETE, and M-ACTION, the access control field described above is used for data origination authentication. Please note that any of the messages sent between manager and agent must be sent in confirmed mode. The                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      46                   Secure Association Establishment    following is an example of the information exchanged in the CMIP PDUs and the processing involved. Assume for the example:       •   A SOA is making an association with the NPAC SMS.        •   The SOA system provides SOA functionality for another Service Provider.        •   The SOA systemId is “9999” for the primary Service Provider Id and is “8888” for an associated Service Provider Id.        •   The NPAC SMS systemId is “NPAC SMS User Id.”        •   The listId for the key list is 1.        •   The keyId is 32.        •   The key in listId 1 with a keyId of 32 is “ABC123.”        •   The sequence number is 1.    The SOA sends an M-GET to the NPAC SMS. The M-GET PDU contains the following access control information in the syntax described above:       •   The systemId of “8888.”        •   The listId of 1.        •   The keyId of 32.        •   The current Local SMS GMT time in the cmipDepartureTime.        •   A sequence number of 1.        •   And the signature contains MD5 hashed and encrypted systemId, systemType, userId, cmipDepartureTime, and the sequenceNumber using the encryption key “ABC123” as found in key list 1 with key Id 32.    Once the M-GET is sent, the sender (in this case the SOA), starts a tunable timer (with a default value of 2 minutes). If the timer expires before the M-GET CMISE service response is received then the SOA will regenerate the sequenceNumber, cmipDepartureTime and signature and resend the request. The SOA should resend a default of 3 times and abort the association if no response is received. If a response is received after the timeout period, it should be discarded. If an error message is received on a retry request, it should be evaluated to see if the request was processed or the error was received for other reasons. For example, an error of “duplicateObjectInstance” for an M-CREATE request most likely indicates a successful create.  When the NPAC SMS receives the M-GET request it validates the data received. The data is validated as follows:       •   Ensure the systemId is present and valid for the association. For the SOA the systemId can be the primary or associated Service Provider Id depending on the requestor.        •   Ensure the sequence number is the next sequence number expected. (In this case 1).        •   Ensure the cmipDepartureTime is within 5 minutes of the current NPAC SMS time.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      47                   Secure Association Establishment         •   Find the key specified and decrypt the signature, insuring that the systemId, systemType, userId, cmipDepartureTime, and sequenceNumber are the same as those specified in the PDU.    If validation of the M-GET PDU fails then an A-ABORT will be issued by the NPAC SMS without any additional information to prevent tampering and unauthorized use of network resources by intruders. If the validation of the M-GET PDU is successful then the NPAC SMS would get the data requested and send back an M-GET Response to the SOA.  Since CMIP notifications (M-EVENT-REPORT) do not have access control fields, all notifications defined contain the access control information in the notification definition. ObjectCreation, ObjectDeletion, and AttributeValueChange should use the “information” attribute, which is an ANY DEFINED BY to contain the access control field. The values and authentication for the notification access control fields are the same as above. For range ObjectCreation and AttributeValueChange notifications the access control would not be placed in the information attribute but rather in the access control attribute defined. This would allow for the access control information to only be present once in the range notifications.  When the NPAC sends a notification, the destination service provider is uniquely identified in the distinguishedName of the M-EVENT-REPORT. The lnpLocalSMS-Name attribute value(2.17) is appended to the service provider’s id and is used to populate the value of the first element of the EventReportArgument’s managedObjectInstance distinguishedName. This allows primary service providers to distinguish notifications destined for themselves and for each secondary service provider.  5.2.4 Audit Trail  Audit trails will be maintained in logs on the NPAC SMS for the following association information:       •   Association set-up messages.        •   Association termination messages.        •   Invalid messages:         •   Invalid digital signature.        •   Sequence number out of order.        •   Generalized time out of range.        •   Invalid origination address.         •   All incoming messages regardless of whether or not they cause changes to data stored in the NPAC SMS.    This information will be made available for report generation on the NPAC SMS system. It will not be made available through the NPAC SMS Interoperable Interface.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      48                   Secure Association Establishment    5.3 Association Management and Recovery  5.3.1 Establishing Associations  5.3.1.1 NpacAssociationUserInfo  The following structure will be used to report the status of a login attempt or the current state of the NPAC SMS:  NpacAssociationUserInfo ::= SEQUENCE {  error-code [0] IMPLICIT ErrorCode,  error-text [1] IMPLICIT GraphicString(SIZE(1..80))   }  ErrorCode ::= ENUMERATED   {  success (0),  access-denied (1)  retry-same-host (2)  try-other-host (3)   }  Bind Requests and Responses  For AARQ (M-Bind requests) the NPAC SMS will be ignoring the CMIPUserInfo userInfo field. The SMASEUserInfo will be ignored by the NPAC SMS.  In order to validate a successful login, the AARE (M-Bind response) from the NPAC SMS will contain the NpacAssociationUserInfo as the “userInfo” field of the CMIPUserInfo that is contained on the AARE. The ErrorCode will be set to “success”.  The following structure will be used for CMIPUserInfo:  CMIPUserInfo ::= 2:9:1:1:4 —{joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1) abstractSyntax(4)}  CMIPUserInfo ::= SEQUENCE {  protocolVersion [0] IMPLICIT ProtocolVersion DEFAULT {version1-cmip-assoc}, functionalUnits [1] IMPLICIT FunctionalUnits DEFAULT {}, accessControl   [2] EXTERNAL OPTIONAL userInfo            [3] EXTERNAL OPTIONAL   }  5.3.1.2 Unbind Requests and Responses  The NPAC SMS will never be issuing the RLRQ (M-Unbind request), but will respond to them from the SOA or Local SMS.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      49                   Secure Association Establishment    5.3.1.3 Aborts  For unsuccessful logon attempts or situations where the NPAC SMS application must abort all associations, the ABRT CMIPAbortInfo structure’s “userInfo” will contain the NpacAssociationUserInfo structure. The ErrorCode will be set to one of the enumeration values.  The following structure will be used for CMIPAbortInfo:  CMIPAbortInfo ::= 2:9:1:1:4 —{joint-iso-ccitt(2) ms(9) cmip(1) cmip-pci(1) abstractSyntax(4)}  CMIPAbortInfo ::= SEQUENCE {  abortSource [0] IMPLICIT CMIPAbortSource, userInfo [1] EXTERNAL OPTIONAL   }  5.3.1.4 NPAC SMS Failover Behavior  Under normal conditions, the primary NPAC SMS will be responding by accepting association requests while the secondary NPAC SMS will be responding by denying association requests with an ABRT and error code of TRY_OTHER_HOST.  When the primary NPAC SMS needs to go down for a short period of time (secondary will not take over), the primary NPAC SMS will either not be responding (if down) or be denying association requests with an error code of RETRY _SAME_HOST (if partially up). The secondary NPAC SMS will be responding by denying association requests with an ABRT and error code of TRY_OTHER_HOST.  When the primary NPAC SMS goes down (scheduled or unscheduled) and the secondary NPAC SMS is re-synchronizing to become active, the primary NPAC SMS will be denying association requests with an ABRT and error code of TRY_OTHER_HOST. The secondary NPAC SMS will be responding by denying association requests with an ABRT and error code of RETRY_SAME_HOST. Once the secondary NPAC SMS is done re-synchronizing, it will then start accepting association requests.  5.3.1.5 Service Provider SOA and Local SMS Procedures  The following is an algorithm that can be used by a service provider SOA or Local SMS when trying to establish an association with the NPAC SMS:  try to establish an association on the primary NPAC SMS if a response was obtained {  if the response was an ABRT and the ABRT is from the NPAC Application {  switch (error code) {  case ACCESS_DENIED find out what is causing the error and fix it                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      50                   Secure Association Establishment         retry the association on the primary NPAC SMS case RETRY_SAME_HOST      wait X seconds      retry the association on the primary NPAC SMS case TRY_OTHER_HOST      wait X seconds      execute this algorithm again substituting      “secondary” for “primary”       } } else {  if the response was an ABRT and from the PROVIDER (not application)  find out what is causing the error and fix it retry the association on either the primary or secondary NPAC SMS       } else {                                        #   timeout — some type of network error has occurred           #   a number of different things can be done:            #                       #       wait X seconds           #       retry primary            #                        #            or            #                       #       find out what is causing the error and fix it           #       retry the association on the primary NPAC SMS            #                        #            or            #                       #       wait X seconds           #       execute this algorithm again substituting           #       “secondary” for “primary”        }                     5.3.2 Releasing or Aborting Associations  Any of the systems, NPAC SMS, service provider SOA or Local SMS can abort an association at any time. Only the SOA and Local SMS can perform an RLRQ request. Once a scheduled outage has arrived, the NPAC SMS will abort associations (error code of “Try Other Host” or “Retry Same Host” depending on the type of outage).                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997 — 2006 NeuStar, Inc.      51                   Secure Association Establishment       5.3.3   Error Handling      5.3.3.1   NPAC SMS Error Handling    The NPAC SMS will issue errors to the Local SMS and SOA interfaces based upon the definitions and mappings in Appendix A. The NPAC SMS expects the SOA and Local SMS to support the same error definitions when both issuing (with the exception of a sending processingFailure as defined in ILL 130) and receiving error responses for the operations each interface supports.  The NPAC SMS will attempt to interpret an error returned from a SOA or Local SMS. The NPAC SMS will log the error. If the request is not resent and the error response was returned from a Local SMS and related to a subscription version broadcast (M-CREATE or Create Action, M-DELETE, M-SET), a broadcast failure will be noted for the service provider on the subscription version. If a service provider does not have an active Local SMS association at the time of a broadcast, the broadcast will be automatically failed for the service provider.  The Local SMS and SOA are expected to recover themselves with the NPAC SMS when their association is reestablished. Thus it is the responsibility of the Local SMS and SOA to request the necessary data to rectify the failed transmission of M-EVENT-REPORTs, network data updates and non-broadcast oriented subscription version updates.  If the NPAC SMS sends a request to a Local SMS or SOA and receives no response from the CMISE service within the tunable period, the NPAC SMS will resend the message according to the tunable retry periods for the specific message type. If a response is received after the timeout period, it will be discarded. If the NPAC SMS receives no response, the NPAC SMS will assume the association is down and abort the connection. The Local SMS and SOA systems should assume the same behavior with the NPAC SMS.     5.3.3.2   Processing Failure Error    The NPAC SMS will use the Service Provider profile flags (SOA Action Application Level Errors Indicator, SOA Non-Action Application Level Errors Indicator, LSMS Action Application Level Errors Indicator, and LSMS Non-Action Application Level Errors Indicator) to determine the handling of Processing Failure errors. When they are not supported:  In addition to the standard CMIP error reporting mechanisms, the following attribute will be passed in the SpecificErrorInfo structure on CMIP errors that return a PROCESSING FAILURE error. This structure will be used to detail errors not covered by the standard CMIP error codes.  GDMO Definition  lnpSpecificInfo ATTRIBUTE  WITH ATTRIBUTE SYNTAX LNP-ASN1.LnpSpecificInfo;  MATCHES FOR EQUALITY;  BEHAVIOUR lnpSpecificInfoBehavior;  REGISTERED AS {lnp-attribute 8};  lnpSpecificInfoBehavior BEHAVIOUR  DEFINED AS !  This attribute is used to return more detailed error text information upon a CMIP Processing Failure error.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      52                   Secure Association Establishment    !;  ASN.1 Definition  LnpSpecificInfo ::= GraphicString(SIZE(1..256))  When the Service Provider profile flags (SOA Application Level M-ACTION Errors Indicator, SOA Non-Action Application Level Errors Indicator, LSMS Application Level Errors M-ACTION Indicator, and LSMS Non-Action Application Level Errors) are supported, the Processing Failure error will contain an lnpSpecificErrorCode instead of lnpSpecificInfo.     5.3.3.3   NPAC SMS Detailed Error Codes    The NPAC SMS will issue detailed error codes to the supporting SOA and Local SMS interfaces based upon the definitions and mappings in Appendix A. The Service Provider profile flags (SOA Application Level Errors Indicator, LSMS Application Level Errors Indicator) will indicate whether application level errors are supported across the SOA/LSMS interfaces. When they are supported:       •   The SOA/LSMS will utilize ACTIONs that support detailed error codes (e.g., M-ACTION subscriptionVersionActivateWithErrorCode), as defined in Exhibit 10. The SOA/LSMS may still utilize ACTIONs that do not support detailed error codes.        •   All other CMIP messages (e.g., M-CREATE serviceProvNPA-NXX) will be supported through a processingFailure response that will contain the detailed error code, instead of the other CMIP standard errors.    This allows all messages to be covered for the detailed error codes for SOA/LSMS interfaces that support this features.  For SOA/LSMS interfaces that do not support this feature, an ACTION that supports error codes will result in a no-such-action error response.     5.3.4   Recovery    The SOA and Local SMS associations are viewed to be permanent connections by the NPAC SMS. Thus when the association is broken for any reason, the system connecting to the NPAC SMS must assume responsibility to recover and resynchronize themselves with the NPAC SMS. One association should be established for recovery and no other associations should be established in normal mode until recovery is complete.  During the recovery processing, other messages may be generated at the NPAC SMS that are intended for the recovering SOA or LSMS. These messages are queued on the NPAC SMS until the SOA or LSMS finishes the recovery process and sends an lnpRecoveryComplete action to the NPAC SMS. Additionally, during the recovery process, the “x by y” retry functionality (where “x” is the number of attempts, and “y” is the interval in number of minutes in between attempts) continues on the NPAC SMS, but message sending is suspended to the SOA or LSMS, and the retry attempts counter is not decremented, as long as the SOA or LSMS is still in recovery mode. Therefore, a Subscription Version could stay in a “sending” status for a period of time longer than expected, since the retry logic will not transition the status to “partial failure” or “failed” as long as a Service Provider is in recovery mode.  While recovering subscription data, the NPAC SMS excludes Subscription Versions with a status of failed. The value in the Broadcast Timestamp field in each Subscription Version is used to determine whether or not a Subscription Version is included in the recovering LSMS’s requested criteria.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      53                   Secure Association Establishment    The SOA or LSMS is capable of recovering data based on the association functions. The SOA recovers service provider, network data and notification data using the network data management association function (networkDataMgmt). The LSMS recovers notifications and subscription data using the data download association function (dataDownload), and recovers service provider and network data using the network data management association function (networkDataMgmt).  Service Provider and Notification recovery requests can only be sent to the NPAC when the SOA/LSMS is in recovery mode, otherwise an error message is returned.  NPAC data may be recovered in three ways, ‘time-based’, ‘record-based’, or ‘Send What I Missed (SWIM)-based’criteria. Based on the type of data being recovered, additional criteria may also be specified. The table below show the type of data that can be recovered, and the criteria that may be used for each type.                  Data Type   Criteria   Additional Criteria         Network Data    Time Based    Time Range (consisting of Start time, End time)                    Record-Based    NPA-NXX range                        all NPA-NXX data                        NPA-NXX-X range                        all NPA-NXX-X data                        LRN range                        all LRN data              all network data                    SWIM    conditional Action ID (indicating receipt of previous response for <Network> data)               Service Provider Data    Time Based    Time Range (consisting of Start time, End time)                    Record Based    Service Provider ID                        All Service Providers                    SWIM    conditional Action ID (indicating receipt of previous response for <Service Provider> data)               Subscription Data    Time-Based    Time Range (consisting of Start time, End time)                    Record-Based    TN                        TN range                    SWIM    conditional Action ID (indicating receipt of previous response for <Subscription> data)               Number Pool Block Data    Time-Based    Time Range (consisting of Start time, End time)                    Record-Based    NPA-NXX-X                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      54                   Secure Association Establishment                    Data Type   Criteria   Additional Criteria                  NPA-NXX-X range                    SWIM    conditional Action ID (indicating receipt of previous response for <Number Pool Block> data)               Notification Data    Time-Based    Time Range (consisting of Start time, End time)                    Record-Based    Not Available                    SWIM    Time Range (consisting of Start time, End Time) is ignored in a SWIM recovery request Conditional Action ID (indicating receipt of previous response for <Notification> data)     ‘Time-Based’ Recovery Requests  All ‘time-based’ recovery requests specifying time range criteria are limited to the NPAC SMS tunable, “Maximum Download Duration”. When the SOA or LSMS issues a recovery request (whether Service Provider, Network, Subscription, Number Pool Block, or Notification Data) with time-based criteria, the NPAC SMS will compare the time range indicated in the request to the “Maximum Download Duration” tunable.  For service providers that do not support linked replies, Subscription data ‘time-based’ recovery requests specifying time range criteria are also limited to the number of TNs specified in the Service Provider specific tunable, “Maximum TN Download in Recovery Request”. Therefore, a valid request will fall within both the duration and quantity tunable values.  For service providers that do not support linked replies, Notification data ‘time-based’ recovery requests specifying time range criteria are also limited to the number of notifications specified in the NPAC SMS tunable, “Maximum Number of Download Notifications”. Therefore, a valid request will fall within both the duration and quantity tunable values.  For service providers that do not support linked replies, for all types of ‘time-based’ recovery requests, where the tunable value is exceeded, an appropriate error message is issued over the interface from the NPAC SMS to the originating system. This applies to both duration overages (“Maximum Download Duration”), and number of record overages (“Maximum TN Download in Recovery Request” for subscription data, and “Maximum Number of Download Notifications” for notification data).  ‘Record-Based’ Recovery Requests  For service providers that do not support linked replies, all ‘record-based’ recovery requests specifying other criteria (for example, TN/TN range, NPA-NXX/NPA-NXX range) are limited by the number of records specified in the NPAC SMS tunable, “Maximum Number of Download Records”. When the SOA or LSMS issues a network data recovery request or the LSMS issues a subscription version data recovery request, using ‘record-based’ criteria, the NPAC SMS will compare the records indicated in the request to the “Maximum Number of Download Records” tunable. If the number of records exceeds this tunable value, an appropriate error message is issued over the interface from the NPAC SMS to the originating system.  ‘SWIM-Based’ Recovery Requests                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      55                   Secure Association Establishment    ‘SWIM-based’ recovery requests allow for the recovery of service provider, network, subscription, number pool block, and notification data where the NPAC SMS replies to the originating SOA/LSMS with the missed data, by using linked replies. The NPAC SMS will keep track of messages destined for a SOA/LSMS that were NOT successfully responded to by the SOA/LSMS, when the service provider system supports SWIM recovery (SP Profile Flags, SOA SWIM Indicator = TRUE and LSMS SWIM Indicator = TRUE). Missed messages will be stored based on the limits of the SOA SWIM Maximum and LSMS SWIM Maximum tunables. SWIM based recovery requests can only be sent to the NPAC when the SOA/LSMS is in recovery mode, otherwise an error message is returned.  During SWIM based recovery, the SOA/LSMS issue recovery requests for each type of data, and the NPAC SMS will issue recovery responses based on the SP Profile flags for ranges, notification types and EDR for the missed messages and limit the responses by the respective Linked Reply Blocking Factor and Maximum Linked Recovered Object tunables for each data type. Each response from the NPAC SMS will contain a status and ACTION_ID. The status will be one of the following:       •   Success    An NPAC SMS response that includes a status of Success indicates that SWIM recovery for the data type specified can be completed in either a single reply (with a status of Success and an ACTION_ID) or multiple linked replies (each with a status of Success and the same ACTION_ID in each reply, except for the last linked reply which will be empty – indicating the end of the linked reply data). In this case the Service Provider system must issue an M-EVENT-REPORT notification including the ACTION_ID in order for the NPAC SMS to clear the SWIM list for this data type and continue the recovery processing.       •   Failed    An NPAC SMS response that includes a status of Failed indicates the NPAC failed to process the recovery request. An ACTION_ID is included, however the Service Provider system does not need to issue an M-EVENT-REPORT notification. The Service Provider system should re-start the recovery process with a new recovery request.       •   No-Data-Selected    An NPAC SMS response that includes a status of No-Data-Selected indicates there isn’t SWIM data for the requested data type to recover. The response will include an ACTION_ID and the Service Provider system must issue an M-EVENT-REPORT notification including the ACTION_ID to continue the recovery processing.       •   Swim-More-Data    An NPAC SMS response that includes a status of Swim-More-Data indicates that the SWIM recovery for the data type specified includes an amount of data greater than the Linked Reply Maximum and requires subsequent download request in order to recover all the data on the SWIM list.  When the Service Provider system receives an NPAC SMS ACTION response with linked replies that include an ACTION_ID and status of Swim-More-Data in each of the replies, the Service Provider system should issue a subsequent recovery request including this ACTION_ID. The NPAC SMS will issue an ACTION Response for the next set of data and clear the SWIM list for the (linked reply) data already downloaded and processed. This subsequent ACTION response from the NPAC SMS will include a new ACTION_ID (the same in each of the linked replies for this response) and a status of either Swim-More-Data in each reply or Success in each reply followed by an empty reply. The Service Provider system and the NPAC SMS                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      56                   Secure Association Establishment    will continue this message exchange until the NPAC SMS ACTION Response indicates a status of Success (for each linked reply in that response).  After the Service Provider system receives an ACTION Response from the NPAC SMS indicating a status of Success and an ACTION_ID, the Service Provider system must issue an M-EVENT-REPORT notification including the most recent ACTION_ID in order for the NPAC SMS to clear this last set of (linked reply) data that was downloaded and processed, from the SWIM list for this data type and continue the recovery processing.  After the Service Provider system receives an ACTION Response from the NPAC SMS indicating a status of either Success or No-Data-Selected and an ACTION_ID, the Service Provider system must issue an M-EVENT-REPORT notification including the most recent ACTION_ID. The M-EVENT-REPORT reply from the NPAC SMS will contain one of the following responses:       •   Success    An NPAC SMS M-EVENT-REPORT reply that includes a status of Success indicates that the recovery request has been completed for this data type and if there was data downloaded, that data has been cleared from the SWIM list.       •   Failed With an Error Code    An NPAC SMS M-EVENT-REPORT reply that includes a status of Failed with an Error Code indicates that the recovery request failed and the Service Provider system should repeat recovery for that data type.       •   Failed With an Error Code and a Stop-Date (timestamp)    An NPAC SMS M-EVENT-REPORT reply that includes a status of Failed with an Error Code and a stop-date (timestamp) indicates that the SWIM Maximum has been exceeded and the Service Provider’s SWIM indicator was changed from ON to OFF as of the time in the stop-date timestamp. The stop-date (timestamp), also indicates the time of the last SWIM entry onto the SWIM list. In this situation the Service Provider should perform further, ‘time-based’ recovery based upon the stop-date timestamp in order to recover all potentially missed messages for each data type they support. The Service Provider system may complete SWIM recovery for each data type and then request further time-based recovery for each data type:  For example:  SWIM (SP Data) – SWIM (Network Data) — SWIM (Subscription Data) –   SWIM (NPB Data) – SWIM (Notification Data)  – time-based (SP Data) – time-based (Network Data) – time-base (Subscription Data) – time-base (NPB Data) – time-based (Notification Data)  OR upon performing SWIM recovery and receiving the stop-date timestamp they may immediately perform time-based recovery for that same data type then SWIM based recovery for the next data type followed by time-based recovery for the same data type:  For example:  SWIM (SP Data) – time-based (SP Data) – SWIM (Network Data)  - time-based (Network Data)  etc.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      57                   Secure Association Establishment    Service Providers can continue to use the existing recovery mechanism/messages to recover data between the SOA/LSMS and the NPAC, using the ‘time-based’ or ‘record-based’ methods. However, if the Service Provider supports SWIM recovery, it is important that they first recover using the SWIM criteria. When the Service Provider supports SWIM recovery, their SWIM list is not “cleared” until successful SWIM recovery occurs, thus recovering by either time-based or record-based criterion first and SWIM subsequently may cause data integrity issues.  Upon completion of recovery, the SOA/LSMS should issue an lnpRecoveryComplete message indicating the end of the missed data, and processing between the SOA/LSMS and NPAC SMS will resume normal mode.     5.3.4.1   Local SMS Recovery    To recover, the Local SMS starts by setting the recoveryMode flag of the access control parameter. This flag signals the NPAC SMS to hold all data updates to this Local SMS. The Local SMS should then request the service provider, network, subscription and number pool block data downloads and the notifications that occurred during downtime. Once this is complete, the Local SMS should issue the lnpRecoveryComplete action to turn off the recoveryMode flag. After the NPAC SMS responds to the lnpRecovery Complete action it will send to the LSMS any other messages that have occurred since the association was established.     5.3.4.2   SOA Recovery    To recover, the SOA starts by setting the recoveryMode flag of the access control parameter. This flag signals the NPAC SMS to hold all data updates to this SOA. The SOA should then request the service provider, network data downloads and notifications that occurred during downtime. Once this is complete, the SOA should issue the lnpRecoveryComplete action to turn off the recoveryMode flag. After the NPAC SMS responds to the lnpRecovery Complete action it will send to the SOA any other messages that have occurred since the association was established.     5.3.4.3   Linked Action Replies during Recovery    Linked Reply functionality applies to Service Providers that have their SOA Linked Replies Indicator set to TRUE, or their Local SMS Linked Replies Indicator set to TRUE.  For service provider that support linked replies the Maximum TN Download in Recovery Request, the Maximum Number of Download Notifications and Maximum Number of Download Records tunables do not apply to recovery processing.  Linked replies will be returned as the response to an lnpDownload action request for network data if the number of messages returned exceeds the “Network Data Linked Reply Blocking Factor” tunable but is less than the “Network Data Maximum Linked Recovered Objects” tunable. If the number of network data objects to be returned exceeds the “Network Data Maximum Linked Recovered Objects” tunable, a “criteria-too-large” error will be returned to the requesting SOA/LSMS.  Linked replies will be returned as the response to an lnpDownload action request for subscription data if the number of objects returned exceeds the “Subscription                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      58                   Secure Association Establishment    Data Linked Reply Blocking Factor” tunable but is less than the “Subscription Data Maximum Linked Recovered Objects” tunable. If the number of subscription data objects be returned exceeds the “Subscription Data Maximum Linked Recovered Objects” tunable, a “criteria-too-large” error will be returned to the requesting LSMS.  Linked replies will be returned as the response to an lnpDownload action request for Number Pool Block data if the number of objects returned exceeds the “Number Pool Block Data Linked Reply Blocking Factor” tunable but is less than the “ Number Pool Block Data Maximum Linked Recovered Objects” tunable. If the number of Number Pool Block data objects be returned exceeds the “ Number Pool Block Data Maximum Linked Recovered Objects” tunable, a “criteria-too-large” error will be returned to the requesting LSMS.  Linked replies will be returned as the response to an lnpNotificationRecovery action request for notification data if the number of notifications returned exceeds the “Notification Data Linked Reply Blocking Factor” tunable but is less than the “Notification Data Maximum Linked Recovered Notifications” tunable. If the number of notifications to be returned exceeds the “Notification Data Maximum Linked Recovered Notifications” tunable, a “criteria-too-large” error will be returned to the requesting SOA/LSMS.  As an example, a Service Provider’s SOA was down, and is now performing notification recovery. During the downtime, 90 notifications were issued. Assuming the Notification Blocking Factor is set to 50 notifications, the recovering SOA would receive data from the NPAC SMS in the form of three linked replies. The first reply would contain 50 notifications, the second reply would contain 40 notifications, and the third reply would be empty (this is an indication that the NPAC SMS is finished sending data for this recovery request). In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor, the M-ACTION response will be a normal response (i.e., non-linked response) and will not be a linked reply.  Below are the tunables that specify the download size:              Download Criteria   Tunable Name     Network data download request maximum linked reply size    Network Data Linked Replies Blocking Factor           Subscription download request maximum linked reply size    Subscription Data Linked Replies Blocking Factor           Number Pool Block download request maximum linked reply size    Number Pool Block Data Linked Replies Blocking Factor           Notification download request maximum linked reply size    Notification Data Linked Replies Blocking Factor           Total number of network data objects returned for a single download request    Network Data Maximum Linked Recovered Objects           Total number of subscription data objects returned for a single download request    Subscription Data Maximum Linked Recovered Objects           Total number of Number Pool Block data objects returned for a single download request    Number Pool Block Data Maximum Linked Recovered Objects           Total number of notification data notifications returned for a single download request    Notification Data Maximum Linked Recovered Objects     Linked replies will be returned as the response to an action request from the recovering SOA/LSMS. The entire operation is considered complete once all                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      59                    Secure Association Establishment    linked replies and the final empty reply are returned as the response to the original request. Timeout processing is expected to start when the initial request is sent by the recovering SOA/LSMS, and terminate upon receipt of the final empty reply by the recovering SOA/LSMS.  5.4 Congestion Handling  The following sections define NPAC SMS behavior when in congestion and the NPAC handling of Local SMS and SOA congestion. The recommendation for Congestion Control follows the “Flow Control” mechanism and is described in OSI Communication Reference Model (ISO/IEC 7498). The two types of flow control defined are:       1.   Peer Flow Control        2.   Inter-Layer Flow Control    Peer Flow Control can be used when two peer layers of the OSI Stack talk to each other. The most common form of Peer Flow Control is the sliding window protocol. This protocol is implemented by TCP. This is the flow control approach used by the NPAC SMS.     5.4.1   NPAC SMS Congestion    Once the number of incoming messages to be queued to the NPAC SMS is exceeded at the transport layer, TCP/IP, an indication will be sent to the sender from the transport layer, TCP/IP, that congestion is occurring. Upon clearing of the congestion situation, the transport layer, TCP/IP will indicate to the sender that congestion has been cleared. As the receiver, the NPAC SMS application will not be aware that it is congested. The NPAC SMS application will be continually processing the information being sent as quickly as possible. Only the sender will be aware that the NPAC SMS is congested due to the fact that it can not send any more information to the NPAC SMS via the transport layer, TCP/IP. Implementation of functionality to handle NPAC congestion situations is at the discretion of SOA and LSMS vendors.     5.4.2   NPAC Handling of Local SMS and SOA Congestion    The NPAC SMS application must be able to handle congestion when attempting to send out a message to a SOA or LSMS system. When receiving indications of congestion via the transport layer from a SOA or LSMS the NPAC SMS application stops dispatching messages for the SPID (primary or associated) and SOA or LSMS interface that returned congestion. Note: If a SOA system returns congestion it will not affect the LSMS for the same service provider and vise versa. When the NPAC SMS stops dispatching messages to a congested SOA or LSMS, the retry attempts and retry timer values and the behavior associated with them apply to the messages not dispatched. The NPAC will abort the SOA or LSMS association once the retry attempts are exhausted. Any unacknowledged messages at the NPAC SMS application layer will be handled as failures as they are when an association is aborted today, for example for security reasons.  Once the NPAC SMS gets an indication via the transport layer that a SOA or LSMS system that was previously congested is ready to receive information, the NPAC SMS resumes sending of messages to that system. Note that the NPAC SMS will use the sequence number for the message it sends first that was the sequence number on the message that was sent when congestion indication was received. This is done since the SOA or LSMS system did not receive this message. If the sequence number were incremented this would cause the SOA or LSMS to abort the association due to the sequence number value being larger than expected. SOA and LSMSs should use                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      60                   Secure Association Establishment    the same sequence number as well when communicating with the NPAC to prevent the NPAC from aborting the association due to the sequence number value being larger than expected.     5.4.3   Out-Bound Flow Control    Under normal conditions the NPAC SMS sends messages to the associated SOA/LSMS and the SOA/LSMS is able to keep up with the NPAC, and Flow Control is not encountered. However, under load conditions, the SOA/LSMS is not able to keep up with the messages sent from the NPAC SMS and Flow Control may be encountered.  For a SOA/LSMS that is currently in a normal state (not in Flow Control), the NPAC SMS monitors the number of outstanding, non-responsive messages sent to that system. If the number of outstanding, non-responsive messages is less than the Flow Control Upper Threshold (tunable value), NPAC sends the current message it is handling, and continues with normal processing. If the number of outstanding, non-responsive messages is equal to the Flow Control Upper Threshold tunable, the NPAC sends the current message it is handling, and sets the Flow Control flag to TRUE. In this situation Flow Control is encountered.  During Flow Control the NPAC SMS verifies the Flow Control flag setting for the destination SOA/LSMS to determine if it’s OK to send each message. If the flag is FALSE, the message is sent; if the flag is TRUE the message is held/queued. In a Flow Control state, the NPAC SMS monitors the number of outstanding, non-responsive messages sent to that SOA/LSMS. If the number of outstanding, non-responsive messages is greater than the Flow Control Lower Threshold, no action is taken. When the number of outstanding, non-responsive messages is less than or equal to the Flow Control Lower Threshold (tunable value), the NPAC SMS resumes sending messages (whether queued or normal). A SOA/LSMS that is in a Flow Control state will have outstanding, non-responsive messages. For all outstanding, non-responsive messages that were sent, NPAC response timers and abort behavior will apply. For all messages NOT sent but held because the Flow Control flag is set to TRUE, NPAC response timers and abort behavior will NOT apply.  Flow Control is implemented on the NPAC SMS side of the CMIP interface and it is optionally implemented on the SOA/LSMS. The implementation of Flow Control by the sending system is independent of any implementation of Flow Control by the receiving system and is applicable on a per association basis. Flow Control applies to both normal mode and recovery mode and is applicable for service provider, network, number pool block, subscription version and notification data.     5.5   Abort Processing Behavior    The NPAC exchanges messages with the SOA/LSMS. For every request from the NPAC, a response is required from the SOA/LSMS. A SOA/LSMS that fails to respond to a message is subject to Abort Processing Behavior (APB).  The NPAC sends messages to the associated SOA/LSMS. For every message sent, abort behavior is initiated, and a Roll-Up Activity (RAT) timer is started. The initial abort timer is based on existing retry functionality. The RAT timer is either the Roll-Up Activity-Single (RAT Single) tunable value or the Rollup Activity Timer Expire SVRange (RAT Range) tunable value. The secondary abort timer is the Abort Processing Behavior Upper Threshold tunable window. The NPAC allows a SOA/LSMS to fall behind in processing messages. However, the limit is defined by the Abort Processing Behavior Upper Threshold tunable window, upon which when this value is reached the association is aborted.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      61                   Secure Association Establishment    The NPAC SMS “rolls-up” downloaded data (e.g. SV activate to LSMSs) to reflect the status of porting activity. Abort behavior and roll-up behavior are separate items, but often confused because both can happen at the same time when a timer expires.  During message exchange between the NPAC SMS and the SOA/LSMS the response from the SOA/LSMS is one or more of the options below, based on the tunable settings:       •   All SOAs/LSMSs respond to the NPAC SMS message before the end of the retry window and RAT timer expiration.         o   In this instance the NPAC SMS expires the RAT timer for that event and with a successful response, the NPAC SMS considers the responding SOA/LSMS as “successful” to the request (e.g. the SPID is not placed on the Failed-SP List).         •   All SOAs/LSMSs do NOT respond to the NPAC SMS before the end of the retry window (e.g. end of the “X by Y” window).         o   The retry timer has expired based on the applicable retry value. The NPAC SMS determines if any messages/responses were received from this SOA/LSMS during the retry window.         §   If at least one message/response is received from the SOA/LSMS, processing continues.         •   All SOAs/LSMSs do NOT respond to the NPAC SMS before the end of the RAT timer expiration. The RAT timer has expired based on the applicable value (either single or range).         o   The NPAC SMS performs “roll-up” activities for all messages sent to the SOAs/LSMSs on this event (status is set, Failed-SP List(s) is updated appropriately and notifications are sent to respective SOAs).         •   SOA/LSMS responds to the NPAC SMS AFTER the expiration of the RAT timer.         o   The NPAC SMS updates status/Failed-SP List, and sends notifications to respective SOAs.         •   SOA/LSMS does NOT respond to the NPAC SMS before the end of the secondary abort (Abort Processing Behavior Upper Threshold tunable) window.         o   The NPAC SMS aborts the association to the SOA/LSMS and the SOA/LSMS must re-associated to the NPAC SMS.        o   The SOA/LSMS goes through recovery processing (recovery based on SOA/LSMS linked replies indicator) and the NPAC SMS updates the status/Failed-SP List, and sends notifications to the SOAs.    Abort processing behavior applies to both normal and recovery modes. Service provider, network, number pool block, subscription version and notification messages are subject to Abort processing behavior.     5.6   Single Association for SOA/LSMS    A SOA/LSMS system may connect to the NPAC SMS with one association for the same function (same bit mask). The NPAC SMS will abort any previous associations that use that same function.     5.7   Separate SOA Channel for Notifications    A SOA system may connect to the NPAC SMS with multiple SOA channels (i.e., associations) for different functions (different bit masks), specifically request/response                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      62                   Secure Association Establishment    data versus notification data. The NPAC SMS will distribute transactions across these SOA associations based on functionality (different bit masks). This allows for additional throughput for the SOA as a result of two associations.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      63                   GDMO Definitions    6 GDMO Definitions  [Graphic Omitted: 6]  The latest version of the GDMO interface definitions (lnp.mo_v_3_3_1_2005_10_13.txt) is available on the NPAC website (www.npac.com, under the documents section).  The current interface messaging can use one of the following two sets of message files found on the NPAC website:  1. The v_3_3_1, 10/13/05 ASN.1, 10/13/05 GDMO, and NANC-399-XML.txt.  2. The v_3_3_0, 5/27/05 ASN.1, and 5/27/05 GDMO.  Either set is valid when interfacing with the NPAC. The 10/13/05 version contains minor behavior comment changes, as well NANC 399 SVType and OptionalData fields. However, NANC 399 fields are currently inactive in each NPAC Region.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      64                   General ASN.1 Definitions    7 General ASN.1 Definitions  [Graphic Omitted: 7]  The latest version of the LNP ASN.1 Object Identifier definitions (lnp.asn_v_3_3_1_2005_10_13.txt) is available on the NPAC website (www.npac.com, under the documents section).  The current interface messaging can use one of the following two sets of message files found on the NPAC website:  1. The v_3_3_1, 10/13/05 ASN.1, 10/13/05 GDMO, and NANC-399-XML.txt.  2. The v_3_3_0, 5/27/05 ASN.1, and 5/27/05 GDMO.  Either set is valid when interfacing with the NPAC. The 10/13/05 version contains minor behavior comment changes, as well NANC 399 SVType and OptionalData fields. However, NANC 399 fields are currently inactive in each NPAC Region.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      65                   LNP XML Schema    8 LNP XML Schema  [Graphic Omitted: 8]  The latest version of the LNP XML schema (NANC-399-XML.txt) is available on the NPAC website (www.npac.com, under the documents section).  The current interface messaging can use one of the following two sets of message files found on the NPAC website:  1. The v_3_3_1, 10/13/05 ASN.1, 10/13/05 GDMO, and NANC-399-XML.txt.  2. The v_3_3_0, 5/27/05 ASN.1, and 5/27/05 GDMO.  Either set is valid when interfacing with the NPAC. The 10/13/05 version contains minor behavior comment changes, as the well NANC399 SV Type and OptionalData fields. However, NANC 399 fields are currently inactive in each NPAC Region                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      66                   Subscription Version Status    9 Subscription Version Status  [Graphic Omitted: 9]  [Graphic Omitted: Version Creation – Version Death]                      Subscription Version Status Interaction Descriptions   #   Interaction Name   Type   Description         1    Conflict to Canceled    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version in conflict directly to canceled after it has been in conflict for a tunable number of calendar days.                            SOA to NPAC SMS Interface or NPAC Operations Interface — NPAC Personnel    The old Service Provider User (or NPAC personnel acting on behalf of the Service Provider) sends a cancellation request for a Subscription Version created by that Service Provider with a status of conflict that has not been concurred by the other new Service Provider.                   2    Conflict to Cancel Pending    NPAC Operations Interface — NPAC Personnel    User cancels a Subscription Version in conflict or cancels a Subscription Version that was created by or concurred to by both Service Providers.                            SOA to NPAC SMS Interface    User sends a cancellation request for a Subscription Version that was created by or concurred to by both Service Providers.                   3    Cancel Pending to Conflict    NPAC Operations Interface — NPAC Personnel    User sets a Subscription Version with a status of cancel pending to conflict.                            NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version with a status of cancel pending to conflict if cancel pending acknowledgment has not been received from the new Service Provider within a tunable timeframe.                   4    Conflict to Pending    NPAC Operations Interface — NPAC Personnel and SOA to NPAC SMS Interface — Old Service Provider    User removes a Subscription Version from conflict.                            SOA to NPAC SMS Interface — New Service Provider    New Service Provider User removes a Subscription Version from conflict. This action can only occur if a tunable number of hours have elapsed since the Subscription Version was placed in conflict.                   5    Pending to Conflict    NPAC Operations Interface — NPAC Personnel    1.    User sets a Subscription Version with a status of pending to conflict.                2.    User creates a Subscription Version for an existing pending Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      67                   Subscription Version Status                        Subscription Version Status Interaction Descriptions   #   Interaction Name   Type   Description                  SOA to NPAC SMS Interface — Old Service Provider    Old Service Provider sends a Subscription Version creation or modification request for a Subscription Version with a status of pending, which revokes the old Service Provider’s authorization for transfer of service. This action can only be taken once, and must be taken a tunable number of hours prior to the new Service Provider due date.                   6    Pending to Canceled    NPAC Operations Interface — NPAC Personnel    User cancels a Subscription Version with a status of pending that has not been concurred by both service providers.                            SOA to NPAC SMS Interface    Service Provider User sends a cancellation request for a Subscription Version created by that Service Provider with a status of pending that has not been concurred by the other Service Provider.                            NPAC SMS Internal    1.    NPAC SMS automatically sets a pending Subscription Version to canceled after authorization for the transfer of service has not been received from the new Service Provider within a tunable timeframe.                2.    NPAC SMS automatically sets a pending Subscription Version to canceled if an activation request is not received a tunable amount of time after new Service Provider due date.                   7    Pending to Cancel Pending    NPAC Operations Interface — NPAC Personnel    User cancels a Subscription Version with a status of pending that has been created/concurred by both Service Providers.                            SOA to NPAC SMS Interface    Service Provider User sends a cancellation request for a Subscription Version with a status of pending that has been concurred by the other Service Provider.                   8    Cancel Pending to Canceled    NPAC SMS Internal    NPAC SMS automatically sets a cancel pending Subscription Version to canceled after receiving cancel pending acknowledgment from the concurring Service Provider, or the final cancellation concurrence window has expired without cancel concurrence from the old Service Provider.                   9    Creation - Set to Conflict    NPAC Operations Interface — NPAC Personnel    User creates a Subscription Version for the old Service Provider and does not provide authorization for the transfer of service.                            SOA to NPAC SMS Interface — Old Service Provider    User sends an old Service Provider Subscription Version creation request and does not provide authorization for the transfer of service.                   10    Creation - Set to Pending    NPAC Operations Interface — NPAC Personnel    User creates a Subscription Version for either the new or old Service Provider. If the create is for the old Service Provider and authorization for the transfer of service is not provided, refer to # 9, Creation — Set to Conflict, NPAC Operations Interface.                            SOA to NPAC SMS Interface    User sends a Subscription Version creation request for either the new or old Service Provider. If the create is for the old Service Provider, and authorization for the transfer of service is not provided, refer to # 9, Creation — Set to Conflict, SOA to NPAC SMS Interface.                   11    Disconnect Pending to Sending    NPAC SMS Internal    NPAC SMS automatically sets a deferred disconnect pending Subscription Version to sending after the effective release date is reached.                   12    Cancel Pending to Pending    SOA to NPAC SMS Interface or NPAC SOA Low-tech Interface    Service Provider User sends an un-do cancel-pending request for a Subscription Version with a status of cancel-pending for which the same Service Provider previously issued a cancel request.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      68                   Subscription Version Status                        Subscription Version Status Interaction Descriptions   #   Interaction Name   Type   Description         13    Pending to Sending    NPAC Operations Interface — NPAC Personnel    User activates a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.                            SOA to NPAC SMS Interface — New Service Provider    New Service Provider User sends an activation message for a pending Subscription Version for a Subscription Version with a new Service Provider due date less than or equal to today.                   14    Sending to Failed    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from sending to failed after all Local SMSs fail Subscription Version activation after the tunable retry period expires.                   15    Failed to Sending    NPAC Operations Interface — NPAC Personnel    User re-sends a failed Subscription Version.                   16    Partially Failed to Sending    NPAC Operations Interface — NPAC Personnel    User re-sends a partial failure Subscription Version.                   17    Sending to Partially Failed    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from sending to partial failure after one or more, but not all, of the Local SMSs fail the Subscription Version activation after the tunable retry period expires.                   18    Sending to Old    NPAC SMS Internal    NPAC SMS automatically sets a sending Subscription Version to old after a disconnect or “porting to original” port to all Local SMSs successfully completes. Disconnects that fail on one or more, but not all, Local SMSs will also be set to old.                   19    Sending to Active    NPAC SMS Internal    1.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version activation is successful in all of the Local SMSs.                2.    NPAC SMS automatically sets a sending Subscription Version to active after the Subscription Version modification is successfully broadcast to any of the Local SMSs after all have responded.                3.    NPAC SMS automatically sets a sending Subscription Version to active after a failure to all Local SMSs on a disconnect.                   20    Active to Sending    NPAC Operations Interface — NPAC Personnel    User disconnects an active Subscription Version and does not supply an effective release date, or User modifies an active Subscription Version or resends a failed disconnect or modify.                            SOA to NPAC SMS Interface — Current Service Provider    User sends a disconnect request for an active Subscription Version and does not supply an effective release date, or User modifies an active Subscription Version.                   21    Active to Old    NPAC SMS Internal    NPAC SMS automatically sets the currently active Subscription Version to old once a currently active subscription version is superceded by a pending subscription version, due to the fact that the current version is set to old when an activate occurs. The new pending version is set to sending and then to active, partially failed, or old. On a disconnect the sending state occurs before the old.                   22    Disconnect Pending to Active    NPAC Operations Interface — NPAC Personnel    User cancels a Subscription Version with a disconnect pending status.                            SOA to NPAC SMS Interface — New Service Provider    User sends a cancellation request for a disconnect pending Subscription Version.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      69                   Subscription Version Status                        Subscription Version Status Interaction Descriptions   #   Interaction Name   Type   Description         23    Active to Disconnect Pending    NPAC Operations Interface — NPAC Personnel    User disconnects an active Subscription Version and supplies a future effective release date.                            SOA to NPAC SMS Interface — Current Service Provider    User sends a disconnect request for an active Subscription Version and supplies a future effective release date.                   24    Old to Sending    NPA Operations Interface – NPAC Personnel    User re-sends a partial failure of a disconnect or partial failure or failure of a port-to-original Subscription Version.                   25    Old to Old    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from old to old after one or more previously failed Local SMSs successfully disconnect a Subscription Version, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   26    Partially Failed to Active    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from partial failure to active after all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   27    Partially Failed to Partially Failed    NPAC SMS Internal    NPAC SMS automatically sets a Subscription Version from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Subscription Version, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      70                   Number Pool Block Status    10 Number Pool Block Status  [Graphic Omitted: 10]  [Graphic Omitted: Number Pool Block Flow]  In the following table, the reference to “Number Pool Block” data when broadcasting to an LSMS is based on that Service Provider’s EDR Indicator (i.e., Number Pool Block object or Subscription Versions with LNP Type of POOL).                      Number Pool Block Version Status Interaction Descriptions   #   Interaction Name   Type   Description         1    Creation - Set to Sending    NPAC SMS Internal    NPAC SMS creates a Number Pool Block for the Block Holder Service Provider.                            NPAC Operations Interface — NPAC Personnel    User sends a Number Pool Block creation request for the Block Holder Service Provider.                            SOA to NPAC SMS Interface — Block Holder Service Provider    The Service Provider User sends a Number Pool Block creation request for itself (the Block Holder Service Provider).                   2    Sending to Partial Failure    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from sending to partial failure after one or more, but not all, of the Local SMSs fail the Number Pool Block activation after the tunable retry period expires.                   3    Partial Failure to Sending    NPAC Operations Interface — NPAC Personnel    User re-sends a partial failure Number Pool Block.                   4    Sending to Failed    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from sending to failed after all Local SMSs fail Number Pool Block activation after the tunable retry period expires.                   5    Failed to Sending    NPAC Operations Interface — NPAC Personnel    User re-sends a failed Number Pool Block.                   6    Sending to Active    NPAC SMS Internal    1. NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block activation is successful in all of the Local SMSs.                2. NPAC SMS automatically sets a sending Number Pool Block to active after the Number Pool Block modification is broadcast to all of the Local SMSs and either all have responded or retries have been exhausted.                3. NPAC SMS automatically sets a sending Number Pool Block to active after a failure to all Local SMSs on a de-pool.                   7    Active to Sending    NPAC Operations Interface — NPAC Personnel    1. User de-pools an active Number Pool Block. 2. User modifies an active Number Pool Block.                3. User resends a failed de-pool or modify Number Pool Block.                            SOA to NPAC SMS Interface — Block Holder Service Provider    User modifies an active Number Pool Block.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      71                   Number Pool Block Status                        Number Pool Block Version Status Interaction Descriptions   #   Interaction Name   Type   Description         8    Sending to Old    NPAC SMS Internal    1. NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool to all Local SMSs successfully completes.                2. NPAC SMS automatically sets a sending Number Pool Block to old after a de-pool that fails on one or more, but not all Local SMSs.                   9    Old to Sending    NPA Operations Interface – NPAC Personnel    User re-sends a partial failure of a de-pool.                   10    Partial Failure to Partial Failure    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from partial failure to partial failure after one or more, but not all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   11    Partial Failure to Active    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from partial failure to active after all previously failed Local SMSs successfully activate a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                   12    Old to Old    NPAC SMS Internal    NPAC SMS automatically sets a Number Pool Block from old to old after one or more previously failed Local SMSs successfully de-pools a Number Pool Block, as a result of an audit or LSMS recovery. The Failed_SP_List is updated to reflect the updates to the previously failed SPs.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3: © 1997  — 2006 NeuStar, Inc.      72                      NPAC SMS INTEROPERABLE INTERFACE SPECIFICATION  APPENDICES A AND B  NANC Version 3.3.2a  Prepared for: The North American Numbering Council (NANC)   March 9, 2006     Release 3.3: © 1997 — 2006 NeuStar, Inc.  The Work is subject to the terms of the GNU General Public License (the “GPL”), a copy of which may be found at ftp://prep.ai.mit.edu/pub/gnu/GPL. Any use of this Work is subject to the terms of the GPL. The “Work” covered by the GPL by operation of this notice and license is this document and any and all modifications to or derivatives of this document. Where the words “Program,” “software,” “source code,” “code,” or “files” are used in the GPL, users understand and agree that the “Work” as defined here is substituted for purposes of this notice and license.                         March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.                     Table Of Contents    Table Of Contents                    Introduction     1                 A.1 CMISE Primitive Errors     2                 A.2 CMISE Primitive Error Descriptions     2                 A.3 CMIP Error Mapping to NPAC SMS Errors     4                 B.1 Overview     23                 B.2 Audit Scenarios     24     B.2.1 SOA Initiated Audit     24     B.2.1.1 SOA Initiated Audit (continued)     25     B.2.2 SOA Initiated Audit Cancellation by the SOA     26     B.2.3 SOA Initiated Audit Cancellation by the NPAC     27     B.2.4 NPAC Initiated Audit     28     B.2.5 NPAC Initiated Audit Cancellation by the NPAC     30     B.2.6 Audit Query on the NPAC     31     B.2.7 SOA Audit Create for Subscription Versions within a Number Pool Block (previously NNP flow 6.1)     32     B.2.7.1 SOA Creates and NPAC SMS Starts Audit (previously NNP flow 6.1.1)     32     B.2.7.2 NPAC SMS Performs Audit Comparisons for a SOA initiated Audit including a Number Pool Block (previously NNP flow 6.1.2)     34     B.2.7.3 NPAC SMS Reports Audit Results (previously NNP flow 6.1.3)     35     B.2.8 NPAC SMS Audit Create for Subscription Versions Within a Number Pool Block (previously NNP flow 6.2)     36     B.2.8.1 NPAC SMS Creates and Starts Audit (previously NNP flow 6.2.1)     36     B.2.8.2 NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block (previously NNP flow 6.2.2)     37                 B.3 Service Provider Scenarios     38     B.3.1 Service Provider Creation by the NPAC     38     B.3.2 Service Provider Deletion by the NPAC     39     B.3.3 Service Provider Modification by the NPAC     40     B.3.4 Service Provider Modification by the Local SMS     41     B.3.5 Service Provider Modification by the SOA     42     B.3.6 Service Provider Query by the Local SMS     43     B.3.7 Service Provider Query by the SOA     44                 B.4 Service Provider Network Data Scenarios     45     B.4.1 NPA-NXX Scenarios     45     B.4.1.1 NPA-NXX Creation by the NPAC     45     B.4.1.2 NPA-NXX Deletion by the NPAC     46     B.4.1.3 NPA-NXX Creation by the Local SMS     47     B.4.1.4 NPA-NXX Creation by the SOA     48     B.4.1.5 NPA-NXX Deletion by the Local SMS     49     B.4.1.6 NPA-NXX Deletion by SOA     50     B.4.1.7 NPA-NXX Query by the Local SMS     51     B.4.1.8 NPA-NXX Query by the SOA     52     B.4.2 LRN Scenarios     53     B.4.2.1 LRN Creation by the NPAC     53     B.4.2.2 LRN Creation by the SOA     54     B.4.2.3 LRN Deletion by the SOA     55                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.    i                 Table Of Contents                      B.4.2.4 LRN Query by the SOA     56     B.4.2.5 LRN Deletion by the NPAC     57     B.4.2.6 LRN Creation by the Local SMS     58     B.4.2.7 LRN Deletion by the Local SMS     59     B.4.2.8 LRN Query by the Local SMS     60     B.4.2.9 Network Data Download     61     B.4.2.10 Scoped/Filtered GET of Network Data     62     B.4.2.11 Scoped/Filtered GET of Network Data from SOA     63     B.4.3 Service Provider NPA-NXX-X     64     B.4.3.1 Service Provider NPA-NXX-X Create by NPAC SMS (previously NNP flow 1.1)     64     B.4.3.1.1 Service Provider NPA-NXX-X Create by NPAC SMS (continued)     66     B.4.3.2 Service Provider NPA-NXX-X Modification by NPAC SMS (previously NNP flow 1.2)     67     B.4.3.3 Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence (previously NNP flow 1.3)     68     B.4.3.4 Service Provider NPA NXX X Query by SOA or LSMS (previously NNP flow 1.4)     69     B.4.4 Number Pool Block     70     B.4.4.1 Number Pool Block Create/Activate by SOA (previously NNP flow 2.1)     70     B.4.4.2 Number Pool Block Create by NPAC SMS (previously NNP flow 2.2)     73     B.4.4.3 Number Pool Block Create Broadcast Successful to Local SMS (previously NNP flow 2.3.1)     75     B.4.4.4 Number Pool Block Create: Successful Broadcast (previously NNP flow 2.3.2)     76     B.4.4.5 Number Pool Block Create Broadcast to Local SMS: Failure (previously NNP flow 2.4)     77     B.4.4.6 Number Pool Block Create Broadcast to Local SMS: Partial Failure (previously NNP flow 2.5.1)     78     B.4.4.7 Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates (previously NNP flow 2.5.2)     79     B.4.4.8 Number Pool Block Create Resend Broadcast (previously NNP flow 2.6)     80     B.4.4.9 Number Pool Block Create Successful Resend Updates (previously NNP flow 2.7)     81     B.4.4.10 Number Pool Block Create Failed Resend NPAC SMS Updates (previously NNP flow 2.8)     82     B.4.4.11 Number Pool Block Create Partial Failure Resend NPAC SMS Updates (previously NNP flow 2.9)     83     B.4.4.12 Number Pool Block Modify by NPAC SMS (previously NNP flow 2.10)     84     B.4.4.13 Number Pool Block Modify by Block Holder SOA (previously NNP flow 2.11)     86     B.4.4.14 Number Pool Block Modify Successful Broadcast to Local SMS Success (previously NNP flow 2.12.1)     88     B.4.4.15 Number Pool Block Modify Successful Broadcast NPAC SMS Updates (previously NNP flow 2.12.2)     89     B.4.4.16 Number Pool Block Modify Broadcast to Local SMS Failure (previously NNP flow 2.13)     90     B.4.4.17 Number Pool Block Modify Partial Failure Broadcast to Local SMS (previously NNP flow 2.14.1)     91     B.4.4.18 Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.14.2)     92     B.4.4.19 Number Pool Block Modify Resend Broadcast (previously NNP flow 2.15)     93     B.4.4.20 Number Pool Block Modify Successful Resend Updates (previously NNP flow 2.16)     94     B.4.4.21 Number Pool Block Modify Failure Resend Updates (previously NNP flow 2.17)     95     B.4.4.22 Number Pool Block Modification of SOA Origination Indicator (previously NNP flow 2.18)     96     B.4.4.23 Number Pool Block De Pool by NPAC SMS (previously NNP flow 2.19)     97     B.4.4.24 Number Pool Block De Pool Successful Broadcast of Subscription Version and Number Pool Block Deletes (previously NNP flow 2.20.1)     98     B.4.4.25 Number Pool Block De Pool Broadcast Successful NPA-NXX-X Updates (previously NNP flow 2.20.2)     99     B.4.4.26 Number Pool Block De Pool Broadcast to Local SMS Failure (previously NNP flow 2.21)     100     B.4.4.27 Number Pool Block De Pool Partial Failure Broadcast to Local SMS of Subscription Versions and Number Pool Block (previously NNP flow 2.22.1)     101     B.4.4.28 Number Pool Block De Pool Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.22.2)     102     B.4.4.29 Number Pool Block De Pool Resend Broadcast (previously NNP flow 2.23)     103     B.4.4.30 Number Pool Block De Pool Successful Resend Updates (previously NNP flow 2.24)     104                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.    ii                 Table Of Contents                      B.4.4.31 Number Pool Block De Pool Resend Failure Updates (previously NNP flow 2.25)     105     B.4.4.32 Number Pool Block De Pool Resend Partial Failure Updates (previously NNP flow 2.26)     106     B.4.4.33 Number Pool Block Query by SOA or LSMS (previously NNP flow 2.27)     107                 B.5 SubscriptionVersion Flow Scenarios     108     B.5.1 SubscriptionVersion Create Scenarios     108     B.5.1.1 Subscription Version Create by the Initial SOA (Old Service Provider)     109     B.5.1.1.1 Subscription Version Create by the Initial SOA (Old Service Provider) (continued)     111     B.5.1.2 SubscriptionVersion Create by the Initial SOA (New Service Provider)     112     B.5.1.2.1 Subscription Version Create by the Initial SOA (New Service Provider) (continued)     114     B.5.1.3 SubscriptionVersion Create by Second SOA (New Service Provider)     115     B.5.1.4 SubscriptionVersion Create by Second SOA (Old Service Provider) with Authorization to Port     117     B.5.1.5 SubscriptionVersion Activated by New Service Provider SOA     119     B.5.1.6 Active SubscriptionVersion Create on Local SMS     120     B.5.1.6.1 Active Subscription Version Create on Local SMS Using Create Action     121     B.5.1.6.2 SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window     122     B.5.1.6.3 SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window     123     B.5.1.6.4 Subscription Version Create: Failure to Receive Response from New SOA     124     B.5.1.6.5 SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window     125     B.5.1.7 SubscriptionVersionCreate M CREATE Failure to Local SMS     127     B.5.1.8 SubscriptionVersion M CREATE: Partial Failure to Local SMS     128     B.5.1.9 Create Subscription Version: Resend Successful to Local SMS Action     129     B.5.1.10 Subscription Version: Resend Failure to Local SMS     130     B.5.1.11 SubscriptionVersion Create for Intra Service Provider Port     131     B.5.1.12 SubscriptionVersion for Inter and Intra Service Provider Port-to-Original: Successful     134     B.5.1.12.1 Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)     135     B.5.1.12.2 Intra-Service Provider Subscription Version Port-to-Original: Successful (continued)     136     B.5.1.13 SubscriptionVersion for Inter and Intra Service Provider Port-to-Original: All LSMSs Fail    137     B.5.1.13.1 Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)     138     B.5.1.13.2 Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)     139     B.5.1.14 SubscriptionVersion for Inter and Intra Service Provider Port-to-Original: Partial Failure     140     B.5.1.14.1 Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)     141     B.5.1.14.2 Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)     142     B.5.1.15 SubscriptionVersion Port-to-Original: Resend     143     B.5.1.15.1 Subscription Version Port-to-Original: Resend (continued)     144     B.5.1.16 SubscriptionVersion Port-to-Original: Resend Failure to Local SMS     145     B.5.1.16.1 SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)     146     B.5.1.17 Port-to-Original Subscription Version Flows for Pooled TNs     147     B.5.1.17.1 Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA (previously NNP flow 3.1.1)     147     B.5.1.17.2 Successful Broadcast of Port-to-Original Activation Request for a Pooled TN (previously NNP flow 3.1.2)     149     B.5.1.17.3 Successful Broadcast Complete NPAC SMS Updates for a Port-to-Original Request for a Pooled TN (previously NNP flow 3.1.3)     150     B.5.1.17.4 Subscription Version Create Port-to-Original of a Pool TN: Failure Broadcast to All Local SMSs (previously NNP flow 3.2.1)     151     B.5.1.17.5 Updates to NPAC SMS after Failure of Port-to-Original Broadcast for a Pooled TN (previously NNP flow 3.2.2)     152     B.5.1.17.6 Port-to-Original Activation Partial Failure Broadcast of a Pooled TN (previously NNP flow 3.3.1)     153     B.5.1.17.7 Partial Failure Broadcast Complete NPAC SMS Updates of a Port-to-Original for a Pooled TN (previously NNP flow 3.3.2)     154                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.    iii                 Table Of Contents                      B.5.1.17.8 Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN (previously NNP flow 3.4.1)     155     B.5.1.17.9 Successful Resend Broadcast of a Port-to-Original of a Pooled TN (previously NNP flow 3.4.2)     156     B.5.1.17.10 Updates to NPAC SMS after Successful Resend of Port to Original Request of a Pooled TN (previously NNP flow 3.4.3)     157     B.5.1.17.11 Subscription Version Create Port-to-Original of a Pool TN: Resend Failure to Local SMS (previously NNP flow 3.5)     158     B.5.1.17.12 Subscription Version Create Port-to-Original of a Pool TN: Resend Partial Failure to Local SMS (previously NNP flow 3.6)     160     B.5.1.17.13 Subscription Version Port-to-Original of a Pool TN – Creation Prior to NPA-NXX-X Effective Date (previously NNP flow 3.7)     162     B.5.1.18 SubscriptionVersion Inter-Service Provider Create by either SOA (Old or New Service Provider) with a Due Date which is Prior to the NPA NXX Effective Date – Error      163     B.5.2 Modify Scenarios     164     B.5.2.1 SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA     164     B.5.2.2 SubscriptionVersion Modify Active: Failure to Local SMS     166     B.5.2.3 SubscriptionVersion Modify Prior to Activate Using M-ACTION     167     B.5.2.4 SubscriptionVersion Modify Prior to Activate Using M-SET     169     B.5.2.5 Subscription Version Modify Active: Resend Successful to Local SMS     171     B.5.2.6 Subscription Version Modify Active: Resend Failure to Local SMS     172     B.5.2.7 SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA     173     B.5.3 Cancel Scenarios     174     B.5.3.1 SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred     174     B.5.3.1.1 Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)     175     B.5.3.2 SubscriptionVersionCancel: No Acknowledgment from a SOA     176     B.5.3.3 Subscription Version Cancels With Only One Create Action Received     178     B.5.3.4 Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison     179     B.5.3.5 Un Do Cancel Pending Subscription Version Request     180     B.5.4 Disconnect Scenarios     181     B.5.4.1 SubscriptionVersion Immediate Disconnect     181     B.5.4.1.1 SubscriptionVersion Immediate Disconnect (continued)     182     B.5.4.2 SubscriptionVersion Disconnect With Effective Release Date     183     B.5.4.3 SubscriptionVersion Disconnect: Failure to Local SMS     184     B.5.4.4 SubscriptionVersion Disconnect: Partial Failure to Local SMS     185     B.5.4.5 Subscription Version Disconnect: Resend Successful to Local SMS     186     B.5.4.6 Subscription Version Disconnect: Resend Failure to Local SMS     187     B.5.4.7 Disconnect Subscription Version Scenarios for TNs that are part of a Number Pool Block     188     B.5.4.7.1 SOA Initiates Successful Disconnect Request of Ported Pooled TN (previously NNP flow 4.1.1)     188     B.5.4.7.2 Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation (previously NNP flow 4.1.2)     189     B.5.4.7.3 Subscription Version Disconnect With Effective Release Date (replace/update existing flow B.5.4.2 with this flow here – NNP flow 4.2)     190     B.5.4.7.4 Subscription Version Disconnect of a Ported Pooled TN After Block Activation: Failure to Local SMS (previously NNP flow 4.3.1)     191     B.5.4.7.5 Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates (previously NNP flow 4.3.2)     192     B.5.4.7.6 Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS (previously NNP flow 4.4.1)     193     B.5.4.7.7 Subscription Version Disconnect of a Ported Pooled TN Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.4.2)     194                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.    iv                 Table Of Contents                      B.5.4.7.8 Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS (previously NNP flow 4.5.1)     195     B.5.4.7.9 Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates (previously NNP flow 4.5.2)     196     B.5.4.7.10 Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS (previously NNP flow 4.6.1)     197     B.5.4.7.11 Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates (previously NNP flow 4.6.2)     198     B.5.4.7.12 Subscription Version Disconnect of a Ported Pooled TN: Resend Partial Failure to Local SMS (previously NNP flow 4.7.1)     199     B.5.4.7.13 Subscription Version Disconnect of a Ported Pooled TN Resend Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.7.2)     199     B.5.4.7.14 Subscription Version Immediate Disconnect of a Contaminated Pooled TN Prior to Block Activation (after Effective Date) (previously NNP flow 4.8)     201     B.5.5 Conflict Scenarios     202     B.5.5.1 SubscriptionVersion Conflict by the NPAC SMS     202     B.5.5.1.1 Subscription Version Conflict Resolution by the NPAC SMS (continued)     203     B.5.5.2 Subscription Version Conflict Removal by the New Service Provider SOA     204     B.5.5.3 SubscriptionVersion Conflict: No Conflict Resolution     205     B.5.5.3.1 Subscription Version Conflict: No Conflict Resolution (continued)     206     B.5.5.4 Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)     207     B.5.5.5 Subscription Version Conflict Removal by the Old Service Provider SOA     209     B.5.6 SubscriptionVersion Query     210     B.5.6.1 Subscription Data Download     212                 B.6 LSMS Filter NPA-NXX Scenarios     213     B.6.1 1smsFilterNPA-NXX Creation by the Local SMS     213     B.6.2 1smsFilterNPA-NXX Deletion by the Local SMS     214     B.6.3 1smsFilterNPA-NXX Query by the Local SMS     215     B.6.4 1smsFilterNPA-NXX Creation by the SOA     216     B.6.5 1smsFilterNPA-NXX Deletion by the SOA     217     B.6.6 1smsFilterNPA-NXX Query by the SOA     218                 B.7 Local SMS and SOA Recovery     219     B.7.1 Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS (previously NNP flow 5.2)     220     B.7.1.1 Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM     222     B.7.2 Sequencing of Events on Initialization/Resynchronization of EDR Local SMS (previously NNP flow 5.1)     225     B.7.2.1 Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM     227     B.7.3 Sequencing of Events on Initialization/Resynchronization of SOA     231     B.7.3.1 Sequencing of Events on Initialization/Resynchronization of SOA using SWIM     233                 B.8 Miscellaneous     236     B.8.1 SOA/Local SMS Notification of Scheduled NPAC Downtime     236     B.8.2 NPA-NXX Split     237     B.8.2.1 NPA-NXX Split that contains a block of pooled TNs Part 1 (previously NNP flow 7)     238     B.8.2.2 NPA-NXX Split that contains a block of pooled TNs Part 2 (previously NNP flow 7)     239     B.8.3 Mass Update     241     B.8.3.1 Mass Update for a range of TNs that contains a Number Pool Block (previously NNP flow 8)     242     B.8.4 Application Level Heartbeat Requests     243     B.8.4.1 NPAC initiated Application Level Heartbeat Request to local system     243     B.8.4.2 Local system initiated Application Level Heartbeat request     244                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.    v                 Introduction    Introduction  This document contains the appendices for the IIS document. The appendices are in a separate document from the body of the IIS due to the large size of the document.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      1                   Appendix A: Errors    Appendix A. Errors  [Graphic Omitted: Appendix A]  This section will be updated to accommodate the errors associated with ILL 130.          A.1   CMISE Primitive Errors    The following exhibit contains the valid errors associated with CMISE confirmed primitives used in the interoperable interfaces definitions. The situations under which these errors occur are documented in the message flow diagrams in Appendix B.  Exhibit 1. Valid Errors Associated with CMISE-Confirmed Primitives Used by the NPAC SMS              CMISE PRIMITIVE ERRORS   CMISE Primitive   Errors     M-EVENT-REPORT    invalidArgumentValue, noSuchArgument, noSuchObjectClass, noSuchObjectInstance, processingFailure, noSuchEventType     M-GET    accessDenied, classInstanceConflict, complexityLimitation, getListError, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported           M-SET    accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported, setListError           M-ACTION    accessDenied, class-InstanceConflict, complexityLimitation, invalidArgumentValue, invalidFilter, invalidScope, noSuchAction, noSuchArgument,  noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported           M-CREATE    accessDenied, class-InstanceConflict, duplicateManaged-ObjectInstance, invalidAttributeValue, invalidObjectInstance, missingAttributeValue, noSuchAttribute, noSuchObjectClass, noSuchObject-Instance, processingFailure, noSuchReferenceObject           M-DELETE    accessDenied, class-InstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObject-Instance, processingFailure, syncNotSupported             A.2   CMISE Primitive Error Descriptions         accessDenied  The service provider does not have the authorization to do this operation. Examples:       •   The service provider is not authorized to perform this type of operation.        •   The service provider is not the old or new service provider for the subscription version.        •   The modify of the subscription version will cause a mass update.        •   The version selected for a disconnect is not active.         duplicateManagedObjectInstance                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      2                   Appendix A: Errors    For create operations, the requested object already exists. Examples:       •   Pending subscription version, NPA-NXX or LRN already exist on NPAC SMS.         classInstanceConflict  The object specified is not a member of the specified class.       complexityLimitation  A parameter was too complex to complete the operation.       invalidArgumentValue  A specified argument is not valid. Examples:       •   An argument value does not pass validation for an action or event report.        •   A required parameter is missing for an action or event report.        •   An argument value does not exist.         invalidAttributeValue  A specified attribute is not valid.       invalidFilter  A filter specified is not valid.       invalidScope  The scope specified is not valid.       noSuchAction  A specified action is not recognized.       noSuchArgument  A specified argument is not recognized.       noSuchAttribute  A specified attribute is not recognized.       noSuchObjectClass  A specified object class is not recognized.       noSuchObjectInstance  The requested object does not exist. Examples:       •   A query fails based on the search criteria.        •   The referenced object (subscription version, NPA-NXX, LRN, etc.) does not exist.         processingFailure  A general failure has occurred in processing the operation or notification A text string is needed to qualify the error message.  Exhibit 2. processingFailure Errors                  processingFailure Errors       Error ID   Description     0    lnpSpecificInfo (GraphicString)    Invalid CLASS DPC value.                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      3                   Appendix A: Errors         resourceLimitation  The operation was not processed due to a resource limitation.       synchronizationNotSupported  The type of synchronization specified is not supported.          A.3   CMIP Error Mapping to NPAC SMS Errors    The following exhibit provides a mapping of errors generated in the NPAC SMS, to the CMIP error that is sent to a SOA/LSMS. CMIP errors are defined as follows: accessDenied  Implies the service provider cannot perform the given task.       duplicateObjectInstance  The object already exists.       invalidArgumentValue  Represents invalidArgumentValue for an M-ACTION response, and invalidAttributeValue for M-CREATE and M-SET responses.       noSuchObjectInstance  The requested object does not exist.       processingFailure  The processing failed for the reason given.  The CMIP errors listed in the table should be used as a general guideline. Due to interaction of the different request types (M-ACTION, M-CREATE, M-SET, M-DELETE) and the internal handling of errors, some messages may be delivered to the SOA/LSMS using a different CMIP error than those listed in the table.  Exhibit 3 CMIP Error Mapping to NPAC SMS Errors                  SMS Error   Error Description   CMIP Error     0    No error    processingFailure_er   1    No error, used to signal multi pass events that the processing is complete.    processingFailure_er   2    No error, used to signal multi pass events that this is the first pass in processing.    processingFailure_er   100    Timer expected event that was missing, timer will be removed    processingFailure_er   101    Timer could not post event to queue due to database error    processingFailure_er   102    System call failed, PLEASE specify call in additional text.    processingFailure_er   103    operator new failed    processingFailure_er   104    Exception w/descriptive text thrown    processingFailure_er   105    Unknown Exception    processingFailure_er   106    Unable to access CurrentEvent    processingFailure_er   107    Unable to access Events Manager    processingFailure_er   108    Could not open a directory    processingFailure_er   200    Timer expected event that was missing, timer will be removed    accessDenied_er   201    Timer could not post event to queue due to database error    accessDenied_er   202    System call failed, PLEASE specify call in additional text.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      4                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     203    Operator new failed    processingFailure_er   204    Exception w/descriptive text thrown    processingFailure_er   205    Unknown Exception    accessDenied_er   206    Unable to access CurrentEvent    accessDenied_er   207    Unable to access Events Manager    accessDenied_er   208    Could not open a directory    accessDenied_er   209    Event retry limit reached    processingFailure_er   210    Can’t open a file    processingFailure_er   211    Event failed, unknown reason    processingFailure_er   212    Event failed, loaded with unknown reason    processingFailure_er   213    Event failed, sms engine couldn’t acquire lock    processingFailure_er   214    Array bounds exception    processingFailure_er   215    Event missing expected attribute    processingFailure_er   216    Array bounds error    processingFailure_er   2000    Required data for TN field(s) missing.    invalidAttributeValue_er   2001    Required due date entry missing from the subscription version.    invalidAttributeValue_er   2002    Required Customer Disconnect Date missing from the subscription version.    invalidAttributeValue_er   2003    Required New Service Provider ID missing from the subscription version.    invalidAttributeValue_er   2004    Required Old Service Provider ID missing from the subscription version.    invalidAttributeValue_er   2005    Required LRN missing.    invalidAttributeValue_er   2006    Required CLASS DPC missing.    invalidAttributeValue_er   2007    Required CLASS SSN missing.    invalidAttributeValue_er   2008    Required CNAM DPC missing.    invalidAttributeValue_er   2009    Required CNAM SSN missing.    invalidAttributeValue_er   2010    Required ISVM DPC missing.    invalidAttributeValue_er   2011    Required ISVM SSN missing.    invalidAttributeValue_er   2012    Required LIDB DPC missing.    invalidAttributeValue_er   2013    Required LIDB SSN missing.    invalidAttributeValue_er   2014    Required value for Date is missing from Network Data.    invalidAttributeValue_er   2015    Required value for Time is missing from Network Data.    invalidAttributeValue_er   2016    Required value for NPAC Customer Name is missing.    invalidAttributeValue_er   2017    Required value for NPAC Customer Id is missing.    invalidAttributeValue_er   2018    Required value for Transmission Media is missing from Network Data.    accessDenied_er   2019    Required value for NPAC Customer Type is missing from NPAC Customer.    invalidAttributeValue_er   2020    Required value for Allowable Functions is missing from NPAC Customer.    accessDenied_er   2021    Required value for Download is missing from NPAC Customer.    accessDenied_er   2022    Required value for Maximum Query is missing from NPAC Customer.    accessDenied_er   2023    Required value for Contact Name is missing from NPAC Customer.    processingFailure_er   2024    Required value for Address Line 1 is missing from NPAC Customer.    processingFailure_er   2025    Required value for NPAC Customer City is missing from NPAC Customer.    processingFailure_er   2026    Required value for Repair Center City is missing from NPAC Customer.    processingFailure_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      5                   Appendix A: Errors                     SMS Error   Error Description   CMIP Error     2027    Required value for NPAC Customer State is missing from NPAC Customer.    processingFailure_er   2028    Required value for Repair Center State is missing from NPAC Customer.    processingFailure_er   2029    Required value for NPAC Customer Zip Code is missing from NPAC Customer.    processingFailure_er   2030    Required value for Repair Center Zip Code is missing from NPAC Customer.    processingFailure_er   2031    Required value for Pager is missing from NPAC Customer.    processingFailure_er   2032    Required value for Pager PIN is missing from NPAC Customer.    processingFailure_er   2033    Required value for Fax is missing from NPAC Customer.    processingFailure_er   2034    Required value for Email is missing from NPAC Customer.    processingFailure_er   2035    Required value for NSAP is missing from NPAC Customer.    processingFailure_er   2036    Required value for TSAP is missing from NPAC Customer.    processingFailure_er   2037    Required value for SSAP is missing from NPAC Customer.    processingFailure_er   2038    Required value for PSAP is missing from NPAC Customer.    processingFailure_er   2039    Required value for IP is missing from NPAC Customer.    invalidAttributeValue_er   2040    Invalid value for CLASS DPC entered.    invalidAttributeValue_er   2041    Invalid value for CLASS SSN entered.    invalidAttributeValue_er   2042    Invalid value for CNAM DPC entered.    invalidAttributeValue_er   2043    Invalid value for CNAM SSN entered.    invalidAttributeValue_er   2044    Invalid value for ISVM DPC entered.    invalidAttributeValue_er   2045    Invalid value for ISVM SSN entered.    invalidAttributeValue_er   2046    Invalid value for LIDB DPC entered.    invalidAttributeValue_er   2047    Invalid value for LIDB SSN entered.    invalidAttributeValue_er   2048    TN NPA contains invalid data.    invalidAttributeValue_er   2049    TN NXX contains invalid data.    invalidAttributeValue_er   2050    TN extension field contains invalid data.    invalidAttributeValue_er   2051    Month field contains invalid data.    invalidAttributeValue_er   2052    Day field contains invalid data.    invalidAttributeValue_er   2053    Year field contains invalid data.    invalidAttributeValue_er   2054    TN range `through’ field (ending extension value) contains invalid data.    invalidAttributeValue_er   2055    The entered due date and time must be greater than or equal to today’s date and time.    invalidAttributeValue_er   2056    Billing Service Provider ID contains invalid data.    invalidAttributeValue_er   2057    End User Location Value contains invalid data.    invalidAttributeValue_er   2058    End User Location Type contains invalid data.    invalidAttributeValue_er   2059    Invalid value for Time entered.    invalidAttributeValue_er   2060    Invalid value for NPAC Customer Name entered.    invalidAttributeValue_er   2061    Invalid value for NPAC Customer Id entered.    invalidAttributeValue_er   2062    Invalid value for LRN entered.    invalidAttributeValue_er   2063    Invalid value for Transmission Media entered.    invalidAttributeValue_er   2064    Invalid value for NPAC Customer Type entered.    invalidAttributeValue_er   2065    Invalid value for Allowable Functions entered.    invalidAttributeValue_er   2066    Invalid value for Download entered.    invalidAttributeValue_er   2067    Invalid value for Maximum Query entered.    invalidAttributeValue_er   2068    Invalid value for Contact Name entered.    processingFailure_er   2069    Invalid value for Address Line 1 entered.    processingFailure_er   2070    Invalid value for Address Line 2 entered.    processingFailure_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      6                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     2071    Invalid value for City entered.    processingFailure_er   2072    Invalid value for State entered.    processingFailure_er   2073    Invalid value for Zip Code entered.    processingFailure_er   2074    Invalid value for Pager entered.    processingFailure_er   2075    Invalid value for Pager PIN entered.    processingFailure_er   2076    Invalid value for Fax entered.    processingFailure_er   2077    Invalid value for Email entered.    processingFailure_er   2078    Invalid value for NSAP entered.    processingFailure_er   2079    Invalid value for TSAP entered.    processingFailure_er   2080    Invalid value for SSAP entered.    processingFailure_er   2081    Invalid value for PSAP entered.    processingFailure_er   2082    Invalid value for IP entered.    invalidAttributeValue_er   2083    Identical values must be entered into both PASSWORD fields.    accessDenied_er   2084    Password field must be non null.    invalidAttributeValue_er   2085    Password must consist of at least 6 case sensitive alphanumeric characters including at least 1 alphabetic and 1 numeric or punctuation character.    invalidAttributeValue_er   2086    Password may not contain the associated userid.    invalidAttributeValue_er   2087    Input attribute not recognized    accessDenied_er   2088    Required value for contact type is missing from NPAC Customer.    processingFailure_er   2089    Required data for TN field(s) missing from contact list    processingFailure_er   2090    PDP Start Date cannot be modified while split is in progress    invalidAttributeValue_er   2091    Modify disconnect SVs must be in ‘disconnect pending’ state.    accessDenied_er   2092    unnecessary optional field if old spid    invalidAttributeValue_er   2093    unnecessary sv_type if old spid    invalidAttributeValue_er   2094    unnecessary optional field if pto    invalidAttributeValue_er   2095    unnecessary sv_type if pto    invalidAttributeValue_er   2096    optional field is not valid    invalidAttributeValue_er   2097    sv_type is not valid    invalidAttributeValue_er   2098    spid supplied an optional field it does not support    invalidAttributeValue_er   2099    spid supports sv_type but fails to provide    missingAttributeValue   2100    optional field is not known    invalidAttributeValue_er   2101    unnecessary optional field    invalidAttributeValue_er   2102    unnecessary sv_type    invalidAttributeValue_er   2103    spid supplied sv_type it does not support    invalidAttributeValue_er   2105    SP must support linked reply for SWIM recovery    accessDenied_er   2106    SP requesting SWIM recovery does not support SWIM    accessDenied_er   2107    Action ID not valid    invalidAttributeValue_er   2108    Required service provider type is not supplied    invalidAttributeValue_er   2109    Service provider type is not valid    invalidAttributeValue_er   2110    SP is not allowed to modify service provider type    accessDenied_er   2111    Service provider type is not consistent with its name    invalidAttributeValue_er   2112    new SP can not resolve conflict with cause code of 50 or 51    accessDenied_er   2113    SV in wrong status for undo cancel operation    noSuchObjectInstance   2114    SV in wrong new status for undo cancel operation    invalidAttributeValue_er   2115    Undo cancel originator SP has not canceled the SV    accessDenied_er   2116    Missing input data for undo cancel operation    invalidAttributeValue_er   2117    SP exceeded LSMS or SOA SWIM recovery limit    processingFailure_er   2118    Undo Cancel Not Supported In This Region.    accessDenied_er   2119    SP Does Not Support SPID Recovery.    accessDenied_er   3000    Value entered for system tunable is out of range.    accessDenied_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      7                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     3001    You entered an invalid logon name or password.    invalidAttributeValue_er   3002    The User Group and User Level have conflicting access levels.    accessDenied_er   3003    Non unique userid was entered for this user.    invalidAttributeValue_er   3004    Your password has expired.    accessDenied_er   3005    New password must differ from old passwords    accessDenied_er   3006    System was unable to add user    accessDenied_er   3007    Not all user data needed was provided    invalidAttributeValue_er   3008    Operation referenced a user that does not exist.    invalidAttributeValue_er   3009    Update of a tunable failed or tunable is missing.    accessDenied_er   3010    Unable to load holiday collection from DB.    processingFailure_er   3011    Unable to add a holiday to the collection    accessDenied_er   3012    Unable to delete a holiday from the collection    accessDenied_er   3013    Unable to find a holiday in the collection    accessDenied_er   3014    Event has incorrect subtype    invalidAttributeValue_er   3015    End time is before start time    invalidAttributeValue_er   3016    Start time is before now    invalidAttributeValue_er   3017    Tunable already exists    duplicateManagedObjectInstance   3018    Tunable doesn’t exist and must in order to be modified    noSuchObjectInstance   3019    Tunable has invalid value    invalidAttributeValue_er   3500    Password will expire in <x> days.    accessDenied_er   3501    The user about to be deleted is currently logged on to the system.    accessDenied_er   3502    This action will affect the entire NPAC SMS.    accessDenied_er   3503    Your password has expired.    accessDenied_er   3504    The NPAC is not accepting logins at this time    processingFailure_er   4000    Key List creation failure.    accessDenied_er   4001    Mismatch of hash values for key in key list.    processingFailure_er   4002    Failure calculating checksum for key list.    accessDenied_er   4003    No keys available for this NPAC Customer in any active key list.    accessDenied_er   4004    Non unique keys found in key list.    invalidAttributeValue_er   4005    No active key list available for this NPAC Customer.    accessDenied_er   4006    Invalid Key File Format.    invalidAttributeValue_er   4007    Key List generation is already in progress.    accessDenied_er   4008    Illegal key list state change failure    accessDenied_er   4009    Missing required data in key management event    invalidAttributeValue_er   4010    Key File event failed to process correctly    accessDenied_er   4011    New key specified by service provider is not usable    accessDenied_er   4012    Failure reading key file, invalid key data or list id.    invalidAttributeValue_er   4013    Failure reading keys from key list in database.    processingFailure_er   4500    There are fewer than 100 keys remaining for this Service Provider.    invalidAttributeValue_er   4750    No match found in the database for the search criteria.    noSuchObjectInstance   5000    Item being added already exists in the database.    duplicateManagedObjectInstance   5001    One or more subscriptions will be affected by change. Change is denied.    accessDenied_er   5002    One or more LRNs will be affected by change. Change/Delete is denied.    accessDenied_er   5003    One or more NPA-NXXs will be affected by change. Change/Delete is denied.    accessDenied_er   5004    Subscriptions in either partial failed or sending state are associated with the change. Change/Delete is denied.    accessDenied_er   5005    GTT data is not equivalent across TN range specified. Modify the TN range.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      8                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     5006    Bulk Download-invalid criteria specified    processingFailure_er   5007    Bulk Download-file error    processingFailure_er   5008    Resync Data invalid criteria specified    invalidAttributeValue_er   5009    LrnId is required if no customer id, on delete lrn action.    invalidAttributeValue_er   5010    The requested LRN does not exist in the NPAC SMS system.    noSuchObjectInstance   5011    No network data match for search criteria in database.    noSuchObjectInstance   5012    Requestor doesn’t own item being deleted.    accessDenied_er   5014    Resync Data-Maximum records reached or exceeded.    accessDenied_er   5015    Npa required for delete if no NpaNxxId.    invalidAttributeValue_er   5016    Nxx required for delete if no NpaNxxId.    invalidAttributeValue_er   5017    Lrn required for delete if no lrnId.    invalidAttributeValue_er   5018    NpaNxx Accept-invalid or missing npa    invalidAttributeValue_er   5019    NpaNxx Accept-invalid or missing nxx    invalidAttributeValue_er   5020    NpaNxx Accept-invalid or missing customer id    invalidAttributeValue_er   5021    NpaNxx Accept-invalid or missing accepted id    invalidAttributeValue_er   5022    CustomerId and name passed in do not match those in database.    invalidAttributeValue_er   5024    Ending npa/nxx doesn’t exist in database.    invalidAttributeValue_er   5027    Npa required for npa split.    invalidAttributeValue_er   5028    New Npa required for npa split.    invalidAttributeValue_er   5031    PDP Start required for npa split.    invalidAttributeValue_er   5032    PDP End required for npa split.    invalidAttributeValue_er   5033    Resync Type required for resync.    invalidAttributeValue_er   5034    Resync Start TS required for resync.    invalidAttributeValue_er   5035    Npa required for resync of type npa range.    invalidAttributeValue_er   5036    Ending Npa required for resync of type npa range.    invalidAttributeValue_er   5037    Nxx required for resync of type npa range.    invalidAttributeValue_er   5038    Ending Nxx required for resync of type npa range.    invalidAttributeValue_er   5039    Lrn required for resync of type lrn range.    invalidAttributeValue_er   5040    End Lrn required for resync of type lrn range.    invalidAttributeValue_er   5041    No NpaNxx is available from the NPANXX::SelectRandom() method.    invalidAttributeValue_er   5042    Request failed on previous npaNxx.    processingFailure_er   5043    Request failed on previous lrn.    processingFailure_er   5044    There are no npanxx’s in the specified range    invalidAttributeValue_er   5045    Supplied customer id does not match any npanxx’s in range    invalidAttributeValue_er   5046    Resync rollup failed    accessDenied_er   5047    Resync returned zero records    accessDenied_er   5048    Resync time range exceeds duration tunable    accessDenied_er   5050    Active SVs found for the new NPA NXX.    invalidAttributeValue_er   5051    Invalid Permissive Dialing Period Date entered.    invalidAttributeValue_er   5052    NPA NXX Already involved in another split.    invalidAttributeValue_er   5053    Missing required data: NXX List.    invalidAttributeValue_er   5054    Missing required data: NPA Split Id.    invalidAttributeValue_er   5055    Permissive Dialing Period End Date must be after now.    invalidAttributeValue_er   5056    Missing required data: PDP End Date and/or Nxx List.    invalidAttributeValue_er   5057    Permissive Dialing Period Start Date must be after now.    invalidAttributeValue_er   5058    PDP Start date must be before PDP End date.    invalidAttributeValue_er   5059    PDP Start value must equal Effective timestamp of each new NPA NXX involved in the split.    invalidAttributeValue_er   5060    New and old NPA NXX records must be owned by same SP.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      9                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error    5061    Cannot Delete a split after the start of PDP.    invalidAttributeValue_er    5062    The NPA-NXX is currently involved in a split.    invalidAttributeValue_er   5070    FAILURE attempting to update NPA-NXX.    accessDenied_er   5071    FAILURE attempting to delete NPA_SPLIT_LOG records.    accessDenied_er   5072    FAILURE attempting to delete NPA_SPLIT records.    accessDenied_er   5073    Delete denied due to associated NPA-NXX-Xs.    invalidAttributeValue_er   5074    Block action denied due to spid not owning lrn.    invalidAttributeValue_er   5075    Create block failed due to too many tns in block.    invalidAttributeValue_er   5076    Create block failed due to tns already in another block.    invalidAttributeValue_er   5077    NPA-NXX-X action denied due to effective date before NpaNxx effective ts.    invalidAttributeValue_er   5078    Block id is required for block modify.    invalidAttributeValue_er   5079    Lrn or GTT Data is required for block modify.    invalidAttributeValue_er   5080    Block does not exist in database.    invalidAttributeValue_er   5081    NPA-NXX-X delete denied due to non active block.    accessDenied_er   5082    Customer delete denied due to associated NPA-NXX-Xs.    invalidAttributeValue_er   5083    BlockId does not exist in the NPAC system.    invalidAttributeValue_er   5084    The TUNA_MAXIMUM_BLOCK_RANGE value for querying blocks is missing.    invalidAttributeValue_er   5085    Blocks found: exceed maximum query limit.    processingFailure_er   5086    Block Holder cannot equal the code holder.    invalidAttributeValue_er   5087    The NpaNxxAcceptId does not exist in the NpaNxxAcceptTable.    invalidAttributeValue_er   5088    NPA-NXX-X action denied: effective date is before NPA-NXX live timestamp.    accessDenied_er   5089    SV action denied because due date is before NPA-NXX live timestamp.    accessDenied_er   5090    NetworkNotificationRecoveryAction time range is invalid    invalidAttributeValue_er   5091    NetworkNotificationRecoveryAction time range exceeds tunable    accessDenied_er   5092    NPA-NXX-X delete denied due to associated failed LSMS entries.    accessDenied_er   5093    Pending like with active pooled SVs and Pending like PTO SVs exist.    accessDenied_er   5094    Cannot delete NPA-NXX-X using new Npa for a scheduled split.    accessDenied_er   5095    The NPA-NXX-X-ID is required.    invalidAttributeValue_er   5096    No matching NPA-NXX-X exists in the database.    noSuchObjectInstance   5097    The NPA-NXX-X is required.    missingAttributeValue   5098    The SOA Origination Indicator is required.    missingAttributeValue   5099    A scheduled create block event is required.    missingAttributeValue   5100    The number of business days between the NPA-NXX-X’s creation date and effective date does not meet the minimum tunable value.    accessDenied_er   5101    Block Create request is before NPA-NXX-X’s effective date.    invalidAttributeValue_er   5102    A pending/conflict/cancel pending/failed PTO SV exists.    accessDenied_er   5103    LIDB SSN is not allowed.    invalidAttributeValue_er   5104    LIDB DPC is not allowed.    invalidAttributeValue_er   5105    ISVM SSN is not allowed.    invalidAttributeValue_er   5106    ISVM DPC is not allowed.    invalidAttributeValue_er   5107    CNAM SSN is not allowed.    invalidAttributeValue_er   5108    CNAM DPC is not allowed.    invalidAttributeValue_er   5109    CLASS SSN is not allowed.    invalidAttributeValue_er   5110    CLASS DPC is not allowed.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      10                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     5111    LRN is not allowed.    invalidAttributeValue_er   5112    A pooled block already exists.    accessDenied_er   5113    Cannot modify an NPA-NXX-X using the new Npa of a scheduled split.    accessDenied_er   5114    Cannot create an NPA-NXX-X using the new Npa of a scheduled split.    accessDenied_er   5115    Effective date is not allowed.    invalidAttributeValue_er   5116    An NPA-NXX-X exists for the new Npa.    accessDenied_er   5117    PDP Start, PDP End, or NXX List must be supplied in modify request.    invalidAttributeValue_er   5118    New NPA-NXX already exists.    invalidAttributeValue_er   5119    PDP Start Date cannot be changed if pending SVs exist in new NPA-NXX    invalidAttributeValue_er   5120    At least one of old and new NPA-NXX must exist.    invalidAttributeValue_er   5121    PDP Start date cannot change after PDP Start.    invalidAttributeValue_er   5122    An SV exists in both the old and new NPA-NXX.    invalidAttributeValue_er   5123    A DashX exists in the new NPA-NXX.    invalidAttributeValue_er   5124    Cannot create LISP PTO with scheduled block creation.    accessDenied_er   5125    Deferred disconnect timer is firing, modify denied.    accessDenied_er   5126    LRN specified for SV is in a different LATA from TN.    invalidAttributeValue_er   5127    LRN specified for Block is in a different LATA from DashX.    invalidAttributeValue_er   5128    SPID migration file open error.    invalidAttributeValue_er   5129    LATA ID Not Found in the LATA File.    invalidAttributeValue_er   5130    LATA File Access Error.    invalidAttributeValue_er   5131    Notification recovered exceeded max tunable for sp supports linked reply.    accessDenied_er   5132    BDD response file invalid    invalidAttributeValue_er   5133    Processing BDD response file failed    accessDenied_er   5134    Consistency check failed for network item (i.e. LRN, NPANXX, and DashX)    accessDenied_er   5135    NPA-NXX not valid for this region.    invalidAttributeValue_er   5500    One or more subscriptions will be affected by change. Require user acknowledgment to proceed.    accessDenied_er   6000    Item being added already exists in the database.    invalidAttributeValue_er   6001    One or more subscriptions will be affected by change. Change is denied.    accessDenied_er   6002    One or more npa nxxs are associated with this customer, Delete is denied.    accessDenied_er   6003    One or more lrns are associated with this customer, Delete is denied.    accessDenied_er   6004    NPAC Customer ID cannot be modified.    invalidAttributeValue_er   6005    The NPAC Customer being modified does not exist in the database.    noSuchObjectInstance   6006    The NPAC Customer being deleted does not exist in the database, or has already been deleted.    noSuchObjectInstance   6007    Invalid contact type for NPAC Customer    processingFailure_er   6008    The contact info array is missing from the Customer.    invalidAttributeValue_er   6009    The network address list array is missing from the Customer.    invalidAttributeValue_er   6010    The network address type is missing from the Customer.    processingFailure_er   6011    The npac customer contact is missing from the Customer.    processingFailure_er   6012    The billing contact is missing from the Customer.    processingFailure_er   6013    The security contact is missing from the Customer.    processingFailure_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      11                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     6014    The repair contact is missing from the Customer.    processingFailure_er   6015    At least one network address is required for Customer.    invalidAttributeValue_er   6016    Required value for Contact Name is missing from Billing Contact.    processingFailure_er   6017    Required value for Address Line 1 is missing from Billing Contact.    processingFailure_er   6018    Required value for NPAC Customer City is missing from Billing Contact.    processingFailure_er   6019    Required value for NPAC Customer State is missing from Billing Contact.    processingFailure_er   6020    Required value for NPAC Customer Zip Code is missing from Billing Contact.    processingFailure_er   6021    Required value for Contact Name is missing from Repair Contact.    processingFailure_er   6022    Required value for Address Line 1 is missing from Repair Contact.    processingFailure_er   6023    Required value for Contact Name is missing from Security Contact.    processingFailure_er   6024    Required value for Address Line 1 is missing from Security Contact.    processingFailure_er   6025    Required value for NPAC Customer City is missing from Security Contact.    processingFailure_er   6026    Required value for NPAC Customer State is missing from Security Contact.    processingFailure_er   6027    Required value for NPAC Customer Zip Code is missing from Security Contact.    processingFailure_er   6028    Event subtype not recognized    invalidAttributeValue_er   6029    Invalid operation for this NPAC Customer    accessDenied_er   6030    SP User cannot modify Customer Name on modify.    invalidAttributeValue_er   6031    SP User cannot modify allowable functions mask on modify.    invalidAttributeValue_er   6032    Required value for country is missing from contact data.    processingFailure_er   6033    SP block indicator must be only attribute on event    invalidAttributeValue_er   6034    LTI Only Customer attribute missing from event    invalidAttributeValue_er   6035    SP can not modify sp block indicator flag    invalidAttributeValue_er   6036    Customer cannot be deleted if associated with primary or secondary customer    invalidAttributeValue_er   6037    Active customer to modify or delete does not exist    accessDenied_er   6038    Customer cannot be modified to LTI User if associated customers exist.    invalidAttributeValue_er   6039    Customer Request denied due to duplicate Network Address PSAP.    invalidAttributeValue_er   6040    Customer does not exist and cannot be added as a Secondary Customer.    noSuchObjectInstance   6041    This customer must be removed from all router config lists before it can be deleted.    accessDenied_er   6500    One or more subscriptions will be affected by change. Require user acknowledgment to proceed.    invalidAttributeValue_er   6750    No match found in the database for the search criteria.    noSuchObjectInstance   6751    <x> Subscriptions found: exceed maximum query limit.    invalidAttributeValue_er   6752    No subscription versions found for the given input search criteria.    noSuchObjectInstance   6753    Warning Primary Customer has no SOA Functionality Set.    invalidAttributeValue_er   6754    Warning Secondary Customer has no SOA Functionality Set.    invalidAttributeValue_er   7000    The NPA NXX for this operation does not exist in the NPAC SMS system.    noSuchObjectInstance                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      12                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7001    Service Provider ID does not exist in the NPAC SMS system.    invalidAttributeValue_er   7002    The Service Provider issuing this subscription version request is not the Service Provider identified as the New Service Provider ID or the Old Service Provider ID on the subscription version    accessDenied_er   7003    This Service Provider has already issued a create for the subscription version.    duplicateManagedObjectInstance   7004    The entered LRN is not associated with the New Service Provider in the NPAC SMS system.    invalidAttributeValue_er   7005    The Old Service Provider ID in the subscription version does not match the current Service Provider ID on an existing active subscription version for this TN.    accessDenied_er   7006    The New Service Provider ID input data does not match the new Service Provider ID in an existing pending subscription version for this TN.    accessDenied_er   7007    The Old Service Provider ID input data does not match the old Service Provider ID in an existing pending subscription version for this TN.    accessDenied_er   7008    Releasing a subscription version for an Intra-Service Provider port does not apply.    accessDenied_er   7009    The Old Service Provider ID must match the New Service Provider ID for an Intra-Service Port.    invalidAttributeValue_er   7010    The New and Old Service Provider Due Dates must match.    invalidAttributeValue_er   7011    An active subscription version must exist for an Intra SP port.    accessDenied_er   7012    A subscription version with sending status cannot be modified.    accessDenied_er   7013    A subscription version with failed status cannot be modified.    accessDenied_er   7014    A subscription version with partial failure status cannot be modified.    accessDenied_er   7015    A subscription version with canceled status cannot be modified.    accessDenied_er   7016    A subscription version with old status cannot be modified.    accessDenied_er   7017    A subscription version with disconnect pending status cannot be modified.    accessDenied_er   7018    A subscription version with cancel pending status cannot be modified.    accessDenied_er   7019    A subscription version must be in pending status to be activated.    accessDenied_er   7020    The Old Service Provider ID is not equal to the New Service Provider ID on the active subscription version, as required for an Intra Service Provider port.    accessDenied_er   7021    The Service Provider originating the modification request is not the current Service Provider.    accessDenied_er   7022    The subscription version cannot be put in conflict because its current status is not pending, or cancel pending.    accessDenied_er   7023    The subscription version cannot be disconnected because there is no current subscription version in active status.    accessDenied_er   7024    This active subscription version cannot be disconnected until a sending subscription version successfully completes.    accessDenied_er   7025    This active subscription version cannot be disconnected until a failed or partial failure subscription version is re-sent and successfully completes.    accessDenied_er   7026    The subscription version cannot be canceled because its current status is not pending, conflict or disconnect pending.    accessDenied_er   7027    The subscription version cannot be resent because its current status is not partial failure, failure, disconnect pending, old or active.    accessDenied_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      13                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7028    Active subscription version may not be modified because a related subscription version for this TN has been activated.    accessDenied_er   7029    Pending subscription version may not be activated until a related subscription version in sending status becomes active.    accessDenied_er   7030    Deferred disconnect request is not allowed because a pending subscription version exists for this TN.    accessDenied_er   7031    This subscription version may not be activated because authorization for transfer of service has not been received from the New SP.    accessDenied_er   7032    The due date of a subscription version with active status cannot be modified.    invalidAttributeValue_er   7033    Porting To Original must be false for inter service ports.    invalidAttributeValue_er   7034    Required Port Type is missing from input data.    invalidAttributeValue_er   7035    Required TN data (NPA) is missing from input data.    invalidAttributeValue_er   7036    Required TN data (NXX) is missing from input data.    invalidAttributeValue_er   7037    Required TN data (starting station) is missing from input data.    invalidAttributeValue_er   7038    Required TN data (ending station) is missing from input data.    invalidAttributeValue_er   7039    Required Old Service Provider Authorization Flag missing from the subscription version.    invalidAttributeValue_er   7040    Required Porting To Original Flag is missing from input data.    invalidAttributeValue_er   7041    NPAC SMS allows only one of pending, cancel pending, conflict, disconnect pending, failed or partial failure Subscription Version per TN.    invalidAttributeValue_er   7043    LIDB SSN is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7044    LIDB SSN is not allowed for old service provider input.    invalidAttributeValue_er   7045    LIDB DPC is not allowed for old service provider input.    invalidAttributeValue_er   7046    LIDB DPC is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7047    ISVM SSN is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7048    ISVM SSN is not allowed for old service provider input.    invalidAttributeValue_er   7049    ISVM DPC is not allowed for old service provider input.    invalidAttributeValue_er   7050    ISVM DPC is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7051    CNAM SSN is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7052    CNAM SSN is not allowed for old service provider input.    invalidAttributeValue_er   7053    CNAM DPC is not allowed for old service provider input.    invalidAttributeValue_er   7054    CNAM DPC is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7055    CLASS SSN is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7056    CLASS SSN is not allowed for old service provider input.    invalidAttributeValue_er   7057    CLASS DPC is not allowed for old service provider input.    invalidAttributeValue_er   7058    CLASS DPC is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7059    LRN is not allowed for Porting-to-Original ports.    invalidAttributeValue_er   7060    LRN is not allowed for old service provider input.    invalidAttributeValue_er   7061    New Service Provider due date is not allowed for Old Service Provider input.    invalidAttributeValue_er   7062    Old Service Provider due date is not allowed for New Service Provider input.    invalidAttributeValue_er   7063    Old Service Provider Authorization Flag is not allowed for New Service Provider input.    invalidAttributeValue_er   7064    Old Service Provider Authorization Flag is not allowed for Intra-Service Ports.    invalidAttributeValue_er   7065    Billing Service Provider ID is not allowed for Old Service Provider input.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      14                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7066    End User Location is not allowed for Old Service Provider input.    invalidAttributeValue_er   7067    End User Location Type is not allowed for Old Service Provider input.    invalidAttributeValue_er   7068    Either the Ported Telephone Number or the Subscription Version ID is required to activate a subscription version.    invalidAttributeValue_er   7069    The Old Service Provider cannot modify an intra service port.    accessDenied_er   7070    Only the Current Service Provider can disconnect a subscription version.    accessDenied_er   7071    SV cannot be disconnected if it has failed list, or an active like, or pending like SV exists for that TN    accessDenied_er   7072    The subscription version cannot be removed from conflict because its current status is not conflict.    accessDenied_er   7073    Only the Current Service Provider can activate a subscription version.    invalidAttributeValue_er   7074    A pending subscription version cannot be activated before its npa_nxx’s effective date.    invalidAttributeValue_er   7075    NPAC SMS allows only one sending Subscription Version per TN.    accessDenied_er   7076    NPAC SMS allows only one active Subscription Version per TN.    accessDenied_er   7077    Request failed on previous subscription version.    processingFailure_er   7078    Required subscription version ID is missing from input data.    invalidAttributeValue_er   7079    Required TimerId is missing from input data.    accessDenied_er   7080    Required ConflictDate is missing from input data.    invalidAttributeValue_er   7081    Required PendingDate is missing from input data.    invalidAttributeValue_er        The Service Provider requesting this cancel did not create the       7082    subscription version.    accessDenied_er   7083    There is no subscription version with the requested status.    invalidAttributeValue_er   7084    The subscription version status is required to modify a subscription version.    invalidAttributeValue_er   7085    The action ID field is required for LsmsSvNotifyResponseEvent event type.    processingFailure_er   7086    The old service provider cannot request conflict resolution.    accessDenied_er   7087    Mass Update requires at least one of the following as input: LRN, a gtt data item, billing id, end user location, end user location type.    invalidAttributeValue_er   7088    Active subscription versions cannot be modified via CMIP set.    accessDenied_er   7089    The Old Service Provider has already put this subscription version into conflict the maximum number of times.    accessDenied_er   7090    It is too close to the New Service Provider due date for the Old Service Provider to place the subscription version into conflict.    accessDenied_er   7091    This subscription version may not be activated because the Old Service Provider’s concurrence window has not yet expired.    accessDenied_er   7092    Required originating SPID is missing from input data.    invalidAttributeValue_er   7093    SV Notification SV_MODIFIED missing response.    invalidAttributeValue_er   7094    Either the Ported Telephone Number or the Subscription Version ID is required to modify a subscription version.    invalidAttributeValue_er   7095    Required Resync Type is missing from input data.    invalidAttributeValue_er   7096    Required Resync Start Timestamp is missing from input data.    invalidAttributeValue_er   7097    Either the Ported Telephone Number or the Subscription Version ID is required to cancel a subscription version.    invalidAttributeValue_er   7098    Either the Ported Telephone Number or the Subscription Version ID is required to resolve a conflicted subscription version.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      15                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7099    Either the Ported Telephone Number or the Subscription Version ID is required to disconnect a subscription version.    invalidAttributeValue_er   7100    Either the Ported Telephone Number or the Subscription Version ID is required to create a subscription version.    invalidAttributeValue_er   7101    The NPA-NXX of the TN has been split. The entered TN is the old NPA-NXX.    invalidAttributeValue_er   7102    Either the subscription version ID or TN is required for concurrence.    invalidAttributeValue_er   7104    The Status Change Cause Code is required if the authorization flag is false.    invalidAttributeValue_er   7105    The Status Change Cause Code cannot be set if the authorization flag is true.    invalidAttributeValue_er   7106    The Status Change Cause Code cannot be set if the new service provider is the originator.    invalidAttributeValue_er   7107    Invalid Status Change Cause Code.    invalidAttributeValue_er   7108    A pending subscription version cannot be activated before its due date.    invalidAttributeValue_er   7109    The Old Service Provider cannot cancel this subscription version which is in conflict because the New Service Provider did not concur with a prior cancellation.    invalidAttributeValue_er   7110    The New Service Provider cannot resolve this conflict until the tunable period of time has passed since the Old Service Provider moved it into conflict.    accessDenied_er   7111    Porting To Original Flag is not allowed for old service provider input.    invalidAttributeValue_er   7112    At least one of the following is required as input for subscription version modification: LRN, a gtt data item, billing id, end user location, end user location type.    processingFailure_er   7113    LSMS did not respond in allotted time.    processingFailure_er   7114    Missing SV Tunable value.    invalidAttributeValue_er   7115    The Status Change Cause Code is required if the old service provider is the originator.    invalidAttributeValue_er   7116    The subscription version cannot be resent because it does not have a failed LSMS list.    accessDenied_er   7117    Either the due date or the authorization flag is required to modify a subscription version by the old Service Provider.    invalidAttributeValue_er   7118    On a modify by new/current Service Provider, one of the GTT input data fields, lrn, billing data, or due date is required.    invalidAttributeValue_er   7119    A Disconnect request for an active subscription version for this TN previously failed. This failure must be resolved before a create is allowed.    accessDenied_er   7120    The LNP Type input in the event does not match the LNP type of a pending SV for this TN.    invalidAttributeValue_er   7121    A subscription version with cancel pending status exists. A new one cannot be created for this TN.    accessDenied_er   7122    A pending subscription version for the TN exists.    accessDenied_er   7123    A subscription version with disconnect pending status exists. A new one cannot be created for this TN.    accessDenied_er   7124    The old authorization flag of a subscription version with active status cannot be modified.    invalidAttributeValue_er   7125    The change cause code of a subscription version with active status cannot be modified.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      16                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7126    A Failed subscription version for the TN exists. This failure must be resolved before a modify is allowed.    accessDenied_er   7127    There is no subscription version matching the query filter data.    noSuchObjectInstance   7128    The Service Provider requesting this modify did not create the subscription version.    accessDenied_er   7129    The Ending Station must be a number greater than the Starting Station.    invalidAttributeValue_er   7130    The LNP Type must be either LISP or LSPP.    accessDenied_er   7131    The Old Service Provider cannot cancel a disconnect pending subscription version.    accessDenied_er   7132    A subscription version with sending status exists. A new one cannot be created for this TN.    accessDenied_er   7133    The Service Provider requesting this conflict did not create the subscription version.    accessDenied_er   7134    Waiting on New SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.    accessDenied_er   7135    Waiting on Old SP concurrence. The Service Provider issuing this cancel already cancelled the subscription version.    accessDenied_er   7136    There must be an active SV for a porting to original port.    accessDenied_er   7137    The requested subscription version does not exist.    noSuchObjectInstance   7138    A subscription version with pending status exists. A new one cannot be created for this TN.    accessDenied_er   7139    The Service Provider requesting this conflict resolution did not create the subscription version.    accessDenied_er   7140    The Old Service Provider ID must not match the New Service Provider ID for an Inter Service Port.    invalidAttributeValue_er   7141    Subscription version must be in cancel pending state for concurrence.    accessDenied_er   7142    The action ID does not belong to originator.    processingFailure_er   7143    NPAC SMS allows only two sending Subscription Versions per tn for port to original.    accessDenied_er   7144    The change cause code of a subscription version cannot be modified if it is already set.    invalidAttributeValue_er   7145    NPAC SMS allows only three sending Subscription Versions per tn for port to original of sv in block.    accessDenied_er   7146    The user originating the Block request is not an NPAC Personnel user.    accessDenied_er   7148    The New Service Provider ID must match the Block Holder ID for a Block.    invalidAttributeValue_er   7149    Required BlockId is missing from input data.    invalidAttributeValue_er   7150    Old Service Provider due date is not allowed for a block creation.    invalidAttributeValue_er   7151    Old Service Provider ID is not allowed for a block.    invalidAttributeValue_er   7152    LRN is not allowed for a block.    invalidAttributeValue_er   7163    A pending subscription version exists for this NPA-NXX-X. A block cannot be created.    accessDenied_er   7164    New Service Provider due date is not allowed for a block.    invalidAttributeValue_er   7165    A block cannot be created before the NPA-NXX-X’s effective date.    accessDenied_er   7166    A block cannot be created before the NpaNxx’s effective date.    accessDenied_er   7167    A subscription version with LNP Type POOL cannot be activated.    accessDenied_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      17                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7168    Only NPAC Personnel may disconnect a pooled SV.    accessDenied_er   7169    Effective Release Date cannot be set for pooled SV disconnect.    invalidAttributeValue_er   7170    NPAC SMS allows only two sending Subscription Versions per tn for ports of SVs in a block.    accessDenied_er   7171    New Service Provider ID is not allowed for a block create.    invalidAttributeValue_er   7172    All TNs in the block range are currently ported.    accessDenied_er   7173    An old subscription version with a failed LSMS list exists. A new one cannot be created.    accessDenied_er   7174    The new SP for this Port To Original SV is not the donor of the NpaNxx.    accessDenied_er   7175    Time Range exceeds tunable value.    invalidAttributeValue_er   7176    Delete denied, tunable does not exist.    noSuchObjectInstance   7177    Create denied, tunable already exists.    duplicateManagedObjectInstance   7178    Modify denied, tunable does not exist.    noSuchObjectInstance   7179    WSMSC DPC required if SOA supports it.    invalidAttributeValue_er   7180    WSMSC SSN required if SOA supports it.    invalidAttributeValue_er   7181    WSMSC DPC not valid input for this action.    invalidAttributeValue_er   7182    WSMSC SSN not valid input for this action.    invalidAttributeValue_er   7183    Query expression required on mass update.    invalidAttributeValue_er   7184    Either subscription version ID, block ID, TN or all failures is required on resend.    invalidAttributeValue_er   7185    Cannot retrieve svs from temp table.    processingFailure_er   7186    The Event does not contain any data to process.    invalidAttributeValue_er   7187    Failure changing viewed indicator.    processingFailure_er   7188    Modify failed: the notification does not exist in the database.    invalidAttributeValue_er   7189    Either BlockId or NPA-NXX-X and status are required for block modify    invalidAttributeValue_er   7190    NPA-NX-X is required for block create    invalidAttributeValue_er   7191    Cannot create LISP, after dashX creation, before block is created    accessDenied_er   7192    Pending like svs exist with matching pto svs    accessDenied_er   7193    Non active non pooled svs exist    accessDenied_er   7194    Only npac personnel can create lisp with pending block creation    accessDenied_er   7195    New sp of lisp create must be code holder with pending block creation    accessDenied_er   7196    Cannot create lisp if active sv exists and pending block creation    accessDenied_er   7197    Cannot create lspp with pending block creation    accessDenied_er   7198    Cannot create sv if dashx has failed lsms list    accessDenied_er   7199    WSMSC DPC entered is invalid    invalidAttributeValue_er   7200    WSMSC SSN entered is invalid    invalidAttributeValue_er   7201    Can only modify pooled svs with block modify request    accessDenied_er   7202    Only npac personnel can modify the soa indicator    invalidAttributeValue_er   7203    Cannot modify pooled block if block has failed lsms list    accessDenied_er   7204    Cannot modify non active pooled svs    accessDenied_er   7205    Cannot activate lisp if active sv exists    accessDenied_er   7206    Cannot activate pto during dashx deletion.    accessDenied_er   7207    Cannot activate pto due to failed dashX deletion.    accessDenied_er   7208    Cannot cancel a pooled sv    accessDenied_er   7209    Cannot conflict a pooled sv    accessDenied_er   7210    Pending like SVs exist with no matching active SVs.    accessDenied_er   7211    Can only modify one pooled block at a time.    accessDenied_er   7212    Mass Update of pooled block must wholly encompass block.    accessDenied_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      18                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     7213    You cannot resend a pooled SV.    accessDenied_er   7214    No subscription versions found for the given input search criteria.    noSuchObjectInstance   7215    Subscriptions found exceed maximum query limit.    complexityLimitation   7216    Subscription version must be in pending or conflict state for create timeout.    accessDenied_er   7217    Subscription version must be in cancel pending state for cancel timeout.    accessDenied_er   7218    The old customer id on the create does not match the owner of the associated npa nxx.    accessDenied_er   7219    Found active like SV for block creation.    invalidAttributeValue_er   7220    A subscription version’s due date cannot be before its npa_nxx’s effective date.    invalidAttributeValue_er   7221    Status change cause code is not allowed on an LISP creation, modification, or set to conflict.    invalidAttributeValue_er   7222    Old due date is not allowed on an LISP creation or modification.    invalidAttributeValue_er   7223    A subscription version with failed status exists. A new one cannot be created for this TN.    accessDenied_er   7224    A subscription version with partial failed status exists. A new one cannot be created for this TN.    accessDenied_er   7225    Recovered objects found exceed maximum limit.    complexityLimitation   7226    An active subscription version with failed list can not be modified. This failure must be resolved before a modify is allowed.    accessDenied_er   7227    Old SP cant modify NewSPDueDate Or RoutingData.    accessDenied_er   7228    New SP cant modify OldSPDueDate, Authorization or CauseCode.    accessDenied_er   7500    The entered due date differs from the due date entered by the other Service Provider.    invalidAttributeValue_er   7751    Block successfully activated.    processingFailure_er   7752    Block successfully modified.    processingFailure_er   7753    Block successfully disconnected.    processingFailure_er   7754    Block activate partially failed.    processingFailure_er   7755    Block modify partially failed.    processingFailure_er   7756    Block disconnect partially failed.    processingFailure_er   7757    Block activate totally failed.    processingFailure_er   7758    Block modify totally failed.    processingFailure_er   7759    Block disconnect totally failed.    processingFailure_er   7760    Found Same TN for Old and New NPA at Start of PDP.    processingFailure_er   7761    No more than three related svs are allowed.    accessDenied_er   7762    With three related svs, one must be pooled in old, partial failed, failed or sending status.    accessDenied_er   7763    With three related svs, one must be pto.    accessDenied_er   7764    With three related svs, one must be non pto and non pooled.    accessDenied_er   7765    With two related svs, at least one must be non pto.    accessDenied_er   7766    With no related svs, the sv cannot be pto.    accessDenied_er   9000    Invalid date entered.    invalidAttributeValue_er   9001    Invalid time entered.    invalidAttributeValue_er   9002    Audit Profile name too long.    invalidAttributeValue_er   9003    Invalid TN data entered.    invalidAttributeValue_er   9004    Audit Profile name is not unique.    duplicateManagedObjectInstance   9005    No audits match the entered criteria.    invalidAttributeValue_er   9006    Could not cancel specified Audit(s)    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      19                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     9007    Audit validation failed.    invalidAttributeValue_er   9008    No LSMSs to audit.    invalidAttributeValue_er   9009    Need required event input data    invalidAttributeValue_er   9010    Failed to generate a unique name for a periodic audit.    invalidAttributeValue_er   9011    Failed to generate a discrepancy for an SV mismatch.    invalidAttributeValue_er   9012    Failed to issue query events.    invalidAttributeValue_er   9013    Starting Station > Ending Station Error    invalidAttributeValue_er   9014    CMIP bounced, which killed our query.    invalidAttributeValue_er   9015    We can’t use input data that conflicts with itself    invalidAttributeValue_er   9016    Failed to issue SP Notification events.    processingFailure_er   9017    Failed to retrieve allowable function mask    invalidAttributeValue_er   9018    Event Process failed    processingFailure_er   9019    Discrepancy created with invalid reason code.    invalidAttributeValue_er   9500    NPA does not exist in the NPAC SMS data.    invalidAttributeValue_er   9501    NPA NXX combination does not exist in the NPAC SMS data.    invalidAttributeValue_er   9750    No TNs found within the range entered.    noSuchObjectInstance   9751    No results have yet been reported for the selected audit.    invalidAttributeValue_er   10000    Invalid NPA data entered.    invalidAttributeValue_er   10001    Invalid NXX data entered.    invalidAttributeValue_er   10002    Invalid LRN data entered.    invalidAttributeValue_er   10003    Invalid range for NXXs (second must be greater than first).    invalidAttributeValue_er   10004    Invalid range for LRNs (second must be greater than first).    invalidAttributeValue_er   10005    Invalid printer name entered.    invalidAttributeValue_er   10006    Too many characters entered in printer field.    invalidAttributeValue_er   10007    Invalid TN entered in fax field.    processingFailure_er   10008    Too many characters entered in file name field.    invalidAttributeValue_er   10009    Invalid file name entered.    invalidAttributeValue_er   10010    No generated file name entered.    accessDenied_er   10011    No destination designated for report.    accessDenied_er   10012    Invalid date entered.    invalidAttributeValue_er   10013    Invalid parameters detected in Report Parameters.    invalidAttributeValue_er   10014    End date occurs before the start date.    invalidAttributeValue_er   10015    Requester does not have privileges to generate this report.    accessDenied_er   10016    Event missing customer ID    invalidAttributeValue_er   10017    No existing report or incorrect permissions    accessDenied_er   10018    Failure scanning existing report directory    accessDenied_er   10019    Failure opening existing report directory    accessDenied_er   10020    Failure retrieving originator information    accessDenied_er   10021    Failure printing report file    accessDenied_er   10022    Failure emailing report file    accessDenied_er   10023    Failure faxing report file    accessDenied_er   10024    Failure moving report file    accessDenied_er   10025    Failure renaming report file    accessDenied_er   10026    Failure running report    processingFailure_er   10750    No billing data exists for the entered criteria.    accessDenied_er   10751    Unknown report name for report id.    accessDenied_er   11000    Invalid date entered.    invalidAttributeValue_er   11001    Invalid printer name entered.    invalidAttributeValue_er   11002    Too many characters entered in printer field.    invalidAttributeValue_er   11003    Invalid TN entered in fax field.    processingFailure_er   11004    Too many characters entered in file name field.    invalidAttributeValue_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      20                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     11005    End date occurs before the start date.    invalidAttributeValue_er   11006    You cannot post date service element collection changes.    accessDenied_er   11007    Invalid file name entered.    invalidAttributeValue_er   11008    Incomplete Request Parameter Set.    accessDenied_er   11009    Invalid category for billing    invalidAttributeValue_er   11010    Invalid Multiplier Specified.    invalidAttributeValue_er   11011    Unable To Read Multiplier.    accessDenied_er   11500    Unable to connect to entered fax number.    accessDenied_er   12000    Oracle RDBMS has reported the following Database Server Error: ORA-nnnnn    accessDenied_er   12001    Oracle RDBMS has reported the following SQL Execution Error: ORA-nnnnn    accessDenied_er        Oracle RDBMS has reported the following Stored Procedure/Trigger Error:       12002    ORA-nnnnn    accessDenied_er   12003    Oracle RDBMS has reported the following Database Networking (SQL*NET) Error: ORA-nnnnn    accessDenied_er   12004    Oracle RDBMS has reported the following Replication Server Error ORA-nnnnn    accessDenied_er   12005    Oracle RDBMS has reported the following Report Writer Error: ORA nnnnn    accessDenied_er   12006    Oracle RDBMS database has been disconnected.    accessDenied_er   12110    Dispatcher found bad event    accessDenied_er   12120    Corrupt data found    accessDenied_er   12140    Resource Failure    processingFailure_er   12150    Hard (non-retryable) Resource Failure    processingFailure_er   13000    Housekeeping error    invalidAttributeValue_er   13001    Housekeeping tuna value error    accessDenied_er   13002    Invalid event subtype    accessDenied_er   13003    Tunable Not Found    accessDenied_er   13004    InvalidPurgeAction    accessDenied_er   14000    CMIP:Access Denied Error    accessDenied_er   14001    CMIP:Class Instance Conflict    classInstanceConflict   14002    CMIP:Complexity Limitation    complexityLimitation   14003    CMIP:Duplicate Managed Object Instance    duplicateManagedObjectInstance   14004    CMIP:GetListError    getListError_er   14005    CMIP:Invalid Argument Value    invalidArgumentValue_er   14006    CMIP:Invalid Attribute Value    invalidAttributeValue_er   14007    CMIP:Invalid Filter    invalidFilter   14008    CMIP:Invalid Scope    invalidScope   14009    CMIP:No Such Action    noSuchAction_er   14010    CMIP:No Such Argument    noSuchArgument_er   14011    CMIP:No Such Attribute    noSuchAttribute_er   14012    CMIP:No Such Object Class    noSuchObjectClass   14013    CMIP:No Such Object Instance    noSuchObjectInstance   14014    CMIP:Resource Limitation    invalidAttributeValue_er   14015    CMIP:Synch Not Supported    syncNotSupported   14016    CMIP process restarted    processingFailure_er   14017    CMIP:Sap Create failure    processingFailure_er   14018    CMIP:Processing failure    processingFailure_er   14019    CMIP:Bind Error    processingFailure_er   14020    CMIP:Received Unexpected Message    processingFailure_er                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      21                   Appendix A: Errors                    SMS Error   Error Description   CMIP Error     14021    CMIP:Retrieve Attribute Failed    processingFailure_er   14022    CMIP:Invalid Data Type    processingFailure_er   14023    CMIP:Invalid Message Type    processingFailure_er   14024    CMIP:Invalid Attribute    noSuchAttribute_er   14025    CMIP:No Existing Event    noSuchEventType   14026    CMIP:SetListError    setListError_er   14027    CMIP:DeleteListError    processingFailure_er   14028    CMIP:Invalid Error Mapping    processingFailure_er   14029    CMIP:Invalid Object Instance    invalidObjectInstance   14030    CMIP:Missing Attribute Value    missingAttributeValue   14031    CMIP:Mistyped Operation    mistypedOperation   14032    CMIP:No Such Reference Object    noSuchReferenceObject   14033    CMIP:Operation Canceled    operationCancelled   14034    CMIP:No Such Invoke ID    noSuchInvokeId   14035    NPAC:Sending Abort    accessDenied_er   14036    NPAC:Received Abort    operationCancelled                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      22                   Appendix B: Message Flow Diagrams    Appendix B. Flow Diagrams  [Graphic Omitted: Appendix B]          B.1   Overview    This appendix defines the message flow scenarios for the SOA to NPAC and the NPAC SMS to Local SMS interfaces. Each of these definitions consists of a message flow diagram and a textual description of the diagram.   IMPORTANT NOTES  The order of messages in the message flows must be followed by the NPAC SMS SOA and LSMS systems with the exception of the return of the M-EVENT-REPORT confirmations.   The following is an example message flow diagram and legend for elements shown in the diagram.  [Graphic Omitted: an example message flow diagram and legend ]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      23                   Appendix B: Message Flow Diagrams    Audit Scenarios          B.1.1   SOA Initiated Audit    [Graphic Omitted: SOA Initiated Audit]  In this scenario, the SOA initiates an audit to the NPAC SMS due to suspected subscription version discrepancies. This scenario applies to non-pooled subscription versions only.  Action is taken by SOA personnel to start an audit due to suspected network discrepancies.     1.   The SOA sends a M-CREATE request to the NPAC SMS, requesting an audit. The SOA must specify the following attributes in the request:    subscriptionAuditName – unique English audit name  subscriptionAuditRequestingSP - the service provider requesting the audit  subscriptionAuditServiceProvIdRange - which service provider or all service providers for audit  subscriptionAuditTN-Range - TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.  If these attributes are not specified, then the create will fail with a missingAttributesValue error. The SOA may also specify the following attributes in the request:  subscriptionAuditAttributeList - subscription version attributes to be audited  subscriptionAuditTN-ActivationRange - time range of activation for subscription versions to be audited  The subscriptionAuditId and the subscriptionAuditStatus will be determined by the NPAC SMS. If any values are deemed invalid, an invalidArgumentValue error will be returned. Once the NPAC SMS creates the audit request object, it sends an M-CREATE response back to the SOA that initiated the request.     2.   NPAC SMS responds to M-CREATE.      3.   NPAC SMS sends M-EVENT-REPORT to the service provider SOA for the subscriptionAudit creation.      4.   The service provider SOA confirms the M-EVENT-REPORT.    NPAC SMS begins audit.     5.   NPAC SMS issues a scoped and filtered M-GET for the subscription versions in the audit, to all LSMSs accepting downloads for the NPA-NXX of the subscription version.      6.   Local SMS returns M-GET query data.    NPAC SMS performs the necessary comparisons of each subscription version object.     7.   If a discrepancy is found, NPAC SMS issues a subscriptionAudit-DiscrepancyRpt M-EVENT-REPORT.      8.   Service provider SOA confirms the M-EVENT-REPORT.    If a discrepancy is found, NPAC SMS issues the necessary operation to the Local SMS to correct the discrepancy (M-CREATE, M-DELETE, or M-SET).  Flow Continues under B.2.1.1.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      24                   Appendix B: Message Flow Diagrams            B.1.1.1   SOA Initiated Audit (continued)    [Graphic Omitted: SOA Initiated Audit (continued)]     1.   If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).      2.   The service provider SOA confirms the M-EVENT-REPORT.      3.   If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).      4.   The old service provider SOA confirms the M-EVENT-REPORT.    NPAC SMS has completed the audit comparisons and corrections.     5.   NPAC SMS issues the subscriptionAuditResults M-EVENT-REPORT to the service provider SOA.      6.   The Service provider SOA confirms the M-EVENT-REPORT.      7.   The NPAC SMS then sends an objectDeletion M-EVENT-REPORT to the SOA for the subscriptionAudit object.      8.   The service provider SOA confirms the M-EVENT-REPORT.      9.   The NPAC SMS issues a local M-DELETE request (housekeeping activity) for the subscriptionAudit object to/from the NPAC SMS. This will schedule the deletion of the subscriptionAudit object on the NPAC SMS. The M-DELETE does not occur until after the “Audit Log Retention Period” which defaults to 90 days.      10.   The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      25                   Appendix B: Message Flow Diagrams            B.1.2   SOA Initiated Audit Cancellation by the SOA    The SOA cancels an audit that it initiated.  [Graphic Omitted: SOA Initiated Audit Cancellation by the SOA]  Action is taken by SOA personnel to cancel an audit previously initiated by the SOA.     1.   The SOA sends an M-DELETE request for the subscriptionAudit object to the NPAC SMS, requesting cancellation of an audit. If the audit was not initiated by the SOA requesting cancellation, then the request will be rejected with an accessDenied error.      2.   The NPAC SMS issues an M-DELETE Response.      3.   The NPAC SMS issues an M-EVENT-REPORT objectDeletion to the SOA.      4.   The SOA issues an M-EVENT-REPORT Confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      26                   Appendix B: Message Flow Diagrams            B.1.3   SOA Initiated Audit Cancellation by the NPAC    The NPAC cancels an audit that was initiated by an SOA.  [Graphic Omitted: SOA Initiated Audit Cancellation by the NPAC]  Action is taken by NPAC personnel to cancel an audit previously initiated by an SOA.     1.   The NPAC SMS sends an objectDeletion M-EVENT-REPORT to the SOA that initiated the audit request.      2.   The SOA confirms the M-EVENT-REPORT      3.   The NPAC SMS issues a local M-DELETE request (housekeeping activity) to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.      4.   The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      27                   Appendix B: Message Flow Diagrams            B.1.4   NPAC Initiated Audit    In this scenario, the NPAC SMS initiates an audit due to suspected subscription version discrepancies. This scenario applies to non-pooled subscription versions only.  [Graphic Omitted: NPAC Initiated Audit]  Action is taken by NPAC personnel to start an audit due to suspected network discrepancies.     1.   The NPAC SMS does a Local M-CREATE request to itself for the subscriptionAudit object requesting an audit. The following attributes must be included in the request:    subscriptionAuditName – unique English audit name  subscriptionAuditServiceProvIdRange - which service provider or all service providers for audit  subscriptionAuditTN-Range - TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.  If these attributes are not specified, then the create will fail with a missingAttributesValue error. The following attributes may also be included the request:  subscriptionAuditAttributeList — subscription version attributes to be audited  subscriptionAuditTN-ActivationRange — time range of activation for subscription versions to be audited     2.   The NPAC SMS responds with an M-CREATE response indicating that the subscriptionAudit object was created successfully.      3.   The NPAC SMS sends an M-GET request to the Local SMSs to retrieve the subscription data to use for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited.      4.   The Local SMS responds to the M-GET request by returning the subscription data that satisfies the scope and filter data.    NPAC SMS performs the comparisons.  If any discrepancies are found, the NPAC SMS will perform the necessary fix to the Local SMS.     5.   If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).       6.   The old service provider SOA confirms the M-EVENT-REPORT.       7.   If any corrections were issued to any Local SMSs, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus any recently updated Local SMSs that no longer contains a discrepancy).                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      28                   Appendix B: Message Flow Diagrams       8.   The new service provider SOA confirms the M-EVENT-REPORT.    NPAC SMS completes the audit.     9.   Issue a local M-DELETE request (housekeeping activity) for the subscriptionAudit object to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS. The M-DELETE does not occur until after the “Audit Log Retention Period” which defaults to 90 days.       10.   The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      29                   Appendix B: Message Flow Diagrams            B.1.5   NPAC Initiated Audit Cancellation by the NPAC    The NPAC SMS cancels an audit that it initiated.  [Graphic Omitted: NPAC Initiated Audit Cancellation by the NPAC]  Action is taken by NPAC personnel to cancel an audit previously initiated by the NPAC SMS.     1.   Issue a local M-DELETE request (housekeeping activity) to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.       2.   The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      30                   Appendix B: Message Flow Diagrams            B.1.6   Audit Query on the NPAC    This scenario shows a service provider query on an existing audit that it initiated.  [Graphic Omitted: Audit Query on the NPAC]  The service provider SOA takes action to query an audit that it initiated.     1.   Service provider SOA sends an M-GET request for a subscriptionAudit on the NPAC SMS.       2.   NPAC SMS responds to an M-GET with the audit data or a failure and reason for failure. An accessDenied error will be returned to the service provider if they did not originate the audit queried.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      31                   Appendix B: Message Flow Diagrams            B.1.7   SOA Audit Create for Subscription Versions within a Number Pool Block (previously NNP flow 6.1)    In this scenario, the SOA initiates the audit of one or more subscription versions that are within the range of a number pool block. For non-EDR Local SMSs, this involves the subscription version objects. For EDR Local SMSs, this involves both subscription version objects and number pool block objects.  If discrepancies are found, the NPAC SMS will create, modify or delete subscription version and number pool objects, as necessary. The NPAC SMS will report to the SOA the discrepancies with subscription version identifiers. Thus, if a numberPoolBlock object is in error, the discrepancy will be reported as all TNs within the audit range that were also within the block range. However, in this case where an EDR Local SMS erroneously contains a Number Pool Block, the NPAC SMS will send a Number Pool Block delete to the Local SMS, but will not report any discrepancy back to the requesting SOA for this Local SMS if this was the only discrepancy. Subscription version discrepancies will be reported as usual.          B.1.7.1   SOA Creates and NPAC SMS Starts Audit (previously NNP flow 6.1.1)    [Graphic Omitted: SOA Creates and NPAC SMS Starts Audit ]  Action is taken by SOA personnel to start an audit due to suspected network discrepancies.     1.   The SOA sends an M-CREATE request to the NPAC SMS requesting an audit. The SOA must specify the following attributes in the request:    subscriptionAuditName – unique English audit name  subscriptionAuditRequestingSP – the service provider requesting the audit  subscriptionAuditServiceProvIdRange – which service provider or all service providers for audit  subscriptionAuditTN-Range – TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.  If these attributes are not specified, then the create will fail with a missingAttributeValue error. The SOA may also specify the following attributes in the request:  subscriptionAuditAttributeList – subscription version attributes to be audited  subscriptionAuditTN-ActivationRange – time range of activation for subscription versions to be audited.  The subscriptionAuditId and the subscriptionAuditStatus will be determined by the NPAC SMS. If any values are deemed invalid, an invalidArgumentValue error will be returned.     2.   Once the NPAC SMS creates the audit request object, it sends an M-CREATE response back to the SOA that initiated the request.      3.   NPAC SMS sends M-EVENT-REPORT to the service provider SOA for the subscriptionAudit creation.      4.   The service provider SOA confirms the M-EVENT-REPORT.    NPAC SMS begins audit.     5.   The NPAC SMS sends an M-GET request to the non-EDR Local SMS to retrieve the subscription data for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited.       6.   The non-EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter data.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      32                   Appendix B: Message Flow Diagrams       7.   The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the number pool block for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the numberPoolBlock objects to be audited.       8.   The EDR Local SMS responds to the M-GET request by returning the number pool object block requested.       9.   The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the subscription version objects for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited. No subscription versions with a LNP type of ‘pool’ should exist.       10.   The EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter criteria.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      33                   Appendix B: Message Flow Diagrams            B.1.7.2   NPAC SMS Performs Audit Comparisons for a SOA initiated Audit including a Number Pool Block (previously NNP flow 6.1.2)    The SOA has sent in the audit request and the NPAC SMS had queried for the necessary data. The NPAC SMS now performs the necessary comparisons.  [Graphic Omitted: NPAC SMS Performs Audit Comparisons for a SOA initiated Audit including a Number Pool Block]  The NPAC SMS performs object comparisons. The next 4 items apply to each discrepancy.     1.   If a discrepancy is found, NPAC SMS issues a subscriptionAudit-DiscrepancyRpt M-EVENT-REPORT.      2.   Service provider SOA confirms the M-EVENT-REPORT.          NPAC SMS performs necessary operations to fix each discrepancy on Local SMS. If any subscription versions with a LNP type of ‘pool’ are returned by the EDR Local SMS, they will be deleted and discrepancies reported.      3.   If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of an activated subscription version, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus and a list of failed Local SMSs (minus any updated Local SMSs that no longer contains a discrepancy).      4.   The old service provider SOA confirms the M-EVENT-REPORT.      5.   If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of a subscription version, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the status and a list of failed Local SMSs (minus any updated Local SMSs that no longer contains a discrepancy).      6.   The current service provider SOA confirms the M-EVENT-REPORT.      7.   If any corrections were issued to any Local SMSs that changed the status or numberPoolBlockFailed-SP-List of a number pool block, either by correcting a number pool block or subscription version with LNP type equal to ‘pool’, the numberPoolBlockStatusAttributeValueChange will be sent to the block holder SOA if the numberPoolBlockSOA-Origination indicator is set to “TRUE”. The M-EVENT-REPORT will contain the numberPoolBlockStatus and numberPoolBlockFailed-SP-List.      8.   The block holder service provider confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      34                   Appendix B: Message Flow Diagrams    B.1.7.3 NPAC SMS Reports Audit Results (previously NNP flow 6.1.3)  The NPAC SMS has completed the audit. It has reported and fixed all discrepancies found. It now sends the final results to the SOA.  [Graphic Omitted: NPAC SMS Reports Audit Results]  Audit comparisons and fixes are complete.     1.   NPAC SMS issues the subscriptionAuditResults M-EVENT-REPORT to the service provider SOA.      2.   The service provider SOA confirms the M-EVENT-REPORT.      3.   The NPAC SMS then sends an objectDeletion M-EVENT-REPORT to the SOA for the subscriptionAudit object.      4.   The service provider SOA confirms the M-EVENT-REPORT.      5.   The NPAC SMS issues a local M-DELETE request (housekeeping activity) for the subscriptionAudit object to/from the NPAC SMS. This will attempt to delete the subscriptionAudit object on the NPAC SMS.      6.   The M-DELETE response is received on the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      35                   Appendix B: Message Flow Diagrams    B.1.8 NPAC SMS Audit Create for Subscription Versions Within a Number Pool Block (previously NNP flow 6.2)  In this scenario, the NPAC SMS initiates an audit due to suspected subscriber data discrepancies. For non-EDR Local SMSs, this involves the subscription version objects. For EDR Local SMSs, this involves both subscription version objects and number pool block objects.  If discrepancies are found, the NPAC SMS will create, modify or delete subscription version and number pool objects, as necessary.  B.1.8.1 NPAC SMS Creates and Starts Audit (previously NNP flow 6.2.1)  [Graphic Omitted: NPAC SMS Creates and Starts Audit]  Action is taken by NPAC personnel to start an audit due to suspected network discrepancies.     1.   The NPAC SMS does a Local M-CREATE request for the subscriptionAudit object. The following attributes must be included in the request:    subscriptionAuditName – unique English audit name  subscriptionAuditServiceProvIdRange – which service provider or all service providers for audit  subscriptionAuditTN-Range – TNs to be audited. If only a single TN is to be audited, specify the ending TN station equal to the starting TN station.         If these attributes are not specified, then the create will fail with a missingAttributeValue error. The following attributes may also be included the request:    subscriptionAuditAttributeList – subscription version attributes to be audited  subscriptionAuditTN-ActivationRange – time range of activation for subscription versions to be audited.     2.   The NPAC SMS responds with an M-CREATE response indicating that the subscriptionAudit was created successfully.    NPAC SMS begins audit.     3.   The NPAC SMS sends an M-GET request to the non-EDR Local SMS to retrieve the subscription data for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited.       4.   The non-EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter data.       5.   The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the number pool block for audit processing.       6.   The EDR Local SMS responds to the M-GET request by returning the number pool object block requested.       7.   The NPAC SMS sends an M-GET request to the EDR Local SMS to retrieve the subscription version objects for audit processing. The request uses the CMIP scoping and filtering options to retrieve only the subscriptionVersion objects to be audited. No subscription versions with a LNP type of ‘pool’ should exist.       8.   The EDR Local SMS responds to the M-GET request by returning the subscription version objects that satisfy the scope and filter criteria.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      36                   Appendix B: Message Flow Diagrams            B.1.8.2   NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block (previously NNP flow 6.2.2)    The NPAC SMS has queried for the required data and now proceeds to perform the audit comparisons.  [Graphic Omitted: NPAC SMS Performs Audit Comparisons for NPAC initiated Audit including a Number Pool Block ]  NPAC SMS performs object comparisons.  NPAC SMS performs necessary operations to each fix discrepancy on Local SMS. If any subscription versions with a LNP type of ‘pool’ are returned by the EDR Local SMS, they will be deleted and discrepancies reported.     1.   If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of an activated subscription version, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA with the subscriptionVersionStatus and a list of failed Local SMSs (minus any updated Local SMSs that no longer contain a discrepancy).      2.   The old service provider SOA confirms the M-EVENT-REPORT.       3.   If any corrections were issued to any Local SMSs that changed the status or subscriptionFailed-SP-List of a subscription version, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the subscriptionVersionStatus and a list of failed Local SMSs (minus any updated Local SMSs that no longer contain a discrepancy).      4.   The current service provider SOA confirms the M-EVENT-REPORT.       5.   If any corrections were issued to any Local SMSs that changed the status or numberPoolBlockFailed-SP-List of a number pool block, either by correcting a number pool block or subscription version with LNP type equal to ‘pool’, the numberPoolBlockStatusAttributeValueChange will be sent to the block holder SOA if the numberPoolBlockSOA-Origination indicator is set to “TRUE”. The M-EVENT-REPORT will contain the numberPoolBlockStatus and numberPoolBlockFailed-SP-List.      6.   The block holder service provider confirms the M-EVENT-REPORT.       7.   The NPAC SMS issues an M-DELETE request (housekeeping activity) to remove the subscriptionAudit object from the NPAC SMS.       8.   The NPAC SMS response is received by the NPAC SMS indicating whether the subscriptionAudit object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      37                   Appendix B: Message Flow Diagrams    B.2 Service Provider Scenarios  B.2.1 Service Provider Creation by the NPAC  In this scenario, the NPAC SMS creates data for a new LNP service provider. The addition of NPA-NXX and LRN data for a new service provider will be shown in flows that follow.  [Graphic Omitted: Service Provider Creation by the NPAC]  Action is taken by NPAC SMS personnel to create a new service provider.     1.   Issue a local M-CREATE request for the serviceProv object to/from the NPAC SMS. This will attempt to create the serviceProv object on the NPAC SMS. If the M-CREATE fails, the appropriate error will be returned.       2.   The M-CREATE response is received on the NPAC SMS indicating whether the serviceProv object was created successfully. If a failure occurs, processing will stop.       3.   Issue a local M-CREATE request for the serviceProvNetwork object to/from the NPAC SMS. This will attempt to create the serviceProvNetwork object on the NPAC SMS. If the M-CREATE fails, the appropriate error will be returned.       4.   The M-CREATE response is received on the NPAC SMS indicating whether the serviceProvNetwork object was created successfully. If the object cannot be created, the serviceProv object is deleted and an error is returned.       5.   The NPAC SMS sends an M-CREATE request for the serviceProvNetwork object to each of the Local SMS(s).      6.   The Local SMS(s) will respond by sending an M-CREATE response back to the NPAC SMS.       7.   The NPAC SMS sends an M-CREATE request for the serviceProvNetwork object to each of the SOA(s).      8.   The SOA(s) will respond by sending an M-CREATE response back to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      38                   Appendix B: Message Flow Diagrams    B.2.2 Service Provider Deletion by the NPAC  In this scenario, the NPAC SMS deletes data for an LNP service provider with no network data.  [Graphic Omitted: Service Provider Deletion by the NPAC]  Action is taken by NPAC SMS personnel to delete an existing service provider.  Check the database to see if the service provider has associated with it NPA-NXX data, LRN data, or subscription versions with status other than old or canceled. If so, deny the request.     1.   Issue a local M-DELETE request for the serviceProv object to/from the NPAC SMS. This will attempt to delete the serviceProv object on the NPAC SMS.       2.   The M-DELETE response is received on the NPAC SMS indicating whether the serviceProv object was deleted successfully.       3.   If the serviceProv object was deleted, issue a local M-DELETE request for the serviceProvNetwork object to/from the NPAC SMS. This will attempt to delete the serviceProvNetwork object on the NPAC SMS.       4.   The M-DELETE response is received on the NPAC SMS indicating whether the serviceProvNetwork object was deleted successfully.       5.   If the serviceProvNetwork object was deleted, the NPAC SMS sends an M-DELETE request for the serviceProvNetwork object to each of the Local SMS(s).       6.    The Local SMS(s) will respond by sending an M-DELETE response back to the NPAC SMS.      7.   If the serviceProvNetwork object was deleted, the NPAC SMS sends an M-DELETE request for the serviceProvNetwork object to each of the SOA(s).      8.   The SOA(s) will respond by sending an M-DELETE response back to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      39                   Appendix B: Message Flow Diagrams    B.2.3 Service Provider Modification by the NPAC  In this scenario, the NPAC SMS modifies the LNP service provider data.  [Graphic Omitted: Service Provider Modification by the NPAC]  Action is taken by the NPAC personnel to modify data for an existing service provider.     1.   Issue a local M-SET request for the serviceProv object to/from the NPAC SMS. This will attempt to set the specified information on the NPAC SMS.       2.   Validate the data to be set in the M-SET request. An M-SET Error Response of invalidArgumentValue is returned if any data is deemed invalid. The M-SET response is received on the NPAC SMS indicating whether the serviceProv object was modified successfully.    If the serviceProvNetworkName or ServiceProviderType changed, perform the next 4 steps:     3.   Issue a local M-SET request for the serviceProvNetwork object to/from the NPAC SMS. This will attempt to set the specified information on the NPAC SMS.       4.   Validate the data to be set in the M-SET request. An M-SET Error Response of invalidArgumentValue is returned if any data is deemed invalid. The M-SET response is received on the NPAC SMS indicating whether the serviceProvNetwork object was modified successfully.       5.   NPAC SMS performs an M-SET for the serviceProvNetwork to all the Local SMS(s) if the service provider name or service provider type changed.       6.    The Local SMS(s) respond.       7.   NPAC SMS performs an M-SET for the service ProvNetwork to all the SOA(s) if the service provider name or service provider type changed.      8.   The SOA(s) respond.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      40                   Appendix B: Message Flow Diagrams    B.2.4 Service Provider Modification by the Local SMS  In this scenario, the Local SMS modifies its own service provider data.  [Graphic Omitted: Service Provider Modification by the Local SMS]  Action is taken by the Local SMS personnel to modify their own service provider data.     1.   The Local SMS sends an M-SET request to the NPAC SMS to modify their service provider information.          The NPAC SMS verifies that the service provider to be modified is owned by the service provider that initiated the request. If not, an access denied M-SET Error Response of invalidArgumentValue is returned.          Validate the data to be set in the M-SET request. An invalidArgumentValue M-SET Error Response is returned if any data is deemed invalid.      2.   The NPAC SMS sends an M-SET response back to the Local SMS that initiated the request                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      41                   Appendix B: Message Flow Diagrams    B.2.5 Service Provider Modification by the SOA  In this scenario, the SOA modifies its own service provider data.  [Graphic Omitted: Service Provider Modification by the SOA]  Action is taken by the SOA to modify their own service provider data.     1.   The SOA sends an M-SET request to the NPAC SMS to modify their service provider information.          The NPAC SMS verifies that the service provider to be modified is owned by the service provider that initiated the request. If not, an access denied M-SET Error Response is returned.          Validate the data to be set in the M-SET request. An invalidArgumentValue M-SET Error Response is returned if any data is deemed invalid.      2.   The NPAC SMS sends an M-SET response back to the SOA that initiated the request.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      42                   Appendix B: Message Flow Diagrams    B.2.6 Service Provider Query by the Local SMS  In this scenario, the Local SMS queries their own service provider data.  [Graphic Omitted: Service Provider Query by the Local SMS]  Action is taken by the Local SMS personnel to query their own service provider data.     1.   The Local SMS sends an M-GET request to the NPAC SMS requesting their own service provider information.          The NPAC SMS verifies that the service provider information to be retrieved is owned by the service provider that initiated the request. If not, an M-GET Error Response of accessDenied is returned if the two service providers do not match.      2.   The NPAC SMS sends an M-GET response containing the requested service provider information back to the Local SMS or SOA that initiated the request.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      43                   Appendix B: Message Flow Diagrams    B.2.7 Service Provider Query by the SOA  In this scenario, the SOA queries their own service provider data.  [Graphic Omitted: Service Provider Query by the SOA]  Action is taken by the SOA or SOA personnel to query their own service provider data.     1.   The SOA sends an M-GET request to the NPAC SMS requesting their own service provider information.          The NPAC SMS verifies that the service provider information to be retrieved is owned by the service provider that initiated the request. If not, an M-GET error response of accessDenied is returned if the two service providers do not match.       2.   The NPAC SMS sends an M-GET response containing the requested service provider information back to the SOA that initiated the request.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      44                   Appendix B: Message Flow Diagrams    B.3 Service Provider Network Data Scenarios  B.3.1 NPA-NXX Scenarios  B.3.1.1 NPA-NXX Creation by the NPAC  In this scenario, NPAC SMS creates new NPA-NXX data for an LNP service provider.  [Graphic Omitted: NPA-NXX Creation by the NPAC]  Action is taken by the NPAC Personnel to create an NPA-NXX for a specified service provider.     1.   The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvNPA-NXX object.       2.   The NPAC SMS receives the M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.       3.   If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       4.   The Local SMS(s) respond by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.       5.   If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       6.   The SOA(s) respond by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      45                   Appendix B: Message Flow Diagrams    B.3.1.2 NPA-NXX Deletion by the NPAC  In this scenario, NPAC SMS deletes an NPA-NXX for an LNP service provider.  [Graphic Omitted: NPA-NXX Deletion by the NPAC]  Action is taken by NPAC SMS personnel to delete an NPA-NXX for a specified service provider.     1.   The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvNPA-NXX object.          Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” or “canceled.” Also, check if any NPA-NXX-Xs exist with this NPA-NXX. If so, respond with an error and terminate processing at this point.       2.   The NPAC SMS receives the M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.       3.   If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       4.   The Local SMS(s) responds by sending an M-DELETE response to the NPAC SMS indicating whether the serviceProvNPA-NXX object was deleted successfully.       5.   If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       6.   The SOA(s) responds by sending an M-DELETE response to the NPAC SMS indicating whether the serviceProvNPA-NXX object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      46                   Appendix B: Message Flow Diagrams    B.3.1.3 NPA-NXX Creation by the Local SMS  In this scenario, the Local SMS creates a new NPA-NXX for its own service provider network data.  [Graphic Omitted: NPA-NXX Creation by the Local SMS]  Action is taken by the Local SMS personnel to create an NPA-NXX available for porting in their own service provider network.     1.   The Local SMS sends an M-CREATE request to the NPAC requesting that an NPA-NXX object be created for their own service provider network.          The NPAC SMS verifies that the service provider creating the NPA-NXX information is the same as the service provider that owns the network data. If not, then an access denied M-CREATE accessDenied Error Response is returned.       2.   The NPAC SMS responds by sending an M-CREATE response to the Local SMS that initiated the request indicating whether the serviceProvNPA-NXX object was created successfully.       3.   If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       4.   The Local SMS(s) responds by sending an M-CREATE Response indicating whether the serviceProvNPA-NXX object was created successfully.       5.   If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       6.   The SOA(s) responds by sending an M-CREATE Response indicating whether the serviceProvNPA-NXX object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      47                   Appendix B: Message Flow Diagrams    B.3.1.4 NPA-NXX Creation by the SOA  In this scenario, the SOA creates a new NPA-NXX for its own service provider network data.  [Graphic Omitted: NPA-NXX Creation by the SOA]  Action is taken by the SOA personnel to create an NPA-NXX available for porting in their own service provider network.     1.   The SOA sends an M-CREATE request to the NPAC requesting that an NPA-NXX object be created for their own service provider network.          The NPAC SMS verifies that the service provider creating the NPA-NXX information is the same as the service provider that owns the network data. If not, then an access denied M-CREATE response is returned to the SOA that initiated the request.      2.   The NPAC SMS sends an M-CREATE response back to the SOA for the serviceProvNPA-NXX object.       3.   If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       4.   The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.       5.   If the serviceProvNPA-NXX object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       6.   The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvNPA-NXX object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      48                   Appendix B: Message Flow Diagrams    B.3.1.5 NPA-NXX Deletion by the Local SMS  In this scenario, the Local SMS deletes an NPA-NXX in its own service provider network data.  [Graphic Omitted: NPA-NXX Deletion by the Local SMS]  Action is taken by the Local SMS personnel to delete an NPA-NXX for their own service provider network data.     1.   The Local SMS sends an M-DELETE request to the NPAC SMS requesting that an NPA-NXX object be deleted for their own service provider.          The NPAC SMS verifies that the service provider that owns the NPAC-NXX information to be deleted is the same as the service provider that owns the network data. If not, then an M-DELETE accessDenied error response is returned.          Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” without a Failed SP List or canceled.” Also, check if any NPA-NXX-Xs or Number Pool Blocks exist with this NPA-NXX. If so, terminate processing at this point.       2.   The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.       3.   If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       4.   The Local SMS(s) responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.       5.   If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       6.   The SOA(s) responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      49                   Appendix B: Message Flow Diagrams    B.3.1.6 NPA-NXX Deletion by SOA  In this scenario, the SOA deletes a new NPA-NXX for its own service provider network data.  [Graphic Omitted: NPA-NXX Deletion by SOA]  Action is taken by the SOA personnel to delete an NPA-NXX for their own service provider network data.     1.   The SOA sends an M-DELETE request to the NPAC SMS requesting that an NPA-NXX object be deleted for their own service provider.          The NPAC SMS verifies that the service provider that owns the NPA-NXX information to be deleted is the same as the service provider that owns the network data. If not, then an M-DELETE accessDenied Error Response is returned.          Check the subscriptions database to see if subscriptions exist with this NPA-NXX that have a status other than “old” or “canceled.” Also, check if any NPA-NXX-Xs or Number Pool Blocks exist with this NPA-NXX. If so, terminate processing at this point.       2.   The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.       3.   If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       4.   The Local SMS(s) respond by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully.       5.   If the serviceProvNPA-NXX object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) accepting downloads for the NPA-NXX for the serviceProvNPA-NXX object.       6.   The SOA(s) respond by sending an M-DELETE response indicating whether the serviceProvNPA-NXX object was deleted successfully                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      50                   Appendix B: Message Flow Diagrams    B.3.1.7 NPA-NXX Query by the Local SMS  In this scenario, the Local SMS queries for NPA-NXX data.  [Graphic Omitted: NPA-NXX Query by the Local SMS]  Action is taken by Local SMS personnel to query for a serviceProvNPA-NXX.     1.   The Local SMS sends an M-GET request to the NPAC SMS for the serviceProvNPA-NXX object.       2.   The NPAC SMS responds by sending an M-GET response containing the NPA-NXX data back to the Local SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      51                   Appendix B: Message Flow Diagrams    B.3.1.8 NPA-NXX Query by the SOA  In this scenario, the SOA queries for NPA-NXX updates.  [Graphic Omitted: NPA-NXX Query by the SOA]  Action is taken by SOA personnel to query for a serviceProvNPA-NXX.     1.   The SOA sends an M-GET request to the NPAC SMS for the serviceProvNPA-NXX object.       2.   The NPAC SMS responds by sending an M-GET response containing the NPA-NXX data back to the SOA.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      52                   Appendix B: Message Flow Diagrams    B.3.2 LRN Scenarios  B.3.2.1 LRN Creation by the NPAC  In this scenario, the NPAC SMS creates an LRN.  [Graphic Omitted: LRN Creation by the NPAC]  Action is taken by the NPAC personnel to create an LRN for an existing service provider.     1.   The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvLRN object.       2.   The NPAC SMS receives the M-CREATE response indicating whether the serviceProvLRN object was created successfully.       3.   If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) for the serviceProvLRN object.       4.   The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.       5.   If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) for the serviceProvLRN object.       6.   The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      53                   Appendix B: Message Flow Diagrams    B.3.2.2 LRN Creation by the SOA  In this scenario, the SOA creates an LRN for its own service provider network data.  [Graphic Omitted: LRN Creation by the SOA]  Action is taken by the SOA personnel to create an LRN for their own network data.     1.   The SOA sends an M-CREATE request to the NPAC SMS requesting that an LRN object be created for their own network data.          The NPAC SMS verifies that the service provider creating the LRN information is the same as the service provider that owns the service provider network data. If not, then an accessDenied M-CREATE Error Response is returned.       2.   The NPAC SMS responds by sending an M-CREATE response back to the SOA that initiated the request, indicating whether the serviceProvLRN object was created successfully.       3.   If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) for the serviceProvLRN object.       4.   The Local SMS(s) respond by sending an M-CREATE response indicating whether the service provider LRN object was created successfully.       5.   If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) for the serviceProvLRN object.       6.   The SOA(s) respond by sending an M-CREATE response indicating whether the service provider LRN object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      54                   Appendix B: Message Flow Diagrams    B.3.2.3 LRN Deletion by the SOA  In this scenario, the SOA deletes an LRN for their own service provider network data.  [Graphic Omitted: LRN Deletion by the SOA]  Action is taken by the SOA personnel to delete an LRN for their own network data.     1.   The SOA sends an M-DELETE request to the NPA requesting that an LRN object be deleted.          The NPAC SMS verifies that the service provider deleting the LRN information is the same as the service provider that is associated with the network data. If not, then an accessDenied M-DELETE error response is returned.          Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” without a Failed SP List or “canceled.” Also, check if any Number Pool Blocks exist with this LRN. If so, an M-SET error response complexity limitation is returned.       2.   The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.       3.   If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) for the serviceProvLRN object.       4.   The Local SMS(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.       5.   If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) for the serviceProvLRN object.       6.   The SOA(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.                          March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.    55                  Appendix B: Message Flow Diagrams    B.3.2.4 LRN Query by the SOA  In this scenario, the SOA queries LRN data.  [Graphic Omitted: LRN Query by the SOA]  Action is taken by SOA personnel to an LRN for a specified service provider.     1.   The SOA sends an M-GET request to the NPAC SMS for the serviceProvLRN object.      2.   The NPAC SMS responds by sending an M-GET response containing the data back to the SOA.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      56                   Appendix B: Message Flow Diagrams    B.3.2.5 LRN Deletion by the NPAC  In this scenario, the NPAC SMS deletes an LRN.  [Graphic Omitted: LRN Deletion by the NPAC]  Action is taken by the NPAC SMS personnel to delete an LRN for a service provider.     1.   The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvLRN object.          Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” Also, check if any Number Pool Blocks exist with this LRN. If so, terminate processing at this point.       2.   The NPAC SMS receives the M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.       3.   If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) for the serviceProvLRN object.       4.   The Local SMS(s) responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.       5.   If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) for the serviceProvLRN object.       6.   The SOA(s) responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      57                   Appendix B: Message Flow Diagrams    B.3.2.6 LRN Creation by the Local SMS  In this scenario, the Local SMS creates an LRN for its own service provider network data.  [Graphic Omitted: LRN Creation by the Local SMS]  Action is taken by the Local SMS personnel to create an LRN for their own network data.     1.   The SMS sends an M-CREATE request to the NPAC requesting that an LRN object be created for their own network data.          The NPAC verifies that the service provider creating the LRN information is the same as the service provider that owns the service provider network data. If not, then an accessDenied M-CREATE error response is returned.       2.   The NPAC SMS responds by sending an M-CREATE response back to the Local SMS that initiated the request, indicating whether the serviceProvLRN object was created successfully.       3.   If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all Local SMS(s) for the serviceProvLRN object.       4.   The Local SMS(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.       5.   If the serviceProvLRN object was created, the NPAC SMS sends an M-CREATE request to all SOA(s) for the serviceProvLRN object.       6.   The SOA(s) responds by sending an M-CREATE response indicating whether the serviceProvLRN object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      58                   Appendix B: Message Flow Diagrams    B.3.2.7 LRN Deletion by the Local SMS  In this scenario, the Local SMS deletes an LRN for their own service provider network data.  [Graphic Omitted: LRN Deletion by the Local SMS]  Action is taken by the Local SMS personnel to delete an LRN for their own network data.     1.   The Local SMS sends an M-DELETE request to the NPAC requesting that an LRN object be deleted.          The NPAC SMS verifies that the service provider deleting the LRN information is the same as the service provider that is associated with the network data. If not, then an accessDenied M-DELETE Error Response is returned.          Check the subscriptions database to see if subscriptions exist with this LRN that have a status other than “old” or “canceled.” Also, check if any Number Pool Blocks exist with this LRN. If so, an M-SET Error Response complexity limitation is returned.       2.   The NPAC SMS responds by sending an M-DELETE response indicating whether the serviceProvLRN object was deleted successfully.       3.   If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all Local SMS(s) for the serviceProvLRN object.       4.   The Local SMS(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.       5.   If the serviceProvLRN object was deleted, the NPAC SMS sends an M-DELETE request to all SOA(s) for the serviceProvLRN object.       6.   The SOA(s) responds by sending a message indicating whether the serviceProvLRN object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      59                   Appendix B: Message Flow Diagrams    B.3.2.8 LRN Query by the Local SMS  In this scenario, the Local SMS queries LRN data.  [Graphic Omitted: LRN Query by the Local SMS]  Action is taken by Local SMS personnel to query an LRN for a specified service provider.     1.   The Local SMS sends an M-GET request to the NPAC SMS for the serviceProvLRN object.      2.   The NPAC SMS responds by sending an M-GET response containing the data back to the Local SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      60                   Appendix B: Message Flow Diagrams    B.3.2.9 Network Data Download  DELETED. This scenario is superceded by the text and flows in section B.7, Local SMS and SOA Recovery.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      61                   Appendix B: Message Flow Diagrams    B.3.2.10 Scoped/Filtered GET of Network Data  This scenario shows a request for network data via a scoped/filtered M-GET. Scoping and filtering can be done from the serviceProvNetwork object.  [Graphic Omitted: Scoped/Filtered GET of Network Data]  Action is taken by the Local SMS personnel to request network data via a scoped/filtered M-GET request.     1.   The Local SMS sends a scoped/filtered M-GET request to the NPAC SMS.       2.   The NPAC SMS sends the first network data object (serviceProvNetwork) that passes the scope/filter criteria to the Local SMS that initiated the request.       3.   The NPAC SMS sends continues to send to the Local SMS all network data objects (serviceProvNetwork) that pass the scope/filter criteria.       4.   A final M-GET response is sent to the Local SMS that initiated the request once all scoped/filtered network objects have been returned, and will contain no data.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      62                   Appendix B: Message Flow Diagrams    B.3.2.11 Scoped/Filtered GET of Network Data from SOA  This scenario shows a request for network data via a scoped/filtered M-GET. Scoping and filtering is done from serviceProvNetwork.  [Graphic Omitted: Scoped/Filtered GET of Network Data from SOA]  Action is taken by the SOA personnel to request network data via a scoped/filtered M-GET request.     1.   The SOA sends a scoped/filtered M-GET request to the NPAC SMS.       2.   The NPAC SMS sends the first network data object (serviceProvNetwork, serviceProvNPA-NXX, serviceProvLRN, serviceProvNPA-NXX-X) that passes the scope/filter criteria to the SOA that initiated the request.       3.   The NPAC SMS continues to send to the SOA all network data objects object (serviceProvNetwork, serviceProvNPA-NXX, serviceProvLRN, serviceProvNPA-NXX-X) that pass the scope/filter criteria.       4.   A final M-GET response is sent to the SOA that initiated the request once all scoped/filtered network objects have been returned, and will contain no data.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      63                   Appendix B: Message Flow Diagrams       B.3.3 Service Provider NPA-NXX-X    This section contains the flows that demonstrate service provider NPA-NXX-X creation, modification, deletion and query.     B.3.3.1 Service Provider NPA-NXX-X Create by NPAC SMS (previously NNP flow 1.1)    In this scenario, the NPAC SMS creates the serviceProvNPA-NXX-X object at the request of the number pool administrator.  [Graphic Omitted: Service Provider NPA-NXX-X Create by NPAC SMS]  Action is taken by NPAC SMS personnel to create the serviceProvNPA-NXX-X object.     1.   The NPAC SMS sends an M-CREATE request to itself in order to create a local serviceProvNPA-NXX-X object. The NPAC SMS provides the following attributes:             serviceProvNPA-NXX-X-Value serviceProvNPA-NXX-X-EffectiveTimeStamp serviceProvID           The NPAC SMS validates the following:         •   NPA-NXX of the serviceProvNPA-NXX-X-value is an existing NPA-NXX.        •   The effective date is greater than or equal to the NPA-NXX Live TimeStamp.        •   The effective date is greater than or equal to the current date.        •   Verify no serviceProvNPA-NXX-X object exists with this NPA-NXX-X value.        •   The service provider ID is an existing service provider.           The NPAC SMS rejects the request if any subscriptionVersionNPAC objects exist with a status of pending, conflict, cancel-pending or failed for a TN specified by the serviceProvNPA-NXX-X-value and an active subscriptionVersionNPAC object does not exist for that TN or the subscription version is a Port-To-Original request.      2.   The NPAC SMS receives the M-CREATE request and sets the serviceProvNPA-NXX-X-ID, serviceProvNPA-NXX-X-CreationTimeStamp and serviceProvNPA-NXX-X-ModifiedTimeStamp. The NPAC SMS then issues a response indicating whether the serviceProvNPA-NXX-X object was successfully created.      3.   The NPAC SMS sends an M-CREATE request for the serviceProvNPA-NXX-X object to all Local SMSs who support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX. The following attributes are sent in the M-CREATE:             serviceProvNPA-NXX-X-ID serviceProvNPA-NXX-X-Value serviceProvNPA-NXX-X-CreationTimeStamp serviceProvNPA-NXX-X-EffectiveTimeStamp serviceProvNPA-NXX-X-ModifiedTimeStamp serviceProvNPA-NXX-X-DownloadReason       4.   The Local SMS responds by sending the M-CREATE response indicating whether the serviceProvNPA-NXX-X object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      64                   Appendix B: Message Flow Diagrams       5.   At the same time as step 3, the NPAC SMS sends an M-CREATE request for the serviceProvNPA-NXX-X object to all SOAs who support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX. The following attributes are sent in the M-CREATE:             serviceProvNPA-NXX-X-ID serviceProvNPA-NXX-X-Value serviceProvNPA-NXX-X-CreationTimeStamp serviceProvNPA-NXX-X-EffectiveTimeStamp serviceProvNPA-NXX-X-ModifiedTimeStamp serviceProvNPA-NXX-X-DownloadReason       6.   The SOA responds by sending the M-CREATE response indicating whether the serviceProvNPA-NXX-X object was created successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      65                   Appendix B: Message Flow Diagrams       B.3.3.1.1 Service Provider NPA-NXX-X Create by NPAC SMS (continued)    [Graphic Omitted: Service Provider NPA-NXX-X Create by NPAC SMS (continued)]         NPAC SMS decides if this NPA-NXX-X Create is the first use of the NPA-NXX.      1.   If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the accepting Local SMSs.      2.   The Local SMS confirms the M-EVENT-REPORT.      3.   The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the Current Service Provider SOA.      4.   The SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      66                   Appendix B: Message Flow Diagrams       B.3.3.2 Service Provider NPA-NXX-X Modification by NPAC SMS (previously NNP flow 1.2)    In this scenario, the NPAC SMS modifies the serviceProvNPA-NXX-X object at the request of the number pool administrator.  [Graphic Omitted: Service Provider NPA-NXX-X Modification by NPAC SMS]  Action is taken by NPAC SMS personnel to initiate a modification to the serviceProvNPA-NXX-X object.     1.   NPAC SMS sends the M-SET request to itself to update the following attributes:             serviceProvNPA-NXX-X-EffectiveTimeStamp serviceProvNPA-NXX-X-ModifiedTimeStamp       2.   NPAC SMS responds indicating whether the modification was successful. The update request will fail if the effective timestamp is less than the NPA-NXX Live TimeStamp or if the current date is greater than or equal to the object’s current effective timestamp.       3.   NPAC SMS sends the M-SET request to update the serviceProvNPA-NXX-X to all Local SMS that support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.       4.   At the same time as step 3, NPAC SMS sends the M-SET request to update the serviceProvNPA-NXX-X to all SOAs that support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.       5.   Local SMS respond to the M-SET indicating whether the modification was successful.      6.   SOA respond to the M-SET indicating whether the modification was successful.                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      67                   Appendix B: Message Flow Diagrams       B.3.3.3 Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence (previously NNP flow 1.3)    In this scenario, the NPAC SMS deletes the serviceProvNPA-NXX-X object at the request of the number pool administrator. This deletion takes place prior to the effective date or after the effective date, but prior to the number pool block object being created for the NPA-NXX-X value.  [Graphic Omitted: Service Provider NPA-NXX-X Deletion by NPAC SMS Prior to Number Pool Block Existence]  Action is taken by NPAC SMS personnel to delete a serviceProvNPA-NXX-X object.     1.   The NPAC SMS sends an M-DELETE request to itself in order to delete the local serviceProvNPA-NXX-X object.       2.   The NPAC SMS receives the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was successfully deleted.       3.   The NPAC SMS sends the M-DELETE request to all Local SMS for the serviceProvNPA-NXX-X object who support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.       4.   At the same time as step 3, the NPAC SMS sends the M-DELETE request to all SOAs for the serviceProvNPA-NXX-X object who support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS and are receiving data for the NPA-NXX.       5.   The Local SMS responds by sending the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was deleted successfully.       6.   The SOA responds by sending the M-DELETE response indicating whether the serviceProvNPA-NXX-X object was deleted successfully.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      68                   Appendix B: Message Flow Diagrams       B.3.3.4 Service Provider NPA-NXX-X Query by SOA or LSMS (previously NNP flow 1.4)    In this scenario, the service provider queries the NPAC SMS for one or more serviceProvNPA-NXX-X objects from the SOA or Local SMS.  [Graphic Omitted: Service Provider NPA-NXX-X Query by SOA or LSMS]  Service provider personnel take action to query the NPAC SMS for one or more serviceProvNPA-NXX-X objects.     1.   SOA or Local SMS sends an M-GET for a single serviceProvNPA-NXX-X object by serviceProvNPA-NXX-X-ID or a scope and filtered M-GET for one or more serviceProvNPA-NXX-X objects.       2.   If the NPAC SMS finds one or more serviceProvNPA-NXX-X objects that match the input criteria, the NPAC SMS responds with the single or linked reply of serviceProvNPA-NXX-X object(s). Otherwise it returns an empty result.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      69                   Appendix B: Message Flow Diagrams       B.3.4 Number Pool Block    This section contains the flows that demonstrate number pool block creation, modification and deletion.     B.3.4.1 Number Pool Block Create/Activate by SOA (previously NNP flow 2.1)    In this scenario, the block holder service provider sends in the M-ACTION for the number pool block to be created.  [Graphic Omitted: Number Pool Block Create/Activate by SOA]  Action is taken by the block holder service provider SOA to create a number pool block.     1.   The block holder service provider SOA sends the M-ACTION numberPoolBlock-Create to the NPAC SMS. The block holder service provider must provide the following attributes:             numberPoolBlockNPA-NXX-X numberPoolBlockLRN numberPoolBlockSPID numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN           If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes must be included:             numberPoolBlockWSMSC-DPC numberPoolBlockWSMSC-SSN           If the indicator is not set in the service provider’s profile, the WSMSC data cannot be included.           If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes must be included:             numberPoolBlockSVType           If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may optionally be included:             alternativeSPID           The NPAC SMS verifies the following and returns the indicated error if the condition fails:         •   The serviceProvNPA-NXX-X object exists for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is ‘no-npa-nxx-x-found’.        •   The service provider associated with the SOA is equal to the numberPoolBlockSPID and is owner of the corresponding serviceProvNPA-NXX-X object. If the condition fails, error returned is ‘soa-not-authorized’.                                  March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      70                   Appendix B: Message Flow Diagrams         •   All attributes are valid. If the condition fails, error returned is ‘invalid-data-values’.        •   A numberPoolBlockNPAC object does not already exist or one exists with a status of ‘old’ with an empty list of failed service providers for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is ‘number-pool-block-already-exists’.        •   The current date is greater than or equal to the serviceProvNPA-NXX-X-EffectiveTimeStamp of the corresponding serviceProvNPA-NXX-X object. If the condition fails, error returned is ‘prior-to-effective-date’.        •   There are no subscription version objects within the given TN range with a status of pending, conflict, cancel-pending or failed (“pending-like”) and no active subscription version for that TN. If the condition fails, error returned is ‘invalid-subscription-versions’.           Any other error will be returned as “failed”. If an error is found, the NPAC SMS returns the M-ACTION reply with the error. No further processing occurs.      2.   If the request is valid, the NPAC SMS creates the numberPoolBlockNPAC object. The numberPoolBlockSOA-Origination indicator is set to TRUE. The numberPoolBlockActivationTimeStamp, numberPoolBlockCreationTimeStamp, numberPoolBlockBroadcastTimeStamp and numberPoolBlockModifiedTimeStamp are set. The numberPoolBlockStatus is set to “sending”.      3.   The NPAC SMS responds to the M-CREATE.      4.   If the request is valid, the NPAC SMS will create the corresponding subscriptionVersionNPAC object(s). If an active, partial-failure, sending or disconnect-pending (“active-like”) subscription version exists within the block’s TN range, no new subscription version will be created for that TN. For the subscription versions created, the subscriptionLNPType will be set to ‘pool’, subscriptionVersionStatus will be set to “sending” and the subscriptionModifiedTimeStamp, subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionCreationTimeStamp will be set.      5.   The NPAC SMS will respond with the M-CREATE response.      6.   NPAC SMS responds to the M-ACTION.      7.   NPAC SMS sends the M-EVENT-REPORT objectCreation for the numberPoolBlockNPAC to the SOA. The following attributes will be sent in the objectCreation notification:             numberPoolBlockId numberPoolBlockSOA-Origination numberPoolBlockCreationTimeStamp numberPoolBlockStatus numberPoolBlockNPA-NXX-X numberPoolBlockSPID numberPoolBlockLRN numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN           If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes will be included:                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      71                   Appendix B: Message Flow Diagrams             numberPoolBlockWSMSC-DPC numberPoolBlockWSMSC-SSN           If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes will be included:             numberPoolBlockSVType           If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may optionally be included:             alternativeSPID       8.   The block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      72                   Appendix B: Message Flow Diagrams       B.3.4.2 Number Pool Block Create by NPAC SMS (previously NNP flow 2.2)    In this scenario, the NPAC SMS creates the number pool block on or after the effective date of the serviceProvNPA-NXX-X object. Since the SOA does not send in the creation request, all notifications (M-EVENT-REPORTs) to the SOA will be suppressed.  [Graphic Omitted: Number Pool Block Create by NPAC SMS]  Action is taken by the NPAC SMS to create a number pool block.     1.   NPAC SMS personnel create the numberPoolBlockNPAC on the NPAC SMS for a service provider block holder using the M-ACTION, numberPoolBlock-Create. The following attributes are required:             numberPoolBlockNPA-NXX-X numberPoolBlockSPID numberPoolBlockLRN numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN           If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile, the following attributes must be provided:             numberPoolBlockWSMSC-DPC numberPoolBlockWSMSC-SSN           If the indicator is not set, the request will be rejected.          If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes must be included:             numberPoolBlockSVType           If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may optionally be included:             alternativeSPID           The NPAC SMS verifies the following and returns the indicated error if the condition fails:         •   The serviceProvNPA-NXX-X object exists for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is no-npa-nxx-x-found.        •   All attributes are valid. If the condition fails, error returned is invalid-data-values.        •   A numberPoolBlockNPAC object does not already exist or one exists with a status of ‘old’ with an empty list of failed service providers for the given numberPoolBlockNPA-NXX-X. If the condition fails, error returned is number-pool-block-already-exists.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      73                   Appendix B: Message Flow Diagrams         •   The current date is greater than or equal to the serviceProvNPA-NXX-X-EffectiveTimeStamp of the corresponding serviceProvNPA-NXX-X object. If the condition fails, error returned is prior-to-effective-date.        •   There are no subscription version objects within the given TN range with a status of pending, conflict, cancel-pending or failed (“pending-like”) and no active subscription version for that TN. If the condition fails, error returned is invalid-subscription-versions.           Any other error will be returned as “failed”. If an error is found, the NPAC SMS returns the M-ACTION reply with the error. No further processing occurs.      2.   The NPAC SMS creates the numberPoolBlockNPAC object. The numberPoolBlockSOA-Origination indicator is set to FALSE. The numberPoolBlockCreationTimeStamp, numberPoolBlockActivationTimeStamp, numberPoolBlockBroadcastTimeStamp and numberPoolBlockModifiedTimeStamp are set. The numberPoolBlockStatus is set to “sending”.      3.   NPAC SMS responds to the M-CREATE.      4.   The NPAC SMS creates the corresponding subscriptionVersionNPAC object.(s). If an active, partial-failure, sending or disconnect-pending (“active-like”) subscription version exists within the block’s TN range, no new subscription version will be created for that TN. For the subscription version created, the subscriptionLNPType will be set to ‘pool’, the subscriptionVersionStatus will be set to “sending” and the subscriptionModifiedTimeStamp, subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionCreationTimeStamp will be set.      5.   NPAC SMS responds to the M-CREATE.      6.   NPAC SMS responds to the M-ACTION.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      74                   Appendix B: Message Flow Diagrams       B.3.4.3 Number Pool Block Create Broadcast Successful to Local SMS (previously NNP flow 2.3.1)    In this scenario, the number pool block and corresponding subscription versions have been created on the NPAC SMS. The NPAC SMS now begins to broadcast the subscriptionVersions and numberPoolBlock data to the Local SMSs.  [Graphic Omitted: Number Pool Block Create Broadcast Successful to Local SMS]     1.   NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the non-EDR Local SMS, if it is accepting downloads for the NPA-NXX of the subscription versions. This action contains all data required to create the subscription versions with the subscriptionLNPType of ‘pool’.       2.   At the same time as step 1, the NPAC SMS sends the M-CREATE for the numberPoolBlock to the EDR Local SMS.       3.   The non-EDR Local SMS verifies the action is valid and returns the M-ACTION reply. If the non-EDR Local SMS does not respond to the M-ACTION request, the NPAC SMS will retry the request a tunable amount of times.       4.   The EDR Local SMS sends to the NPAC SMS the results of the M-CREATE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.       5.   The non-EDR Local SMS proceeds to execute all the creates specified by the action. The non-EDR Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the subscription version creates.       6.   NPAC SMS confirms the M-EVENT-REPORT.   The NPAC SMS now waits for all the subscriptionVersionLocalSMS-ActionResults M-EVENT-REPORTs a tunable amount of time (default 1 hour).                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      75                   Appendix B: Message Flow Diagrams       B.3.4.4 Number Pool Block Create: Successful Broadcast (previously NNP flow 2.3.2)    In this scenario, the NPAC SMS has just completed the successful broadcast of a numberPoolBlock and corresponding subscriptionVersions.  [Graphic Omitted: Number Pool Block Create: Successful Broadcast]     1.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.       2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.       4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’.       6.   Block holder SOA confirms the M-EVENT-REPORT.                             March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      76                   Appendix B: Message Flow Diagrams       B.3.4.5 Number Pool Block Create Broadcast to Local SMS: Failure (previously NNP flow 2.4)    In this scenario, the NPAC SMS has a numberPoolBlock and corresponding subscriptionVersions in ‘sending’ state for creation to the Local SMSs and no Local SMS will respond successfully to the broadcast.  [Graphic Omitted: Number Pool Block Create Broadcast to Local SMS: Failure]     1.   NPAC SMS sends the M-ACTION subscriptionVersionLocalSMS-Create request to all the non-EDR Local SMSs.       2.   At the same time as step 1, NPAC SMS sends the M-CREATE numberPoolBlock request to all the EDR Local SMSs.    NPAC SMS waits for all the responses.  NPAC SMS retries any Local SMS who does not respond.  NPAC SMS receives no responses or receives errors in response to the create requests from all Local SMSs (EDR and non-EDR).     3.   NPAC SMS sets each subscriptionVersionNPAC’s subscriptionVersionStatus to ‘failed’. The subscriptionFailed-SP-List gets updated with the failed service providers and the subscriptionModifiedTimeStamp gets set.      4.   NPAC SMS responds to the M-SET.       5.   NPAC SMS sets the numberPoolBlock’s numberPoolBlockStatus to ‘failed’. The numberPoolBlockFailed-SP-List gets updated with the failed service providers, both EDR and non-EDR, and the subscriptionModifiedTimeStamp gets set.      6.   NPAC SMS responds to the M-SET.       7.   If the numberPoolBlock’s SOA Origination indicator is set to ‘true’, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, for the numberPoolBlock with the numberPoolBlockStatus set to ‘failed’ and the numberPoolBlockFailed-SP-List to the block holder SOA.      8.   The SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      77                   Appendix B: Message Flow Diagrams       B.3.4.6 Number Pool Block Create Broadcast to Local SMS: Partial Failure (previously NNP flow 2.5.1)    In this scenario, the NPAC SMS has a numberPoolBlock and corresponding subscriptionVersions in ‘sending’ state for creation to the Local SMSs and some but not all Local SMS will respond successfully to the broadcast resulting in a state of “partial-failure” for one or more of the subscription versions and the number pool block.  [Graphic Omitted: Number Pool Block Create Broadcast to Local SMS: Partial Failure]     1.   NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the non-EDR Local SMS, if it is accepting downloads for the NPA-NXX of the subscription versions. This action contains all data required to create the subscription versions with the subscriptionLNPType of ‘pool’.       2.   At the same time as step 1, NPAC SMS sends the M-CREATE for the numberPoolBlock to the EDR Local SMS.       3.   The non-EDR Local SMS verifies the action is valid and returns an acknowledgment. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-ACTION request a tunable amount of times.       4.   The EDR Local SMS sends to the NPAC SMS the results of the M-CREATE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.       5.   The non-EDR Local SMS proceeds to execute all the creates specified by the action. The non-EDR Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the creates.       6.   NPAC SMS confirms the M-EVENT-REPORT.   The NPAC SMS now waits for all the subscriptionVersionLocalSMS-ActionResults M-EVENT-REPORTs responses a tunable amount of time (default 1 hour).                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      78                   Appendix B: Message Flow Diagrams       B.3.4.7 Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates (previously NNP flow 2.5.2)    All retries have been exhausted and the time for the subscriptionVersionLocalSMS-CreateResults to be received has expired for a broadcast of a number pool block create.  [Graphic Omitted: Number Pool Block Create Broadcast Partially Failed NPAC SMS Updates]  NPAC SMS receives a successful response to the create request from at least one, but not all, Local SMSs (EDR and non-EDR).  The NPAC SMS must now set the numberPoolBlock to partial-failure and subscriptionVersion objects to partial-failure or active depending upon which Local SMSs failed the request. If an EDR Local SMS failed, the numberPoolBlock and ALL subscriptionVersions broadcast will be set to partial-failure. If a non-EDR Local SMS failed all the creates, the numberPoolBlock and ALL subscriptionVersion broadcast will be set to partial-failure. If a non-EDR Local SMS fails only some of the subscriptionVersion creates, the numberPoolBlock will be set to partial-failure along with the subscriptionVersions the non-EDR Local SMS failed. The other subscription versions may be set to ‘active’ if all EDR Local SMSs were successful and all other non-EDR Local SMSs were successful for those subscription versions.  The numberPoolBlockFailed-SP-List on the number pool block object contains all the service providers who failed to receive either the number pool block or any of the subscription versions. The subscriptionFailed-SP-List on each subscription version object contains only those service providers who failed to receive that subscription version or the number pool block object.  The partial-failure status will be removed from both objects when all subscriptionVersions and numberPoolBlocks are successfully resent or recovered.     1.   NPAC SMS issues an M-SET to the subscriptionVersionNPAC(s) setting the subscriptionVersionStatus to ‘partially-failed’ or ‘active’ and setting the subscriptionFailed-SP-List to the list of failed service providers. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS issues an M-SET to the numberPoolBlockNPAC setting the numberPoolBlockStatus to ‘partially-failed’ and setting the numberPoolBlockFailed-SP-List to the list of failed service providers. The numberPoolBlockModifiedTimeStamp is also set.      4.   NPAC SMS responds to the M-SET.       5.   If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the block holder SOA the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, with the numberPoolBlockStatus set to ‘partially-failed’ and the numberPoolBlockFailed-SP-List.      6.   The block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      79                   Appendix B: Message Flow Diagrams       B.3.4.8 Number Pool Block Create Resend Broadcast (previously NNP flow 2.6)    In this scenario, the NPAC SMS has a number pool block and corresponding subscription versions with LNP type of ‘pool’ in a failed or partially-failed state. The NPAC SMS will resend the requests to the Local SMSs.  [Graphic Omitted: Number Pool Block Create Resend Broadcast]  Action is taken by the NPAC SMS personnel to resend a previously failed activation of a number pool block and corresponding subscription versions.     1.   NPAC SMS issues the M-SET to modify the numberPoolBlockStatus to ‘sending’ on the number pool block object. The numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp also get set.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS issues the M-SET to modify the subscriptionVersionStatus to ‘sending’ on the subscription version object. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp also get set.      4.   NPAC SMS responds to the M-SET.       5.   NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the non-EDR Local SMS if it had previously failed the create request. This action contains all data to create the subscription versions with LNP type of ‘pool’. If the create is for a single subscription version, the M-CREATE will be sent. A mixture of both actions and single creates is possible depending upon the subscription versions that need to be created.       6.   At the same time as step 5, the NPAC SMS sends the M-CREATE for the numberPoolBlock to the EDR Local SMS if it had previously failed the create request.       7.   The non-EDR Local SMS verifies the action is valid and returns the M-ACTION reply. If the non-EDR Local SMS does not respond to the M-ACTION request, the NPAC SMS will retry the request a tunable number of times.       8.   The EDR Local SMS sends to the NPAC SMS the results of the M-CREATE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.       9.   The non-EDR Local SMS proceeds to execute all the creates specified by the action. The non-EDR Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the subscription version creates.      10.   NPAC SMS confirms the M-EVENT-REPORT.    The NPAC SMS now waits for all the subscriptionVersionLocalSMS-CreateResults M-EVENT-REPORTs a tunable amount of time (default 1 hour).                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      80                   Appendix B: Message Flow Diagrams       B.3.4.9 Number Pool Block Create Successful Resend Updates (previously NNP flow 2.7)    In this scenario, the NPAC SMS has successfully re-sent the creation of a number pool block and corresponding subscription versions. The NPAC SMS now updates the state of the objects on the NPAC SMS.  [Graphic Omitted: Number Pool Block Create Successful Resend Updates]     1.   NPAC SMS updates the numberPoolBlockNPAC by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.       5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      81                   Appendix B: Message Flow Diagrams       B.3.4.10 Number Pool Block Create Failed Resend NPAC SMS Updates (previously NNP flow 2.8)    In this scenario, the NPAC SMS has unsuccessfully resent the creation of a number pool block and corresponding subscription versions and the status is still failed for the objects. The NPAC SMS now updates the state of the objects on the NPAC SMS.  [Graphic Omitted: Number Pool Block Create Failed Resend NPAC SMS Updates]     1.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus back to ‘failed’, updating the numberPoolBlockFailed-SP-List with the failed service providers who failed the subscription version and number pool block download and setting the numberPoolBlockModifiedTimeStamp to the current date and time.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus back to ‘failed’, updating the subscriptionFailed-SP-List with the failed service providers who failed either the number pool block or subscription version create and setting the subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.       5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘failed’ and the numberPoolBlockFailed-SP-List.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      82                   Appendix B: Message Flow Diagrams       B.3.4.11 Number Pool Block Create Partial-Failure Resend NPAC SMS Updates (previously NNP flow 2.9)    In this scenario, the NPAC SMS has unsuccessfully re-sent the creation of a number pool block and corresponding subscription versions and the status is now partial-failure for the objects. The NPAC SMS now updates the state of the objects on the NPAC SMS.  [Graphic Omitted: Number Pool Block Create Partial-Failure Resend NPAC SMS Updates]     1.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘partial-failure’, updating the numberPoolBlockFailed-SP-List with the failed service providers who failed the number pool block or subscription version create and setting the numberPoolBlockModifiedTimeStamp to the current date and time.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS updates each of the subscriptionVersionNPAC that was broadcasted by setting the subscriptionVersionStatus to ‘partial-failure’ or ‘active’, updating the subscriptionFailed-SP-List with the failed service providers who failed the number pool block or subscription version create and setting the subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.       5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘partial-failure’ and the failed service provider list.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      83                   Appendix B: Message Flow Diagrams       B.3.4.12 Number Pool Block Modify by NPAC SMS (previously NNP flow 2.10)    This scenario shows the modification of a number pool block object by NPAC Personnel at the request of the block holder service provider.  [Graphic Omitted: Number Pool Block Modify by NPAC SMS]  Action is taken by NPAC personnel to modify the data on a number pool block.     1.   NPAC SMS issues the M-SET to modify attribute data on a single numberPoolBlock. The following attributes can be modified:             numberPoolBlockLRN numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN numberPoolBlockSOA-Origination           If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile, the following attributes may be updated:             numberPoolBlockWSMSC-DPC         numberPoolBlockWSMSC-SSN           If the indicator is not set, the request will be rejected..          If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:             numberPoolBlockSVType           If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:             alternativeSPID           In addition, the numberPoolBlockStatus gets set to ‘sending’ and the numberPoolBlockBroadcastTimeStamp and numberPoolBlockModifiedTimeStamp get set to the current date and time.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues the M-SET to modify the attribute data on the corresponding subscriptionVersionNPAC object(s). Only the following attributes can be modified:             subscriptionLRN                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      84                   Appendix B: Message Flow Diagrams             subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionWSMSC-DPC subscriptionWSMSC-SSN subscriptionSOA-Origination subscriptionSVType subscriptionAlternativeSPID           In addition, the NPAC SMS sets the subscriptionVersionStatus to ‘sending’ and the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp get set to the current date and time.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, attribute value change, to the block holder SOA. The attribute value change would include any of the following attributes that were updated:             numberPoolBlockLRN numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN numberPoolBlockSOA-Origination           The following attributes will be sent if they are updated and the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile:             numberPoolBlockWSMSC-DPC numberPoolBlockWSMSC-SSN           The following attributes will be sent if they are updated and the “SOA Supports SV Type Indicator” is set in the service provider’s profile:             numberPoolBlockSVType           The following attributes will be sent if they are updated and the “SOA Supports Alternative SPID” is set in the service provider’s profile:             numberPoolBlockAlternativeSPID       6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      85                   Appendix B: Message Flow Diagrams       B.3.4.13 Number Pool Block Modify by Block Holder SOA (previously NNP flow 2.11)    This scenario shows the modification of a number pool block object by the block holder SOA Personnel.  [Graphic Omitted: Number Pool Block Modify by Block Holder SOA]     1.   Block holder SOA issues the M-SET by either directing the request to a specific number pool block or issuing a scope and filtered request specifying the numberPoolBlockNPA-NXX-X and numberPoolBlockStatus to modify attribute data on the numberPoolBlock. The following attributes can be modified:             numberPoolBlockLRN numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN           If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile, the following attributes may be updated:             numberPoolBlockWSMSC-DPC numberPoolBlockWSMSC-SSN           If the indicator is not set, the request will be rejected..          If the “SOA Supports SV Type Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:             numberPoolBlockSVType           If the “SOA Supports Alternative SPID Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes may be updated:             alternativeSPID         In addition, the numberPoolBlockStatus gets set to ‘sending’ and the numberPoolBlockBroadcastTimeStamp gets set.     2.   NPAC SMS responds to the M-SET.     3.   NPAC SMS issues the M-SET to modify the attribute data on the corresponding subscriptionVersionNPAC object(s). Only the following attributes can be modified:          subscriptionLRN subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      86                   Appendix B: Message Flow Diagrams              subscriptionISVM-DPC subscriptionISVM-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionWSMSC-DPC subscriptionWSMSC-SSN subscriptionSVType subscriptionAlternativeSPID           In addition, the NPAC SMS sets the subscriptionVersionStatus to ‘sending’.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, attribute value change, to the block holder SOA. The attribute value change would include any of the following attributes that were updated:             numberPoolBlockLRN numberPoolBlockCLASS-DPC numberPoolBlockCLASS-SSN numberPoolBlockCNAM-DPC numberPoolBlockCNAM-SSN numberPoolBlockISVM-DPC numberPoolBlockISVM-SSN numberPoolBlockLIDB-DPC numberPoolBlockLIDB-SSN    If the “SOA WSMSC DPC SSN Data Indicator” is set in the service provider’s profile on the NPAC SMS, the following attributes will be sent if they were updated:           numberPoolBlockWSMSC-DPC numberPoolBlockWSMSC-SSN           The following attributes will be sent if they are updated and the “SOA Supports SV Type Indicator” is set in the service provider’s profile:             numberPoolBlockSVType           The following attributes will be sent if they are updated and the “SOA Supports Alternative SPID” is set in the service provider’s profile:             numberPoolBlockAlternativeSPID       6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      87                   Appendix B: Message Flow Diagrams       B.3.4.14 Number Pool Block Modify Successful Broadcast to Local SMS Success (previously NNP flow 2.12.1)    In this scenario, the NPAC SMS has made a modification to a number pool block object and is about to broadcast the data to the Local SMS.  [Graphic Omitted: Number Pool Block Modify Successful Broadcast to Local SMS Success]  The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.     1.   NPAC SMS sends the M-SET for the updated attributes on the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX.       2.   At the same time, the NPAC SMS sends the M-SET for the updated attributes on the number pool block object to the EDR Local SMS.      3.   Non-EDR Local SMS responds to the M-SET.      4.   EDR Local SMS responds to the M-SET.    As soon as 1 successful response is received to either M-SET, the status of the subscriptionVersionNPAC and numberPoolBlockNPAC object goes to ‘active’.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      88                   Appendix B: Message Flow Diagrams       B.3.4.15 Number Pool Block Modify Successful Broadcast NPAC SMS Updates (previously NNP flow 2.12.2)    In this scenario, the NPAC SMS has received successful M-SET responses from all the Local SMS for the numberPoolBlock and corresponding subscriptionVersions.  [Graphic Omitted: Number Pool Block Modify Successful Broadcast NPAC SMS Updates]  As soon as the first successful response is received, the NPAC SMS sets the status of the subscriptionVersionNPAC objects and numberPoolBlockNPAC object to ‘active’. The numberPoolBlockStatusAttributeValueChange, however, is not sent out until all replies have been received or the retries have been exhausted.     1.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.       5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to active.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      89                   Appendix B: Message Flow Diagrams       B.3.4.16 Number Pool Block Modify Broadcast to Local SMS Failure (previously NNP flow 2.13)    NPAC SMS has a numberPoolBlock and corresponding subscriptionVersion in ‘sending’ state for modifications. In this scenario, no Local SMSs will respond successfully to the M-SET requests.  [Graphic Omitted: Number Pool Block Modify Broadcast to Local SMS Failure]     1.   NPAC SMS sends the M-SET with the modifications for the subscriptionVersion to the non-EDR Local SMS.       2.   At the same time as step 1, NPAC SMS sends the M-SET with the modifications for the numberPoolBlock to the EDR Local SMS.    NPAC SMS waits for a response from all Local SMSs.  NPAC SMS retries any Local SMS that has not responded.  No response or an error is received from all the Local SMSs (EDR and non-EDR).     3.   NPAC SMS returns the subscriptionVersionStatus to ‘active’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.       5.   NPAC SMS returns the numberPoolBlockStatus to ‘active’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers. The numberPoolBlockModifiedTimeStamp also gets set.      6.   NPAC SMS responds to the M-SET.       7.   If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the block holder SOA the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, with the numberPoolBlockStatus set to active and the numberPoolBlockFailed-SP-List.      8.   SOA confirms M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      90                   Appendix B: Message Flow Diagrams       B.3.4.17 Number Pool Block Modify Partial Failure Broadcast to Local SMS (previously NNP flow 2.14.1)    In this scenario, the NPAC SMS has a numberPoolBlock and corresponding subscriptionVersion object(s) in a state of ‘sending’ for a modification to the Local SMS. The broadcast, however, will result in a partial-failure state for both the numberPoolBlock and corresponding subscriptionVersions.  [Graphic Omitted: Number Pool Block Modify Partial Failure Broadcast to Local SMS]  The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.     1.   NPAC SMS sends the M-SET for the updated attributes on the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX.       2.   At the same time as step 1, NPAC SMS sends the M-SET for the updated attributes on the number pool block object to the EDR Local SMS who are accepting downloads for the NPA-NXX.      3.   Non-EDR Local SMS responds successfully to the M-SET.      4.   EDR Local SMS responds successfully to the M-SET.    NPAC SMS waits for a response from all Local SMSs.  NPAC SMS retries any Local SMS that has not responded.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      91                   Appendix B: Message Flow Diagrams       B.3.4.18 Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.14.2)    The NPAC SMS has attempted to broadcast the number pool block modification to the Local SMSs. However, at least 1, but not all Local SMSs have responded successfully to the M-SETs.  [Graphic Omitted: Number Pool Block Modify Broadcast Partial Failure NPAC SMS Updates]  Once the first successful M-SET response is received, the NPAC SMS sets the status to ‘active’ for the numberPoolBlock and subscriptionVersion objects. Once all retries are exhausted, the NPAC SMS sets the numberPoolBlockFailed-SP-List and sends the status attribute value change.  The numberPoolBlockSP-List on the number pool block object contains all the service providers who failed to receive either the number pool block or any of the subscription versions. The subscriptionFailed-SP-List on the subscription version object contains only those service providers who failed to receive that subscription version or the number pool block object.     1.   NPAC SMS updates the subscriptionVersionNPACs with a LNP type set to ‘pool’ that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and updating the subscriptionFailed-SP-List to the list of failed service providers. The subscriptionModifiedTimeStamp is set to the current date and time.      2.   NPAC SMS responds to the M-SET.       3.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockFailed-SP-List to the list of currently failed service providers. It also sets the numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.       5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’ and the numberPoolBlockFailed-SP-List.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      92                   Appendix B: Message Flow Diagrams            B.3.4.19   Number Pool Block Modify Resend Broadcast (previously NNP flow 2.15)    In this scenario, the NPAC SMS must resend a previously failed modification to a number pool block and corresponding subscription versions of type ‘pool’.  [Graphic Omitted: Number Pool Block Modify Resend Broadcast]  Action is taken by the NPAC SMS personnel to resend a previously failed modification of a number pool block and corresponding subscription versions with a LNP type of ‘pool’.     1.   NPAC SMS issues the M-SET to modify the numberPoolBlockStatus to ‘sending’ on the number pool block object. The numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp also get set.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues the M-SET to modify the subscriptionVersionStatus to ‘sending’ on the subscription version object. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp also get set.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues the M-SET for the subscription versions to the non-EDR Local SMS if it had previously failed the modify request and if it is accepting downloads for the NPA-NXX.      6.   At the same time as step 5, the NPAC SMS sends the M-SET for the numberPoolBlock to the EDR Local SMS if it had previously failed the modify request and if it is accepting downloads for the NPA-NXX.      7.   The non-EDR Local SMS sends to the NPAC SMS the results of the M-SET. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-SET request a tunable amount of times.      8.   The EDR Local SMS sends to the NPAC SMS the results of the M-SET. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-SET request a tunable amount of times.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      93                   Appendix B: Message Flow Diagrams            B.3.4.20   Number Pool Block Modify Successful Resend Updates (previously NNP flow 2.16)    In this scenario, the NPAC SMS has received all successful responses to the modify request for a number pool block and corresponding subscription version with LNP type equal to ‘pool’.  [Graphic Omitted: Number Pool Block Modify Successful Resend Updates]     1.   NPAC SMS updates the numberPoolBlockNPAC by setting the numberPoolBlockStatus to ‘active’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘active’ and setting the subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      94                   Appendix B: Message Flow Diagrams            B.3.4.21   Number Pool Block Modify Failure Resend Updates (previously NNP flow 2.17)    In this scenario, the NPAC SMS has not received all successful responses to the modify request for a number pool block and corresponding subscription version with LNP type equal to ‘pool’.  [Graphic Omitted: Number Pool Block Modify Failure Resend Updates]     1.   NPAC SMS updates the numberPoolBlockNPAC by setting the numberPoolBlockStatus back to ‘active’, updating the numberPoolBlockFailed-SP-List with the failed service providers who failed the subscription version and number pool block download and setting the numberPoolBlockModifiedTimeStamp to the current date and time.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS updates each of the subscriptionVersionNPAC that was broadcasted by setting the subscriptionVersionStatus back to ‘active’, updating the subscriptionVersionFailed-SP-List with the failed service providers who failed either the number pool block or subscription version create and setting the subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT, numberPoolBlockStatusAttributeValueChange, to the block holder SOA for the number pool block. The status attribute value change would contain the numberPoolBlockStatus set to ‘active’ and the numberPoolBlockFailed-SP-List with any of the failed service providers who failed the subscription version and/or number pool block download.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      95                   Appendix B: Message Flow Diagrams            B.3.4.22   Number Pool Block Modification of SOA-Origination Indicator (previously NNP flow 2.18)    A block holder service provider has asked the NPAC SMS to change the value of the numberPoolBlockSOA-Origination indicator on a number pool block.  [Graphic Omitted: Number Pool Block Modification of SOA-Origination Indicator]  Action is taken by NPAC SMS personnel to modify a number pool block object.     1.   NPAC SMS locally M-SETs the number pool block object changing the value of the numberPoolBlockSOA-Origination indicator.      2.   NPAC SMS successfully responds to the M-SET.      3.   The NPAC SMS issues the M-EVENT-REPORT attribute value change to the block holder SOA for the number pool block that contains the numberPoolBlockSOA-Origination indicator, only when the numberPoolBlockSOA-Origination indicator is modified from FALSE to TRUE.      4.   The block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      96                   Appendix B: Message Flow Diagrams            B.3.4.23   Number Pool Block De-Pool by NPAC SMS (previously NNP flow 2.19)    This scenario reflects the events that occur when a block is “de-pooled” after the serviceProvNPA-NXX-X object has become effective and active. Only NPAC Personnel are allowed to remove a number pool block object at the request of the number pool block administrator.  The removal of the serviceProvNPA-NXX-X object is a cascading request. First, all subscription versions with the LNP type equal to ‘pool’ must be removed from the non-EDR Local SMSs and the number pool block must be removed from all the EDR Local SMSs.  [Graphic Omitted: Number Pool Block De-Pool by NPAC SMS]  Action is taken by NPAC personnel to ‘de-pool’ a block of TNs.     1.   NPAC SMS issues the M-SET to update the numberPoolBlockStatus to ‘sending’ and the numberPoolBlockBroadcastTimeStamp gets set.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues the M-SET to update the corresponding subscriptionVersions within the block range with LNP type equal to ‘pool’ to a status of ‘sending’ and the subscriptionModifiedTimeStamp gets set.      4.   NPAC SMS responds to the M-SET.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      97                   Appendix B: Message Flow Diagrams            B.3.4.24   Number Pool Block De-Pool Successful Broadcast of Subscription Version and Number Pool Block Deletes (previously NNP flow 2.20.1)    In this scenario, the NPAC personnel have initiated the “de-pool” of a block of TNs. The NPAC SMS already has the numberPoolBlock and corresponding subscriptionVersions in the “sending” state.  In this scenario, the NPAC SMS will send all the M-DELETE requests for the number pool block and subscription versions to the Local SMSs and get successful replies to all the requests.  [Graphic Omitted: Number Pool Block De-Pool Successful Broadcast of Subscription Version and Number Pool Block Deletes]  The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.     1.   NPAC SMS sends the M-DELETE for the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX. The subscription version TNs are within the block range and have the LNP type set to ‘pool’.      2.   At the same time, NPAC SMS sends the M-DELETE for the number pool block object to the EDR Local SMS.      3.   Non-EDR Local SMS respond successfully to the M-DELETE.      4.   EDR Local SMS respond successfully to the M-DELETE.    NPAC SMS waits for all the successful responses and retries as necessary.  NPAC SMS receives all successful responses.     5.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘old’ and setting the subscriptionModifiedTimeStamp to the current date and time. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      6.   NPAC SMS responds to the M-SET.      7.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘old’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time. The numberPoolBlockDisconnectCompleteTimeStamp is set when the first successful response is received.      8.   NPAC SMS responds to the M-SET.      9.   NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the donor service provider SOA that the subscription version is being disconnected with the customer disconnect date.      10.   The donor service provider SOA confirms the M-EVENT-REPORT.      11.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT for the numberPoolBlockStatusAttributeValueChange to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to ‘old’.      12.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      98                   Appendix B: Message Flow Diagrams            B.3.4.25   Number Pool Block De-Pool Broadcast Successful NPA-NXX-X Updates (previously NNP flow 2.20.2)    NPAC SMS has received successful responses to all numberPoolBlock and subscriptionVersion M-DELETE requests. The NPAC SMS now proceeds to delete the service provider NPA-NXX-X object.  [Graphic Omitted: Number Pool Block De-Pool Broadcast Successful NPA-NXX-X Updates]     1.   NPAC SMS issues the M-DELETE to remove the serviceProvNPA-NXX-X object locally.      2.   NPAC SMS responds successfully to the M-DELETE request for the serviceProvNPA-NXX-X object.      3.   The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the non-EDR Local SMS who are supporting the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.      4.   The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the EDR Local SMS who are supporting the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.      5.   At the same time as step 4, the NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the SOAs who are supporting the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.      6.   Non-EDR Local SMS respond successfully to the M-DELETE.      7.   EDR Local SMS respond successfully to the M-DELETE.      8.   SOA respond successfully to the M-DELETE.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      99                   Appendix B: Message Flow Diagrams            B.3.4.26   Number Pool Block De-Pool Broadcast to Local SMS Failure (previously NNP flow 2.21)    This scenario shows the failure of a broadcast for a de-pool of a number pool block. The M-DELETE has been issued on the serviceProvNPA-NXX-X object and now the NPAC SMS is attempting to broadcast the all the M-DELETEs associated with the block removal.  [Graphic Omitted: Number Pool Block De-Pool Broadcast to Local SMS Failure]     1.   NPAC SMS sends the M-DELETE for the subscriptionVersion to the non-EDR Local SMS.      2.   At the same time as step 1, NPAC SMS sends the M-DELETE for the numberPoolBlock to the EDR Local SMS.    NPAC SMS waits for a response from all Local SMSs.  NPAC SMS retries the Local SMSs that have not responded.  No response or an error is received from all the Local SMSs (EDR and non-EDR).     3.   NPAC SMS sets the subscriptionVersionStatus to ‘active’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS sets the numberPoolBlockStatus to ‘active’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers. The numberPoolBlockModifiedTimeStamp also gets set.      6.   NPAC SMS responds to the M-SET.      7.   If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the originating SOA the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange with the numberPoolBlockStatus set back to ‘active’ and numberPoolBlockFailed-SP-List.      8.   SOA confirms M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      100                   Appendix B: Message Flow Diagrams            B.3.4.27   Number Pool Block De-Pool Partial Failure Broadcast to Local SMS of Subscription Versions and Number Pool Block (previously NNP flow 2.22.1)    This scenario shows the processing of a partial-failure for the de-pool of a number pool block. The M-DELETE has been issued on the serviceProvNPA-NXX-X object on the NPAC SMS and now the NPAC SMS is attempting to broadcast all the M-DELETEs associated with the block removal to the Local SMSs.  [Graphic Omitted: Number Pool Block De-Pool Partial Failure Broadcast to Local SMS of Subscription Versions and Number Pool Block]  The NPAC SMS has a number pool block object and corresponding subscription version objects in a state of ‘sending’.     1.   NPAC SMS sends the M-DELETE for the subscription version object(s) to the non-EDR Local SMS who are accepting downloads for the NPA-NXX.      2.   NPAC SMS sends the M-DELETE for the number pool block object to the EDR Local SMS.      3.   Non-EDR Local SMS responds to the M-DELETE for the subscriptionVersion.      4.   EDR Local SMS responds to the M-DELETE for the numberPoolBlock.    NPAC SMS waits for a response from all Local SMSs.  NPAC SMS retries any Local SMS that has not responded.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      101                   Appendix B: Message Flow Diagrams            B.3.4.28   Number Pool Block De-Pool Broadcast Partial Failure NPAC SMS Updates (previously NNP flow 2.22.2)    The NPAC SMS broadcast of a block deletion partially failed. The NPAC SMS now updates the states of the objects on the NPAC SMS.  [Graphic Omitted: Number Pool Block De-Pool Broadcast Partial Failure NPAC SMS Updates]  No response or an error is received from at least one Local SMS.     1.   NPAC SMS updates each of the subscriptionVersionNPACs that was broadcasted by setting the subscriptionVersionStatus to ‘old’ and updating the subscriptionFailed-SP-List to the list of failed service providers. The subscriptionModifiedTimeStamp is set to the current date and time. The subscriptionDisconnectCompleteTimeStamp would be set with the first successful response.          The subscriptionFailed-SP-List will reflect the list of the EDR service providers that failed on the number pool block broadcast and any non-EDR service provider that failed to receive any subscription version.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘old’ and setting the numberPoolBlockFailed-SP-List to the list of currently failed service providers. It also sets the numberPoolBlockModifiedTimeStamp to the current date and time. The numberPoolBlockDisconnectCompleteTimeStamp would be set with the first successful response.          The numberPoolBlockFailed-SP-List will reflect the list of the EDR service providers that failed on the number pool block broadcast and any non-EDR service provider that failed to receive any subscription versions.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT for the subscription version status attribute value change to the block holder SOA. The numberPoolBlockStatusAttributeValueChange would contain the numberPoolBlockStatus set to ‘old’ and the numberPoolBlockFailed-SP-List.      6.   Block holder SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      102                   Appendix B: Message Flow Diagrams            B.3.4.29   Number Pool Block De-Pool Resend Broadcast (previously NNP flow 2.23)    In this scenario, the NPAC SMS resends the broadcast of a de-pool of a block because the first attempt did not complete successfully.  [Graphic Omitted: Number Pool Block De-Pool Resend Broadcast]  Action is taken by the NPAC SMS personnel to resend a previously failed de-pool of block data.     1.   NPAC SMS issues the M-SET to modify the numberPoolBlockStatus to ‘sending’ of the number pool block object. The numberPoolBlockModifiedTimeStamp and numberPoolBlockBroadcastTimeStamp also get set.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues the M-SET to modify the subscriptionVersionStatus to ‘sending’ of the subscription version object. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp also get set.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues the M-DELETE for the subscription versions to the non-EDR Local SMS if it is accepting downloads for the NPA-NXX and had previously failed the delete request.      6.   At the same time as step 5, the NPAC SMS sends the M-DELETE for the numberPoolBlock to the EDR Local SMS if it is accepting downloads for the NPA-NXX and had previously failed the delete request.      7.   The non-EDR Local SMS sends to the NPAC SMS the results of the M-DELETE. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-DELETE request a tunable amount of times.      8.   The EDR Local SMS sends to the NPAC SMS the results of the M-DELETE. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-DELETE request a tunable amount of times.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      103                   Appendix B: Message Flow Diagrams            B.3.4.30   Number Pool Block De-Pool Successful Resend Updates (previously NNP flow 2.24)    In this scenario, the NPAC SMS successfully rebroadcast the number pool block and subscription version deletes to the Local SMS. It now proceeds to update the status of the number pool block and corresponding subscription versions and then sends the NPA-NXX-X delete to the Local SMSs.  [Graphic Omitted: Number Pool Block De-Pool Successful Resend Updates]     1.   NPAC SMS updates all the subscriptionVersionNPACs that were broadcasted by setting the subscriptionVersionStatus to ‘old’ and setting the subscriptionModifiedTimeStamp to the current date and time. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS updates the numberPoolBlock by setting the numberPoolBlockStatus to ‘old’ and setting the numberPoolBlockModifiedTimeStamp to the current date and time. The numberPoolBlockDisconnectCompleteTimeStamp is set when the first successful response is received.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to TRUE, the NPAC SMS sends the M-EVENT-REPORT for the numberPoolBlockStatusAttributeValueChange to the block holder SOA. The status attribute value change would contain the numberPoolBlockStatus set to ‘old’.      6.   Block holder SOA confirms the M-EVENT-REPORT.      7.   NPAC SMS issues the M-DELETE to remove the serviceProvNPA-NXX-X object locally.      8.   NPAC SMS responds successfully to the M-DELETE request for the serviceProvNPA-NXX-X object.      9.   The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the non-EDR Local SMS that support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.      10.   The NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the EDR Local SMS that support the object according to the “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.      11.   At the same time as step 10, the NPAC SMS sends the M-DELETE for the serviceProvNPA-NXX-X object to the SOA that support the object according to the “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS.      12.   Non-EDR Local SMS respond successfully to the M-DELETE.      13.   EDR Local SMS respond successfully to the M-DELETE.      14.   SOA respond successfully to the M-DELETE.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      104                   Appendix B: Message Flow Diagrams            B.3.4.31   Number Pool Block De-Pool Resend Failure Updates (previously NNP flow 2.25)    In this scenario, the NPAC SMS was not successful in the resend of a previously failed de-pool attempt and proceeds to update the status of the number pool block and corresponding subscription versions.  [Graphic Omitted: Number Pool Block De-Pool Resend Failure Updates]     1.   NPAC SMS sets the subscriptionVersionStatus to ‘active’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp on the subscription version objects.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS sets the numberPoolBlockStatus to ‘active’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers on the number pool block object. The numberPoolBlockModifiedTimeStamp also gets set.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the originating SOA the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange with the numberPoolBlockStatus set back to ‘active’ and numberPoolBlockFailed-SP-List.      6.   SOA confirms M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      105                   Appendix B: Message Flow Diagrams            B.3.4.32   Number Pool Block De-Pool Resend Partial Failure Updates (previously NNP flow 2.26)    In this scenario, the NPAC SMS has attempted to resend a failed de-pool attempt and has resulted in partial-failure. The NPAC SMS proceeds to update the status of the objects locally.  [Graphic Omitted: Number Pool Block De-Pool Resend Partial Failure Updates]     1.   NPAC SMS sets the subscriptionVersionStatus to ‘old’, sets the subscriptionFailed-SP-List to the list of failed service providers and sets the subscriptionModifiedTimeStamp to the current date and time on the subscription version objects. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS sets the numberPoolBlockStatus to ‘old’ and sets the numberPoolBlockFailed-SP-List to the list of failed service providers on the number pool block object. The numberPoolBlockModifiedTimeStamp also get set. The numberPoolBlockDisconnectCompleteTimeStamp is set when the first successful response is received.      4.   NPAC SMS responds to the M-SET.      5.   If the numberPoolBlockSOA-Origination indicator is set to ‘true’, the NPAC SMS sends the originating SOA the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange with the numberPoolBlockStatus set to ‘old’ and numberPoolBlockFailed-SP-List.      6.   SOA confirms M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      106                   Appendix B: Message Flow Diagrams            B.3.4.33   Number Pool Block Query by SOA or LSMS (previously NNP flow 2.27)    In this scenario, the service provider personnel queries for one or more number pool block objects from the SOA or Local SMS.  [Graphic Omitted: Number Pool Block Query by SOA or LSMS]  Action is taken by service provider personnel to query one or more numberPoolBlock objects for all attributes.     1.   SOA or Local SMS sends the M-GET request for either requesting a single numberPoolBlock object by numberPoolBlockId or requesting one or more numberPoolBlock objects using a scope and filtered request.      2.   If the requested object(s) exist, the NPAC SMS will respond with a single or linked M-GET reply. If no objects are found, the NPAC SMS will respond with an empty result. All attributes are returned in the query.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      107                   Appendix B: Message Flow Diagrams            B.4   SubscriptionVersion Flow Scenarios    Note: All actions for subscription versions in the flows that follow are atomic. If the operation fails for one TN in a range it fails for all TNs in the range.  Any creation or update of a subscription version causes the subscriptionModifiedTimeStamp to be updated. Therefore the explicit setting of that attribute is not reflected in the subscription version flows.          B.4.1   SubscriptionVersion Create Scenarios    The subscriptionVersionNPAC object is created by either the new or old service provider SOA issuing their M-ACTION to create the subscription version. If the new service provider SOA issues its subscriptionVersionNewSP-Create action first, the old service provider SOA has the option of sending in the subscriptionVersionOldSP-Create action or not. If they do send in the subscriptionVersionOldSP-Create, the old service provider explicitly states their concurrence or non-concurrence to the port by the value set within the subscriptionOldSP-Authorization field. If the old service provider does not send in their create request within the concurrence window, this implies concurrence to the port. However, the old service provider can send in their create request after the concurrence window before activation of the subscription version and the NPAC SMS will accept the data if valid.  If the old service provider SOA issues its subscriptionVersionOldSP-Create action first, then the new service provider SOA must issue its subscriptionVersionNewSP-Create action.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      108                   Appendix B: Message Flow Diagrams            B.4.1.1   Subscription Version Create by the Initial SOA (Old Service Provider)    In this scenario, the old service provider is the first to send the M-ACTION to create the subscriptionVersionobject.  [Graphic Omitted: Subscription Version Create by the Initial SOA]  Action is taken by the old service provider SOA to create a new version of a subscriber.     1.   Old service provider SOA sends M-ACTION subscriptionVersionOldSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The old service provider SOA must specify the following valid attributes:    subscriptionTN or a valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionOldSP-DueDate (seconds set to zeros) subscriptionOldSP-Authorization subscriptionLNPType         If the service provider were to give a range of TNs, this would result in an M-CREATE and M-EVENT-REPORT for each TN.          If an attribute value is invalid, an invalidArgumentValue will be returned, indicating invalid data values. Other appropriate errors will also be returned.      2.   If the request is valid, the NPAC SMS will create the subscriptionVersionNPAC object. The status will be set to “pending” and the subscriptionOldSP-AuthorizationTimeStamp and subscriptionModifiedTimeStamp will be set.      3.   NPAC SMS responds to M-CREATE.      4.   NPAC SMS sends action reply with success or failure and reasons for failure.      5.   If the M-ACTION was successful, the NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M-EVENT-REPORT containing the following attributes to old service provider SOA of subscriptionVersionNPAC creation:    subscriptionVersionID subscriptionTN subscriptionOldSP subscriptionNewCurrentSP subscriptionOldSp-DueDate subscriptionOldSP-Authorization subscriptionOldSP-AuthorizationTimeStamp subscriptionStatusChangeCauseCode — (if subscriptionOldSP-Authorization set to false)                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      109                   Appendix B: Message Flow Diagrams    subscriptionVersionStatus subscriptionVersionConflictTimeStamp — (if subscriptionOldSP-Authorization set to false)         If the notification is a subscriptionVersionRangeObjectCreation then the TN and SVID are the TN and SVID of the first TN in the range or list.      6.   Old service provider SOA responds by sending an M-EVENT-REPORT confirmation back to the NPAC SMS.      7.   If the M-ACTION was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M- EVENT-REPORT to new service provider SOA of subscriptionVersionNPAC creation.      8.   New service provider SOA issues an M-EVENT-REPORT confirmation to NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      110                   Appendix B: Message Flow Diagrams            B.4.1.1.1   Subscription Version Create by the Initial SOA (Old Service Provider) (continued)    [Graphic Omitted: Subscription Version Create by the Initial SOA]         NPAC SMS decides if this subscription version is the first use of the NPA-NXX.      1.   If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the accepting Local SMSs.      2.   The Local SMS confirms the M-EVENT-REPORT.      3.   The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the Old SOA.      4.   The Old SOA confirms the M-EVENT-REPORT.      5.   The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the New SOA.      6.   The New SOA confirms the M-EVENT-REPORT.    The next scenario would be “SubscriptionVersion Create by the Second SOA (New Service Provider).”                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      111                   Appendix B: Message Flow Diagrams            B.4.1.2   SubscriptionVersion Create by the Initial SOA (New Service Provider)    In this scenario, the new service provider is the first to send the M-ACTION to create the subscriptionVersion object.  [Graphic Omitted: SubscriptionVersion Create by the Initial SOA]  Action is taken by the new service provider SOA to create a new subscription version.     1.   New service provider SOA sends M-ACTION subscriptionVersionNewSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The new service provider SOA must specify the following valid attributes:    subscriptionTN or a valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionNewSP-DueDate (seconds set to zero) subscriptionLNPType subscriptionPortingToOriginal-SP Switch         The following items must be provided unless subscriptionPortingToOriginal-SP is true:    subscriptionLRN subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionWSMSC-DPC — if supported by the Service Provider SOA subscriptionWSMSC-SSN — if supported by the Service Provider SOA subscriptionSVType – if supported by the Service Provider SOA         The following attributes are optional:    subscriptionEndUserLocationValue subscriptionEndUserLocationType subscriptionBillingId subscriptionAlternativeSPID – if supported by the Service Provider SOA         If the service provider were to give a range of TNs, this would result in an M-CREATE and M-EVENT-REPORT for each TN.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      112                   Appendix B: Message Flow Diagrams           If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. Other appropriate errors will also be returned.          If the subscriptionPortingToOriginal-SP is true, the new Service Provider ID MUST be the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block); if the SPIDs do not match the NPAC SMS will reject the request.      2.   If the request is valid, the NPAC SMS will create the subscriptionVersionNPAC object. The status will be set to “pending” and the subscriptionModifiedTimeStamp and subscriptionCreationTimeStamp will be set.      3.   NPAC SMS responds to M-CREATE.      4.   NPAC SMS sends action reply with success or failure and reasons for failure.      5.   If the M-ACTION was successful, NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M-EVENT-REPORT containing the following attributes to old service provider SOA of subscriptionVersionNPAC creation:    subscriptionVersionID subscriptionTN subscriptionOldSP subscriptionNewCurrentSP subscriptionNewSP-CreationTimeStamp subscriptionVersionStatus subscriptionNewSP-DueDate         If the notification is a subscriptionVersionRangeObjectCreation then the TN and SVID are the TN and SVID of the first TN in the range or list.      6.   Old service provider SOA responds by sending an M-EVENT-REPORT confirmation back to the NPAC SMS.      7.   If the M-ACTION was successful, NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an objectCreation or subscriptionVersionRangeObjectCreation M-EVENT-REPORT to new service provider SOA of subscriptionVersionNPAC creation.      8.   New service provider SOA issues an M-EVENT-REPORT confirmation to NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      113                   Appendix B: Message Flow Diagrams            B.4.1.2.1   Subscription Version Create by the Initial SOA (New Service Provider) (continued)    [Graphic Omitted: Subscription Version Create by the Initial SOA]         NPAC SMS decides if this subscription version is the first use of the NPA-NXX.      1.   If this is the first use of the NPA-NXX, the NPAC SMS sends the subscriptionVersionNewNPA-NXX M-EVENT-REPORT to inform the accepting Local SMSs.      2.   The Local SMS confirms the M-EVENT-REPORT.      3.   The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the Old SOA.      4.   The Old SOA confirms the M-EVENT-REPORT.      5.   The NPAC SMS sends the subscriptionVersionNew NPA-NXX M-EVENT-REPORT to inform the New SOA.      6.   The New SOA confirms the M-EVENT-REPORT.    The next scenario is either “SubscriptionVersion Create by the Second SOA (Old Service Provider).” or “SubscriptionVersion Activated by New Service Provider SOA”.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      114                   Appendix B: Message Flow Diagrams            B.4.1.3   SubscriptionVersion Create by Second SOA (New Service Provider)    In this scenario, the old service provider has already issued its request causing the subscriptionVersionNPAC to be created. The new service provider is now following with its own create action.  [Graphic Omitted: SubscriptionVersion Create by Second SOA]  New service provider SOA personnel take action to create a new subscription version.     1.   New service provider SOA sends M-ACTION subscriptionVersionNewSP-Create to NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The new service provider SOA must specify the following valid attributes:    subscriptionTN or a valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionNewSP-DueDate (seconds set to zeros) subscriptionLNPType subscriptionPortingToOriginal-SP Switch         The following items must be provided unless subscriptionPortingToOriginal-SP is true:    subscriptionLRN subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionWSMSC-DPC — if supported by the Service Provider SOA subscriptionWSMSC-SSN — if supported by the Service Provider SOA subscriptionSVType – if supported by the Service Provider SOA         The following attributes are optional:    subscriptionEndUserLocationValue  subscriptionEndUserLocationType  subscriptionBillingId  subscriptionAlternativeSPID – if supported by the Service Provider SOA         If a TN range is specified in the request, it would result in an M-SET request and M-EVENT-REPORT for each TN.          If the new service provider is not the new service provider specified in the initial create by the old service provider, an accessDenied error will be returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      115                   Appendix B: Message Flow Diagrams           If the subscriptionPortingToOriginal-SP is true, the new Service Provider ID MUST be the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block); if the SPIDs do not match the NPAC SMS will reject the request.          If any attribute is invalid, an action failure will be returned, indicating invalidArgumentValue. Other appropriate errors will be returned.          If the due date for the port is a previous date, the NPAC SMS accepts a value of a previous date from a service provider, in order to match the due date of the port that was previously received from the Old Service Provider.      2.   If successful, the NPAC SMS sets the subscriptionModifiedTimeStamp, subscriptionCreationTimeStamp, and all data specified in the M-ACTION.      3.   NPAC SMS responds to M-SET.      4.   NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.      5.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT with the following attributes to the old service provider when the subscriptionNewSP-DueDate changes value.    subscriptionNewSP-DueDate subscriptionNewSP-CreationTimeStamp     6.   Old service provider SOA issues M-EVENT-REPORT confirmation.      7.   If the M-ACTION was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the new service provider for all attributes updated from the preceding list of modifiable attributes in addition to the following:    subscriptionNewSP-DueDate subscriptionNewSP-CreationTimeStamp     8.   New service provider SOA issues M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      116                   Appendix B: Message Flow Diagrams            B.4.1.4   SubscriptionVersion Create by Second SOA (Old Service Provider) with Authorization to Port    In this scenario, the new service provider has already issued its request causing the subscriptionVersionNPAC to be created. The old service provider is now following with its own create action authorizing the port.  Note: This is an optional step.  [Graphic Omitted: SubscriptionVersion Create by Second SOA]  Old service provider SOA personnel take action to create a old subscription version.     1.   Old service provider SOA sends M-ACTION subscriptionVersionOldSP-Create to NPAC SMS lnpSubscriptions object to create an old subscriptionVersionNPAC. The old service provider SOA must specify the following valid attributes:    subscriptionTN or a valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionOldSP-Authorization subscriptionOldSP-DueDate (seconds set to zeros) subscriptionLNPType         If a TN range is specified in the request, it would result in an M-SET request and M-EVENT-REPORT for each TN.          If the old service provider is not the old service provider specified in the initial create request by the new service provider, an accessDenied error will be returned.          If any attribute is invalid, an invalidArgumentValue will be returned, indicating invalid data values. Other appropriate errors will also be returned.          If the due date for the port is a previous date, the NPAC SMS accepts a value of a previous date from a service provider, in order to match the due date of the port that was previously received from the New Service Provider.      2.   If the data is valid, the NPAC SMS sets the subscriptionOldSP-AuthorizationTimeStamp, subscriptionModifiedTimeStamp and all data specified in the M-ACTION.      3.   NPAC SMS responds to M-SET.      4.   NPAC SMS sends M-ACTION reply with success or failure and reasons for failure.      5.   If the M-ACTION was successful, the NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT attribute value change to the old service provider for all attributes updated from the following list:    subscriptionOldSP-DueDate subscriptionOldSP-Authorization subscriptionOldSP-AuthorizationTimeStamp     6.   Old service provider SOA issues M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      117                   Appendix B: Message Flow Diagrams       7.   If the M-ACTION was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT attribute value change to the new service provider for all attributes updated from the preceding list. The following attributes are sent in the attributeValueChangeNotification:    subscriptionOldSP-DueDate subscriptionOldSP-Authorization subscriptionOldSP-AuthorizationTimeStamp     8.   New service provider issues M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      118                   Appendix B: Message Flow Diagrams            B.4.1.5   SubscriptionVersion Activated by New Service Provider SOA    In this scenario, either both service providers have sent their create data updates for a new subscription version to the NPAC SMS or the concurrence window has expired for receiving the subscriptionVersionOldSP-Create action. The new service provider can now activate the subscription version.  [Graphic Omitted: SubscriptionVersion Activated by New Service Provider SOA]     1.   The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.            Note:   When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.       2.   NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending,” subscriptionVersionActivationTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC object.       3.   NPAC SMS responds to the M-SET.      4.   The NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (accessDenied) or if there is no version to be activated (invalidArgumentValue) or if any other failures occur.      5.   NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending,” subscriptionBroadcastTimeStamp on the subscriptionVersionNPAC object.      6.   NPAC SMS responds to the M-SET.    For inter-Service Provider subscription versions that are not being ported to the original service provider’s switch, and ALL intra-Service Provider subscription versions, processing continues in the Flow B.5.1.6.1 — Active SubscriptionVersion Create on Local SMSs Using Create Action .  For inter-Service Provider ports to the original service provider’s switch, follow Flows B.5.1.12 – ‘Inter-Service Provider Subscription Version Port-to-Original: Successful’ and B.5.1.12.1 – ‘Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)’.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      119                   Appendix B: Message Flow Diagrams            B.4.1.6   Active SubscriptionVersion Create on Local SMS    This scenario and associated error scenarios reflect the message flow for all new object create requests from the NPAC SMS to the Local SMSs.  [Graphic Omitted: Active SubscriptionVersion Create on Local SMS]  NPAC SMS has a new subscriptionVersion with a status of “sending.”     1.   The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs, that is accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   Each Local SMS will reply to the M-CREATE.          NPAC SMS waits for Local SMSs to respond successfully to the M-CREATE request.      3.   If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the old service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.      4.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the new service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.      6.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   If this TN has been previously ported (i.e., a previously active subscriptionVersionNPAC object exists), the NPAC SMS will issue, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notification to the old service provider SOA for the previously active subscriptionVersionNPAC object of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.      8.   The old service provider SOA for the previously active subscriptionVersionNPAC object returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      120                   Appendix B: Message Flow Diagrams            B.4.1.6.1   Active Subscription Version Create on Local SMS Using Create Action    This scenario reflects the message flow for all new object create requests from the NPAC SMS to the Local SMS Using Create Action. This action is used to create a group of subscription versions with the same routing information.  [Graphic Omitted: Active Subscription Version Create on Local SMS Using Create Action]  NPAC SMS has one or more subscription versions with a status of “sending ” that have been activated by the new service provider.     1.   NPAC SMS issues the subscriptionVersionLocalSMS-Create action to the Local SMS, if it is accepting downloads for the NPA-NXX of the subscriptionVersion. This action contains all data necessary to create the subscription version.          The Local SMS verifies the action is valid, but does not attempt to create the subscription version(s).      2.   The Local SMS responds to the M-ACTION.          The Local SMS proceeds to execute all the creates specified by the action.      3.   The Local SMS sends to the NPAC SMS the M-EVENT-REPORT specifying the success or failure of the creates.      4.   NPAC SMS confirms the M-EVENT-REPORT.          NPAC SMS waits for all responses a tunable amount of time. The default is 1 hour.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó1997 — 2006 NeuStar, Inc.      121                   Appendix B: Message Flow Diagrams            B.4.1.6.2   SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window    This scenario shows no response within “Service Provider Concurrence Window” by the old service provider SOA.  In this case, the new service provider SOA issued the create request. The NPAC SMS has issued the ObjectCreation M-EVENT-REPORT back to both the old and new service provider SOAs. No response has yet been received by the old service provider SOA.  [Graphic Omitted: SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Concurrence Window]         NPAC SMS does not receive a response from the old service provider SOA within “Service Provider Concurrence Window” for the pending subscriptionVersionNPAC created by the new service provider SOA.      1.   NPAC SMS sends the old service provider, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionOldSP-ConcurrenceRequest or subscriptionVersionRangeOldSP-ConcurrenceRequestM-EVENT-REPORT .      2.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          Old service provider has up to “Service Provider Concurrence Failure Window” to respond to the request.          If the old service provider SOA responds with a valid M-ACTION or M-SET, processing resumes as a successful create.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3Ó 1997 — 2006 NeuStar, Inc.      122                   Appendix B: Message Flow Diagrams            B.4.1.6.3   SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window    This scenario shows no response within “Service Provider Final Concurrence Window” by the old service provider SOA.  In this case, the new service provider SOA issued the create request. The NPAC SMS has issued the ObjectCreation M-EVENT-REPORT back to both the old and new service provider SOAs as well as a subsciptionVersionOldSP-ConcurrenceRequest M-EVENT-REPORT to the old service provider SOA. No response has yet been received by the old service provider SOA.  [Graphic Omitted: SubscriptionVersion Create: No Create Action from the Old Service Provider SOA After Final Concurrence Window]         NPAC SMS does not receive a response from the old service provider SOA within “Service Provider Final Concurrence Window” for the pending subscriptionVersionNPAC created by the new service provider SOA.      1.   NPAC SMS sends the old service provider, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionOldSPFinalConcurrenceWindowExpiration or subscriptionVersionRangeOldSPFinalConcurrenceWindowExpiration       M-EVENT-REPORT.      2.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          If the old service provider SOA responds with a valid       M-ACTION or M-SET prior to activation by the new service provider, the subscription version will be updated.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      123                   Appendix B: Message Flow Diagrams            B.4.1.6.4   Subscription Version Create: Failure to Receive Response from New SOA    This scenario shows the process of the NPAC SMS after not receiving any concurrence from the new service provider after the “Final Service Provider Concurrence Window.”  The subscription version remains in the NPAC SMS with a status of pending.  [Graphic Omitted: Subscription Version Create: Failure to Receive Response from New SOA]         NPAC SMS receives no concurrence from the new service provider SOA in “Service Provider Concurrence Window” for the pending subscriptionVersionNPAC created by the old service provider SOA.      1.   NPAC SMS notifies the old service provider, if they support the notification according to their NPAC Customer No New SP Concurrence Notification Indicator in their service provider profile on the NPAC SMS, of the expiration of the final create window where the new service provider did not send up a Create action for this subscription version, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionNewSP-FinalCreateWindowExpiration or subscriptionVersionRangeNewSP-FinalCreateWindowExpiration M-EVENT-REPORT.      2.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      3.   NPAC SMS notifies the new service provider, if they support the notification according to their NPAC Customer No New SP Concurrence Notification Indicator in their service provider profile on the NPAC SMS, of the expiration of the final create window where the new service provider did not send up a Create action for this subscription version, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionNewSP-FinalCreateWindowExpiration or subscriptionVersionRangeNewSP-FinalCreateWindowExpiration M-EVENT-REPORT.      4.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      124                   Appendix B: Message Flow Diagrams            B.4.1.6.5   SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window    This scenario shows no response within “Service Provider Concurrence Window” by the new service provider SOA.  In this case, the oldservice provider SOA issued the create request. The NPAC SMS has issued the ObjectCreation M-EVENT-REPORT back to both the old and new service provider SOAs. No response has yet been received by the new service provider SOA.  [Graphic Omitted: SubscriptionVersion Create: No Create Action from the New Service Provider SOA After Concurrence Window]  NPAC SMS does not receive a response from the new service provider SOA within “Service Provider Concurrence Window” for the pending subscriptionVersionNPAC created by the old service provider SOA.       1.   NPAC SMS sends the new service provider, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionNewSP-CreateRequest or subscriptionVersionRangeNewSP-CreateRequest M-EVENT-REPORT .        2.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.    New service provider has up to “Service Provider Final Concurrence Window” to respond to the request.  If the new service provider SOA responds with a valid M-ACTION or M-SET, processing resumes as a successful create.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      125                   Appendix B: Message Flow Diagrams                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      126                   Appendix B: Message Flow Diagrams            B.4.1.7   SubscriptionVersionCreate M-CREATE Failure to Local SMS    This scenario shows a failure to all of the Local SMS on M-CREATE.  [Graphic Omitted: SubscriptionVersionCreate M-CREATE Failure to Local SMS]         The new service provider SOA has activated the pending subscription.      1.   The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs, that is accepting downloads for the NPA-NXX of the subscriptionVersion.          NPAC SMS waits for responses from each Local SMS.          NPAC SMS resends to each Local SMS up to a tunable number of retries at a tunable interval.          No responses occur from any Local SMS or all Local SMSs report a failure response to the M-CREATE.      2.   NPAC SMS issues M-SET to update the subscriptionVersionStatus to “failed” in the subscriptionVersionNPAC object, the subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.      3.   NPAC SMS issues M-SET response.      4.   If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change.      5.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      6.   If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change.      7.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      127                   Appendix B: Message Flow Diagrams            B.4.1.8   SubscriptionVersion M-CREATE: Partial Failure to Local SMS    This scenario shows a partial failure to a Local SMS on an M-CREATE.  [Graphic Omitted: SubscriptionVersion M-CREATE: Partial Failure to Local SMS]  The new service provider SOA has activated the pending subscription.     1.   The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs, that is accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   One or more Local SMSs respond to the M-CREATE.          NPAC SMS waits for responses from each Local SMS.          NPAC SMS resends, to each unresponsive Local SMS, up to a tunable number of retries at a tunable interval.          No responses occur from at least one Local SMS, or a Local SMS returns an M-CREATE failure.      3.   NPAC SMS issues M-SET to the subscriptionVersionStatus to “partial-failure” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.      4.   NPAC SMS issues M-SET response.      5.   If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.      6.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      128                   Appendix B: Message Flow Diagrams            B.4.1.9   Create Subscription Version: Resend Successful to Local SMS Action    This scenario shows the successful resend of a subscription version create. The resend of a failed subscription version create can only be performed by authorized NPAC personnel.  [Graphic Omitted: Create Subscription Version: Resend Successful to Local SMS Action]         NPAC personnel take action to resend a failed subscriptionVersion create.      1.   The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs that previously failed, and is accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   Each Local SMS will reply to the M-CREATE.          NPAC SMS waits for all Local SMSs to report successful subscription version creation.      3.   NPAC SMS issues M-SET to update the subscriptionVersionStatus to “active” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.      4.   NPAC SMS issues M-SET response.      5.   If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the old service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.      6.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   If the subscriptionVersionNPAC object was modified, the NPAC SMS will issue, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT notifications to the new service provider SOA of the status change using an M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      129                   Appendix B: Message Flow Diagrams            B.4.1.10   Subscription Version: Resend Failure to Local SMS    This scenario shows a failure on a resend of a Subscription Version M-CREATE a Local SMS. The resend of a failed version can only be performed by authorized NPAC SMS personnel.  [Graphic Omitted: Subscription Version: Resend Failure to Local SMS]  The NPAC personnel issues a resend for the failed or partially failed subscriptionVersion.     1.   The NPAC SMS issues an M-CREATE for the subscriptionVersion to each of the Local SMSs for which the M-CREATE previously failed, and is accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   One or more Local SMSs respond to the M-CREATE.          NPAC SMS waits for responses from each Local SMS.          NPAC SMS resends, to each unresponsive Local SMS, up to a tunable number of retries at a tunable interval.          No responses occur from at least one or all Local SMSs, or one or all Local SMSs return an M-CREATE failure.      3.   NPAC SMS issues M-SET to the subscriptionVersionStatus to “partial-failure” or “failed” in the subscriptionVersionNPAC object, subscriptionFailed-SP-List, and the subscriptionModifiedTimeStamp.      4.   NPAC SMS issues M-SET response.      5.   If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.      6.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   If the subscriptionVersionNPAC was modified, the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      130                   Appendix B: Message Flow Diagrams            B.4.1.11   SubscriptionVersion Create for Intra-Service Provider Port    This scenario shows how an intra-service port is processed.  [Graphic Omitted: SubscriptionVersion Create for Intra-Service Provider Port]  Action is taken by the current provider SOA to create a new version of a subscriber.     1.   Current provider SOA sends M-ACTION subscriptionVersionNewSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC. The SOA must specify the following valid attributes:    subscriptionTN or a valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionNewSP-DueDate (seconds set to zeros) subscriptionPortingToOriginal-SPSwitch  The following items must be provided unless subscriptionPortingToOriginal-SP is true:  subscriptionLRN subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionLNPType subscriptionWSMSC-DPC — if supported by the Service Provider SOA subscriptionWSMSC-SSN — if supported by the Service Provider SOA subscriptionSVType – if supported by the Service Provider SOA  If the subscriptionPortingToOriginal-SP is true, the subscriptionNewCurrentSP must be equal to the subscriptionOldSP. If the new Service Provider Id is NOT the same as the Code Holder for the TN (or Block Holder if the TN is part of a Number Pool Block) in a “Port to Original” subscription version request then the NPAC SMS will fail the request.  The following attributes are optional:  subscriptionEndUserLocationValue subscriptionEndUserLocationType subscriptionBillingId subscriptionAlternativeSPID – if supported by the Service Provider SOA                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      131                   Appendix B: Message Flow Diagrams       2.   If the request is valid, the NPAC SMS will M-CREATE the subscriptionVersionNPAC object. The status will be set to “pending.” Also the subscriptionNewSP-CreationTimeStamp, and the subscriptionModifiedTimeStamp will be set.      3.   NPAC SMS responds to M-CREATE.      4.   NPAC SMS sends an action reply with success or failure and reasons for failure. If the action fails, no modifications are applied and processing stops for this scenario.      5.   NPAC SMS notifies intra-service provider SOA of the subscriptionVersionNPAC creation by sending, depending upon the service provider’s TN Range Notification Indicator, either a object creation or subscriptionVersionRangeObjectCreation notification.      6.   Service provider SOA sends M-EVENT-REPORT confirmation to NPAC SMS.          The intra-service subscriptionVersion now follows the same flow as an inter-service subscriptionVersionCreation and activation on the NPAC SMS and creation on the Local SMSs. (refer to flow B.5.1.5, Subscription Version Activated by New Service Provider SOA, for activation on the NPAC SMS and flow B.5.1.6, Active Subscription Version Create on Local SMS, for creation on the Local SMSs.          The only difference is the M-EVENT-REPORT for the subscriptionVersionStatusAttributeValueChange is only sent to the new provider.    NOTE: If this Intra- Service Provider port request is a port-to-original request, follow flows B.5.1.12 and B.5.1.12.1 for successful activate.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      132                   Appendix B: Message Flow Diagrams                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      133                   Appendix B: Message Flow Diagrams            B.4.1.12   SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Successful    This scenario shows how port-to-original (successful) port is processed and applies to both Intra- and Inter- Service Provider port-to-original requests.  [Graphic Omitted: SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Successful]         SV 1 is the currently active Subscription Version.          SV 2 is the current pending Subscription Version.      1.   The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.    Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.    2.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.      3.   NPAC SMS response to the M-SET.      4.   The NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (accessDenied) or if there is no version to be activated (invalidArgumentValue) or if any other failures occur.      5.   The NPAC SMS sets the subscriptionVersionStatus to sending and sets the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      6.   NPAC SMS response to the M-SET.      7.   NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.      8.   Each Local SMS responds with a successful M-DELETE reply.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      134                   Appendix B: Message Flow Diagrams            B.4.1.12.1   Inter-Service Provider Subscription Version Port-to-Original: Successful (continued)    [Graphic Omitted: Inter-Service Provider Subscription Version Port-to-Original: Successful]         All Local SMSs respond successfully.      1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA of SV1,depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      135                   Appendix B: Message Flow Diagrams            B.4.1.12.2   Intra-Service Provider Subscription Version Port-to-Original: Successful (continued)    [Graphic Omitted: Intra-Service Provider Subscription Version Port-to-Original: Successful]         All Local SMSs respond successfully.      1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA of SV1,depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      136                   Appendix B: Message Flow Diagrams       B.4.1.13 | SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: All LSMSs Fail    This scenario shows how a port-to-original (all fail) port is processed and applies to both Intra- and Inter- Service Provider port-to-original requests  [Graphic Omitted: SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: All LSMSs Fail]         SV 1 is the currently active Subscription Version.          SV 2 is the current pending Subscription Version.      1.   The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.    Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.    2.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.      3.   NPAC SMS response to the M-SET.      4.   NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (accessDenied) or if there is no version to be activated (invalidArgumentValue) or if any other failures occur.      5.   The NPAC SMS sets the subscriptionVersionStatus to sending and sets the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      6.   NPAC SMS response to the M-SET.      7.   NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.          NPAC SMS waits for a response from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from all Local SMSs.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      137                   Appendix B: Message Flow Diagrams            B.4.1.13.1   Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)    [Graphic Omitted: Inter-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)]  All Local SMSs have either failed to respond or responded with an error to the M-DELETE request.     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to active.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to active on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to failed. It also sets the subscriptionFailed-SP-List.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2, along with the subscriptionFailed-SP-List.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2, along with the subscriptionFailed-SP-List.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.          NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.          NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      138                   Appendix B: Message Flow Diagrams            B.4.1.13.2   Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)    [Graphic Omitted: Intra-Service Provider Subscription Version Port-to-Original: All LSMSs Fail (continued)]  All Local SMSs have either failed to respond or responded with an error to the M-DELETE request.     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to active.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to active on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to failed. It also sets the subscriptionFailed-SP-List.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2, along with the subscriptionFailed-SP-List.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.          NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.          NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      139                   Appendix B: Message Flow Diagrams            B.4.1.14   SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Partial Failure    This scenario shows how a port-to-original (partial fail) port is processed and applies to both Intra- and Inter- Service Provider port-to-original requests  [Graphic Omitted: SubscriptionVersion for Inter- and Intra- Service Provider Port-to-Original: Partial Failure]         SV 1 is the currently active Subscription Version.          SV 2 is the current pending Subscription Version.      1.   The new service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs.    Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.    2.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.      3.   NPAC SMS response to the M-SET.      4.   The NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (accessDenied) or if there is no version to be activated (invalidArgumentValue) or if any other failures occur.      5.   The NPAC SMS sets the subscriptionVersionStatus to sending and sets the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      6.   NPAC SMS response to the M-SET.      7.   NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.          NPAC SMS waits for a response from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from at least one, but not each, Local SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      140                   Appendix B: Message Flow Diagrams            B.4.1.14.1   Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)         [Gaphic Omitted: Inter-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)]     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionFailed-SP-List.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2, along with the subscriptionFailed-SP-List.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2, along with the subscriptionFailed-SP-List.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.          NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.          NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      141                   Appendix B: Message Flow Diagrams            B.4.1.14.2   Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)    [Graphic Omitted: Intra-Service Provider Subscription Version Port-to-Original: Partial Failure (continued)]     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA of SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionFailed-SP-List.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2, along with the subscriptionFailed-SP-List.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.          NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.          NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      142                   Appendix B: Message Flow Diagrams            B.4.1.15   SubscriptionVersion Port-to-Original: Resend    This scenario shows how a port-to-original (resend) port is processed.  [Graphic Omitted: SubscriptionVersion Port-to-Original: Resend]         SV 1 is the currently active Subscription Version.          SV 2 is the current pending Subscription Version.      1.   NPAC personnel take action to resend a failed port-to-original for a subscription version.      2.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      3.   NPAC SMS responds to the M-SET.      4.   The NPAC SMS sets the subscriptionVersionStatus to sending on the subscriptionVersionNPAC on SV2.      5.   NPAC SMS response to the M-SET.      6.   NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs that previously failed, that are accepting downloads for the NPA-NXX of the subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation may be sent.          Each previously failed Local SMS responds with a successful M-DELETE reply.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      143                   Appendix B: Message Flow Diagrams            B.4.1.15.1   Subscription Version Port-to-Original: Resend (continued)    [Graphic Omitted: Subscription Version Port-to-Original: Resend (continued)]         All previously failed Local SMSs respond successfully.      1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      4.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      144                   Appendix B: Message Flow Diagrams            B.4.1.16   SubscriptionVersion Port-to-Original: Resend Failure to Local SMS    This scenario shows a failure on a resend of a subscription port-to-original that failed previously to one or more of the Local SMSs. The resend of a failed port-to-original for a subscription can only be performed by authorized NPAC personnel.  [Graphic Omitted: SubscriptionVersion Port-to-Original: Resend Failure to Local SMS]         SV 1 is the currently active Subscription Version.          SV 2 is the current pending Subscription Version.          NPAC personnel take action to resend a failed port-to-original for a subscription version.      1.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      2.   NPAC SMS response to the M-SET.      3.   The NPAC SMS sets the subscriptionVersionStatus to sending on the subscriptionVersionNPAC on SV2.      4.   NPAC SMS response to the M-SET.      5.   NPAC SMS sends out an M-DELETE on the subscription Version SV1 to all Local SMSs that previously failed, that are accepting downloads for the NPA-NXX of the subscription Version SV1. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation may be sent.          NPAC SMS waits for a response from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from at least one Local SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      145                   Appendix B: Message Flow Diagrams            B.4.1.16.1   SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)    [Graphic Omitted: SubscriptionVersion Port-to-Original: Resend Failure to Local SMS (continued)]     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to “old” or “active” (if all Local SMSs accepting download for the NPA-NXX failed) from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.      2.   NPAC SMS responds to the M-SET.      3.   The NPAC SMS sends to the current/new service provider SOA, depending upon the new/current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to “old” or “active” on SV1.      4.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionFailed-SP-List.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to “partially failed” or “failed” on SV2, along with the subscriptionFailed-SP-List.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the current/new service provider SOA, depending upon the current/new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to “partially failed” or “failed” on SV2, along with the subscriptionFailed-SP-List.      10.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.          NOTE: SV1 may exist as an old SV that may be associated with SV2 that is in a “partially failed” state for a port to original port. In this case, the housekeeping process should not purge SV1 unless SV2 is also being purged.          NOTE: SV1 and SV2 should be updated to the NPA-NXX for a NPA Split if SV2 is in a “failed” or “partially failed” state.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      146                   Appendix B: Message Flow Diagrams            B.4.1.17   Port-To-Original Subscription Version Flows for Pooled TNs    This section contains Port-to-Original flows whose subscription version TNs are part of a pooled block and therefore the behavior of these scenarios is different than normal Port-to-Original subscription version processing.          B.4.1.17.1   Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA (previously NNP flow 3.1.1)    The following scenarios show the broadcast of a Port-to-Original subscription version that is successfully sent to all of the Local SMSs. In this scenario:       •   SV1 is the currently active Subscription Version.        •   SV2 is the current pending Subscription Version with the Port-To-Original flag set to TRUE.        •   SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.    The creation of a port-to-original request will be rejected if the block holder service provider and new service provider are not the same and if the TN is part of a pooled TN range.  This scenario shows the activation by the new service provider SOA and the update to ‘sending’ of the 3 subscription versions.  [Graphic Omitted: Subscription Version Port-to-Original of a Ported Pool TN Activation by SOA]     1.   The new, block holder service provider SOA issues a subscriptionVersionActivate M-ACTION to the NPAC SMS lnpSubscriptions object to activate the pending subscription version SV2 by specifying the subscription version ID, subscription version TN, or a range of subscription version TNs that are within the block.    Note: When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionActivateWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.    2.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      3.   NPAC SMS responds to the M-SET.      4.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.      5.   NPAC SMS responds to the M-SET.      6.   The NPAC SMS issues an M-CREATE request for SV3 and the subscriptionVersionStatus is set to “sending”, the subscriptionLNPType is set to ‘pool’, the subscriptionActivationTimeStamp, subscriptionCreationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp are set to the current date and time. All routing information originates from the numberPoolBlock that exists for the specified TN(s).      7.   NPAC SMS responds to the M-CREATE.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      147                   Appendix B: Message Flow Diagrams       8.   The NPAC SMS responds with the M-ACTION response. An error will be returned if the service provider is not the new service provider (soa-not-authorized) or if there is no version to be activated (no-version-found) or if any other failures occur (invalid-data-values, failed).                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      148                   Appendix B: Message Flow Diagrams            B.4.1.17.2   Successful Broadcast of Port-to-Original Activation Request for a Pooled TN (previously NNP flow 3.1.2)    The NPAC SMS has the port-to-original request of a pooled TN in sending mode. In this scenario, the broadcasts begin.  [Graphic Omitted: Successful Broadcast of Port-to-Original Activation Request for a Pooled TN]     1.   NPAC SMS issues the M-DELETE for SV1 to the EDR Local SMS that are accepting downloads for the NPA-NXX. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version. If the EDR Local SMS fails to respond, the NPAC SMS will retry the M-DELETE request a tunable amount of times.      2.   At the same time as step 1, the NPAC SMS sends out an M-CREATE on the subscription version SV3 to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX of subscription Version SV3. If the create is for multiple subscription versions, the M-ACTION subscriptionVersionLocalSMS-Create will be used instead. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of ‘pool’. If the non-EDR Local SMS fails to respond, the NPAC SMS will retry the M-CREATE request a tunable amount of times.      3.   The EDR Local SMS responds to the M-DELETE.      4.   Each non-EDR Local SMS responds to the M-CREATE.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      149                   Appendix B: Message Flow Diagrams            B.4.1.17.3   Successful Broadcast Complete NPAC SMS Updates for a Port-to-Original Request for a Pooled TN (previously NNP flow 3.1.3)    In this scenario, the NPAC SMS has successfully completed the broadcast of the port-to-original of a pooled TN. The NPAC SMS now updates the status of the subscription versions on the NPAC SMS.  All Local SMSs respond successfully to the port-to-original broadcast of a pooled TN.  [Graphic Omitted: Successful Broadcast Complete NPAC SMS Updates for a Port-to-Original Request for a Pooled TN]     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to active. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionDisconnectCompleteTimeStamp and subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      12.   The current/new, block holder service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.    After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      150                   Appendix B: Message Flow Diagrams            B.4.1.17.4   Subscription Version Create Port-to-Original of a Pool TN: Failure Broadcast to All Local SMSs (previously NNP flow 3.2.1)    This scenario shows the broadcast of a Port-to-Original subscription version that fails to all of the Local SMSs.       •   SV1 is the active Subscription Version.        •   SV2 is the pending Subscription Version with the Port to Original flag set to TRUE.        •   SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.    In this scenario, the NPAC SMS has the required subscription versions in a ‘sending’ state. The NPAC SMS begins the broadcast.  [Graphic Omitted: Subscription Version Create Port-to-Original of a Pool TN: Failure Broadcast to All Local SMSs]     1.   NPAC SMS issues the M-DELETE for SV1 to the EDR Local SMS. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version.       2.   At the same time as step 1, the NPAC SMS sends out an M-CREATE on subscription version SV3 to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX of subscription Version SV3. If the create is for multiple subscription versions, the M-ACTION subscriptionVersionLocalSMS-Create will be used instead. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of “pool”.    The NPAC SMS waits for a response from all Local SMSs (EDR and non-EDR).  The NPAC SMS retries any Local SMS that has not responded successfully.  No response or an error is received from all of the EDR and non-EDR Local SMSs.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      151                   Appendix B: Message Flow Diagrams            B.4.1.17.5   Updates to NPAC SMS after Failure of Port-to-Original Broadcast for a Pooled TN (previously NNP flow 3.2.2)    The NPAC SMS has just completed an unsuccessful broadcast to the LSMSs of a port-to-original of a pooled TN. The NPAC SMS now proceeds to update the status on the NPAC SMS.  [Graphic Omitted: Updates to NPAC SMS after Failure of Port-to-Original Broadcast for a Pooled TN]  None of the non-EDR Local SMSs has responded successfully to the M-CREATE request for SV3 nor have any of the EDR Local SMSs responded successfully to the M-DELETE for SV1.     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to failure and the subscriptionModifiedTimeStamp is also set to the current date and time.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to active. It also sets the subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to failed. It also sets the subscriptionModifiedTimeStamp to the current date and time and sets the subscriptionFailed-SP-List. The failed SP list contains the EDR and non-EDR Local SMSs who failed to receive the broadcast of SV1 and SV3.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1,, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to active on SV1.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to failed and the subscriptionFailed-SP-List for SV2.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   The NPAC SMS sends to the current/new, block holder service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to failed and the subscriptionFailed-SP-List for SV2.      12.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      152                                      Appendix B: Message Flow Diagrams            B.4.1.17.6    Port-to-Original Activation Partial Failure Broadcast of a Pooled TN (previously NNP flow 3.3.1)    This scenario shows the broadcast of a Port-to-Original subscription version that fails to one or more, but not all, of the Local SMSs.       •   SV1 is the active Subscription Version.        •   SV2 is the pending Subscription Version with the Port-To-Original flag set to TRUE.        •   SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.    The NPAC SMS has the port-to-original request of a pooled TN in sending mode. In this scenario, the broadcasts begin that will result in a partial failure.  [Graphic Omitted: Port-to-Original Activation Partial Failure Broadcast of a Pooled TN]     1.   NPAC SMS issues the M-DELETE to the EDR Local SMS for SV1. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version.       2.   NPAC SMS issues an M-CREATE on the subscription version SV3 to all non-EDR Local SMSs, that are accepting downloads for the NPA-NXX of subscription Version SV3. If the create is for multiple subscription versions, the M-ACTION subscriptionVersionLocalSMS-Create will be used instead. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of “pool”.       3.   The EDR Local SMS responds to the M-DELETE.      4.   Each non-EDR Local SMS responds to the M-CREATE.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      153                                      Appendix B: Message Flow Diagrams            B.4.1.17.7    Partial-Failure Broadcast Complete NPAC SMS Updates of a Port-to-Original for a Pooled TN (previously NNP flow 3.3.2)    In this scenario, the NPAC SMS has already performed the broadcast of the activation of the port-to-original activation. The broadcast resulted in a partial failure status. The NPAC SMS now updates the objects on the NPAC SMS.  [Graphic Omitted: Partial-Failure Broadcast Complete NPAC SMS Updates of a Port-to-Original for a Pooled TN]  At least one of the non-EDR Local SMSs has not responded successfully to the M-CREATE for SV3 and/or at least one of the EDR Local SMSs has not responded successfully to the M-DELETE for SV1.     1.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to partial failure. The subscriptionModifiedTimeStamp is also set to the current date and time.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the s subscriptionDisconnectCompleteTimeStamp and subscriptionModifiedTimeStamp to the current date and time.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionModifiedTimeStamp to the current date and time and sets the subscriptionFailed-SP-List. The failed list contains the both the EDR and non-EDR Local SMSs who did not complete the broadcast of SV1 and SV3 successfully.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to partially failed and the subscriptionFailed-SP-List for SV2.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange with the subscriptionVersionStatus being set to partially failed and the subscriptionFailed-SP-List for SV2.      12.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      154                                      Appendix B: Message Flow Diagrams            B.4.1.17.8    Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN (previously NNP flow 3.4.1)    This scenario shows how the successful resend of a failed port-to-original broadcast is processed. In this scenario the following subscription versions are used:       •   SV1 is the active Subscription Version.        •   SV2 is the partially failed or failed Subscription Version with the Port-To-Original flag set to TRUE.        •   SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder.    In this scenario, the NPAC SMS must resend the port-to-original request. Either at least 1 EDR LSMS failed to receive the M-DELETE for SV1 or at least 1 non-EDR LSMS failed to receive the M-CREATE for SV3. The NPAC SMS will resend the necessary operations to the failed LSMSs.  [Graphic Omitted: Port-to-Original NPAC SMS Initiates Successful Resend for a Pooled TN]     1.   The NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV2.      2.   NPAC SMS responds to the M-SET.      3.   If one of the failed LSMSs is an EDR LSMS, the NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV1.      4.   NPAC SMS responds to the M-SET.      5.   If one of the failed LSMSs is a non-EDR LSMS, the NPAC SMS issues an M-SET request setting the subscriptionVersionStatus to “sending”, the subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp on the subscriptionVersionNPAC on SV3.      6.   NPAC SMS responds to the M-SET.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      155                                      Appendix B: Message Flow Diagrams            B.4.1.17.9    Successful Resend Broadcast of a Port-to-Original of a Pooled TN (previously NNP flow 3.4.2)    The NPAC SMS has the necessary subscription versions in sending mode. It now broadcasts the data.  [Graphic Omitted: Successful Resend Broadcast of a Port-to-Original of a Pooled TN]     1.   If one of the failed Local SMSs is an EDR LSMS, the NPAC SMS issues the M-DELETE to the failed EDR Local SMS for SV1. The EDR Local SMS will revert back to using the routing information in the number pool block object for the TN in the subscription version.      2.   If one of the failed Local SMSs is a non-EDR LSMS, the NPAC SMS sends out an M-CREATE on the subscription version SV3 to the failed non-EDR Local SMSs that are accepting downloads for the NPA-NXX of subscription Version SV3. If the M-CREATE is for multiple subscription versions, a scoped and filtered operation will be sent. The SV3 created on the non-EDR Local SMS systems contains the default block routing information and has a LNP type of “pool”.      3.   If a request was sent, the EDR Local SMS responds to the M-DELETE.      4.   If a request was sent, the non-EDR Local SMS responds to the M-CREATE.    All previously failed Local SMSs respond successfully.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      156                                      Appendix B: Message Flow Diagrams            B.4.1.17.10    Updates to NPAC SMS after Successful Resend of Port-to-Original Request of a Pooled TN (previously NNP flow 3.4.3)    The NPAC SMS just successfully re-broadcasted the necessary updates to the Local SMS. It now updates the status of the objects on the NPAC SMS.  [Graphic Omitted: Updates to NPAC SMS after Successful Resend of Port-to-Original Request of a Pooled TN]     1.   If a resend to a non-EDR Local SMS was successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to active. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to the M-SET.      3.   If a resend to a EDR Local SMS was successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 to old. It also sets the subscriptionModifiedTimeStamp. If the subscription status was previously set to “failed”, the subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to old. It also sets the subscriptionModifiedTimeStamp.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1,, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV1.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to old on SV2.      12.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.    After a tunable amount of days, the subscription versions SV1 and SV2 are purged by the NPAC SMS housekeeping process.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      157                                      Appendix B: Message Flow Diagrams            B.4.1.17.11    Subscription Version Create Port-to-Original of a Pool TN: Resend Failure to Local SMS (previously NNP flow 3.5)    This scenario shows how the unsuccessful resend of a failed port-to-original broadcast is processed. In this scenario, the following subscription versions are used:       •   SV1 is the active Subscription Version.        •   SV2 is the failed Subscription Version with the Port-To-Original flag set to TRUE.        •   SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder and its current status is failed.    In the following scenario, the NPAC SMS must resend the port-to-original request. All the EDR LSMS failed to receive the M-DELETE for SV1 and all the non-EDR LSMSs failed to receive the M-CREATE for SV3. The NPAC SMS will resend the necessary operations to the failed LSMSs, but the resend will result in total failure again. The scenario would work just as a successful resend, except for when the NPAC SMS sets the final statuses on the NPAC SMS.  [Graphic Omitted: Subscription Version Create Port-to-Original of a Pool TN: Resend Failure to Local SMS]     1.   If all non-EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to failed. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to the M-SET.      3.   If all the EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 back to active. It also sets the subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 back to failed and setting the subscriptionFailed-SP-List to the list of all the service providers that failed to receive the broadcast successfully (EDR and non-EDR). It also sets the subscriptionModifiedTimeStamp.      6.   NPAC SMS responds to the M-SET.      7.   The NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set back to active on SV1.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2 with the subscriptionFailed-SP-List.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to failed on SV2 with the subscriptionFailed-SP-List.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      158                                      Appendix B: Message Flow Diagrams            12.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      159                                      Appendix B: Message Flow Diagrams            B.4.1.17.12    Subscription Version Create Port-to-Original of a Pool TN: Resend Partial Failure to Local SMS (previously NNP flow 3.6)    This scenario shows how the unsuccessful resend of a partially failed port-to-original broadcast is processed. In this scenario, the following subscription versions are used:       •   SV1 is the old Subscription Version.        •   SV2 is the partially failed Subscription Version with the Port-To-Original flag set to TRUE.        •   SV3 is the pool reinstatement Subscription Version with LNP type = Pool that reinstates default routing to the block holder and its current status is partially failed.    In the following scenario, the NPAC SMS must resend the port-to-original request. At least 1 of the EDR LSMSs failed to receive the M-DELETE for SV1 and/or at least 1 of the non-EDR LSMSs failed to receive the M-CREATE for SV3. The NPAC SMS will resend the necessary operations to the failed LSMSs, but the resend will result in partial failure again. The scenario would work just as a successful resend, except for when the NPAC SMS sets the final statuses on the NPAC SMS.  [Graphic Omitted: Subscription Version Create Port-to-Original of a Pool TN: Resend Partial Failure to Local SMS]     1.   If a resend of a non-EDR Local SMS was not successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV3 to partially failed. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to the M-SET.      3.   If a resend of an EDR Local SMS was not successful, the NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV1 back to old. It also sets the subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-SET updating the subscriptionVersionStatus of SV2 to partially failed. It also sets the subscriptionModifiedTimeStamp and setting the subscriptionFailed-SP-List to the list of all the service providers that failed to receive the broadcast successfully (EDR and non-EDR).      6.   NPAC SMS responds to the M-SET.      7.   If SV1 was updated, the NPAC SMS sends to the old service provider SOA, who is the current service provider on SV1, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set back to old on SV1.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   The NPAC SMS sends to the old service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2 and the subscriptionFailed-SP-List.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   The NPAC SMS sends to the current/new service provider SOA, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the subscriptionVersionStatus being set to partially failed on SV2 and the subscriptionFailed-SP-List.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      160                                      Appendix B: Message Flow Diagrams            12.   The current/new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      161                                      Appendix B: Message Flow Diagrams            B.4.1.17.13    Subscription Version Port-to-Original of a Pool TN – Creation Prior to NPA-NXX-X Effective Date (previously NNP flow 3.7)    In this scenario, the service provider SOA attempts to create a port-to-original request prior to the effective date of the corresponding serviceProvNPA-NXX-X object. The NPAC SMS will reject this request, as a port-to-original request can not be created prior to the effective date of the corresponding serviceProvNPA-NXX-X.  [Graphic Omitted: Subscription Version Port-to-Original of a Pool TN – Creation Prior to NPA-NXX-X Effective Date]  SOA personnel take action to create a port-to-original request.     1.   The new service provider SOA sends a valid, M-ACTION, subscriptionVersionNewSP-Create request with the subscriptionPortingToOriginal-SPSwitch set to ‘TRUE’ for a TN within a pooled block.       2.   NPAC SMS replies with an error, ‘soa-not-authorized’.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      162                                      Appendix B: Message Flow Diagrams            B.4.1.18    SubscriptionVersion Inter-Service Provider Create by either SOA (Old or New Service Provider) with a Due Date which is Prior to the NPA-NXX Effective Date – Error    In this scenario, the old or new service provider SOA attempts to create an inter-service provider port for a TN with no currently active subscription version, with a due date prior to the effective date of the corresponding serviceProvNPA-NXX object (of that TN). The NPAC SMS will reject this request, as an inter-service provider port cannot be created with a due date prior to the effective date of the corresponding serviceProvNPA-NXX.  [Graphic Omitted: SubscriptionVersion Inter-Service Provider Create by either SOA]  SOA personnel take action to create an inter-service provider port for a TN with a due date which is prior to the associated NPA-NXX (of that TN) Effective Date.     1.   The old or new service provider SOA attempts to create a new subscription version by sending a valid M-ACTION subscriptionVersionOldSP-Create (or NewSP-Create) request for a TN with a due date which is prior to the Effective Date for the respective NPA-NXX (of that TN).       2.   The NPAC SMS sends an error back to the originating SOA, ‘soa-not-authorized’.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      163                                      Appendix B: Message Flow Diagrams            B.4.2    Modify Scenarios      B.4.2.1    SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA    This scenario shows the modification of an active subscription. The modification of an active subscription version can be performed using an M-ACTION only by the current service provider SOA.  This scenario can only be performed when the subscriptionVersionStatus is active and the FailedSP-List is empty. If a Modify Active request is made for an active subscription version that has an entry in the FailedSP-List, the NPAC SMS will reject the request.  [Graphic Omitted: SubscriptionVersion Modify Active Version Using M-ACTION by a Service Provider SOA]  Action is taken by current service provider to modify an active subscription version by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified.  The current service provider can only modify the following attributes:  subscriptionLRN subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionWSMSC-DPC — if supported by the Service Provider SOA subscriptionWSMSC-SSN — if supported by the Service Provider SOA subscriptionEndUserLocationValue subscriptionEndUserLocationType subscriptionBillingId subscriptionSVType – if supported by the Service Provider SOA subscriptionAlternativeSPID-if supported by the Service Provider SOA     1.   Current service provider SOA issues M-ACTION ModifySubscriptionVersion to the NPAC SMS lnpSubscriptions object to update the active version. The NPAC SMS validates the data.      2.   If the M-ACTION data validates, NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionVersionStatus is updated to “sending,” the subscriptionBroadcastTimeStamp and subscriptionModifiedTimeStamp are set, and any other modified attributes are updated.      3.   NPAC SMS issues M-SET response indicating success or failure.      4.   NPAC SMS replies to the M-ACTION with success or failure and reasons for failure to the service provider SOA. If the action fails, no modifications are applied and processing stops. Failure reasons include accessDenied (not the current service provider) and invalidArgumentValue (validation problems).                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      164                                      Appendix B: Message Flow Diagrams            5.   NPAC SMS issues M-SET to all Local SMSs for the updated attributes, that are accepting downloads for the NPA-NXX of the subscriptionVersion. If the update involves multiple subscription version objects, a scoped and filtered request will be sent.      6.   Local SMSs reply to M-SET.          All Local SMSs have reported the object modification.          Failure scenarios for this modification follow the same rules for an objectCreation failure to the Local SMS. However, upon failure the version status is updated to “active” and the subscriptionFailedSP-List is updated to contain the name of the service providers for which the download fails.      7.   NPAC SMS issues M-SET to update the current subscriptionVersionNPAC object subscriptionVersionStatus to “active.”      8.   NPAC SMS responds to M-SET.      9.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current provider of the subscriptionVersionStatus update.      10.   Service provider SOA issues M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      165                                      Appendix B: Message Flow Diagrams            B.4.2.2    SubscriptionVersion Modify Active: Failure to Local SMS    This scenario shows the broadcast of a modified active subscription that fails to one or more of the Local SMSs.  [Graphic Omitted: SubscriptionVersion Modify Active: Failure to Local SMS]         The NPAC SMS has an active subscription version that has been successfully modified by the current service provider. The subscription version now has a status of “sending”.      1.   The NPAC SMS issues M-SET to all Local SMSs for the updated attributes, that are accepting downloads for the NPA-NXX of the subscriptionVersion.          Local SMSs should respond successfully to the M-SET.          NPAC SMS waits for responses from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from at least one Local SMS.      2.   NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “active” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMS that failed to successfully receive the broadcast.      3.   NPAC SMS responds to the M-SET.      4.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.      5.   The current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      166                                      Appendix B: Message Flow Diagrams            B.4.2.3    SubscriptionVersion Modify Prior to Activate Using M-ACTION    This scenario can only be performed when the subscriptionVersionStatus is conflict or pending.  NOTE: The flow for un-do of a cancel-pending subscription version is documented in the cancel section, B.5.3.5 Un-Do Cancel-Pending SubscriptionVersion Request.  [Graphic Omitted: SubscriptionVersion Modify Prior to Activate Using M-ACTION]         Action is taken by a service provider to modify a subscriptionVersion by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified.           The old service provider can only update the following attributes:    subscriptionOldSP-DueDate (seconds set to zeros) subscriptionOldSP-Authorization subscriptionStatusChangeCauseCode         NOTE: The subscriptionStatusChangeCauseCode can only be modified when the subscriptionOldSP-Authorization is set to FALSE, and, if provided, it’s ignored when the subscriptionOldSP-Authorization is set to TRUE.           The new service provider can only update the attributes:    subscriptionLRN subscriptionNewSP-DueDate (seconds set to zeros) subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionWSMSC-DPC — if supported by the Service Provider SOA subscriptionWSMSC-SSN — if supported by the Service Provider SOA subscriptionEndUserLocationValue subscriptionEndUserLocationType subscriptionBillingId subscriptionSVType – if supported by the Service Provider SOA subscriptionAlternativeSPID-if supported by the Service Provider SOA     1.   Service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the version. The NPAC SMS validates the data.       2.   If validation is successful, NPAC SMS will M-SET the attributes modified in the subscriptionVersionNPAC object and set the subscriptionModifiedTimeStamp.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      167                                      Appendix B: Message Flow Diagrams            3.   The NPAC SMS will issue an M-SET response.      4.   NPAC SMS replies to the M-ACTION with success or failure and reasons for failure.          Note: If the old service provider was the initiator of the M-ACTION that caused the subscription version status to change, the NPAC SMS would issue a subscriptionVersionStatusAttributeValueChange M-EVENT-REPORT to the old and new service provider SOAs.      5.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the old service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:            — subscriptionNewSP-DueDate            — subscriptionNewSP-CreationTimeStamp            — subscriptionOldSP-Authorization            — subscriptionOldSP-AuthorizationTimeStamp            — subscriptionStatusChangeCauseCode           In the event the modification request results in a change of status the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the old service provider SOA.       6.   The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.      7.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the new service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:             — subscriptionNewSP-DueDate             — subscriptionNewSP-CreationTimeStamp              — subscriptionOldSP-Authorization              — subscriptionOldSP-AuthorizationTimeStamp              — subscriptionStatusChangeCauseCode          In the event the modification request results in a change of status the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the new service provider SOA.      8.   The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      168                                      Appendix B: Message Flow Diagrams            B.4.2.4    SubscriptionVersion Modify Prior to Activate Using M-SET    This scenario shows a modify using an M-SET. The M-SET can only be performed when the subscriptionVersionStatus is conflict or pending.  [Graphic Omitted: SubscriptionVersion Modify Prior to Activate Using M-SET]         Action is taken by a service provider to modify the subscriptionVersion by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified. The old service provider can only update the following attributes:    subscriptionOldSP-DueDate (seconds set to zeros) subscriptionOldSP-Authorization subscriptionStatusChangeCauseCode         NOTE: The subscriptionStatusChangeCauseCode can only be modified when the subscriptionOldSP-Authorization is set to FALSE           The new service provider can only update the attributes:    subscriptionLRN subscriptionNewSP-DueDate (seconds set to zeros) subscriptionCLASS-DPC subscriptionCLASS-SSN subscriptionLIDB-DPC subscriptionLIDB-SSN subscriptionCNAM-DPC subscriptionCNAM-SSN subscriptionISVM-DPC subscriptionISVM-SSN subscriptionWSMSC-DPC — if supported by the Service Provider SOA subscriptionWSMSC-SSN — if supported by the Service Provider SOA subscriptionEndUserLocationValue subscriptionEndUserLocationType subscriptionBillingId subscriptionSVType – if supported by the Service Provider SOA subscriptionAlternativeSPID-if supported by the Service Provider SOA     1.   The new or old service provider SOA will issue an M-SET request for the attributes to be updated in the subscriptionVersionNPAC object. The request will be validated for an authorized service provider and validation of the attributes and values.       2.   The NPAC SMS will issue an M-SET response indicating success or failure and reasons for failure.           Note: If the old service provider was the initiator of the M-SET that caused the subscription version status to change, the NPAC SMS would issue a subscriptionVersionStatusAttributeValueChange M-EVENT-REPORT to the old and new service provider SOAs                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      169                                      Appendix B: Message Flow Diagrams            3.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the old service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:           — subscriptionNewSP-DueDate            — subscriptionNewSP-CreationTimeStamp            — subscriptionOldSP-Authorization            — subscriptionOldSP-AuthorizationTimeStamp            — subscriptionStatusChangeCauseCode          In the event the modification request results in a change of status the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the old service provider SOA.      4.   The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange M-EVENT-REPORT to the new service provider SOA. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast. Attribute value change notifications will be sent to both service provider SOAs when the following attribute values change for a pending, cancel-pending, conflict, or disconnect-pending subscription version:            — subscriptionNewSP-DueDate            — subscriptionNewSP-CreationTimeStamp            — subscriptionOldSP-Authorization            — subscriptionOldSP-AuthorizationTimeStamp            — subscriptionStatusChangeCauseCode          In the event the modification request results in a change of status the NPAC SMS will send, depending upon the new service provider’s TN Range Notification Indicator, a statusAttributeValueChange or a subscriptionVersionRangeStatusAttributeValueChange which includes the subscriptionVersionStatus to the new service provider SOA.      6.   The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      170                                      Appendix B: Message Flow Diagrams            B.4.2.5    Subscription Version Modify Active: Resend Successful to Local SMS    This scenario shows the successful resend of a modification of an active subscription. The resend of a failed modified active version can only be performed by authorized NPAC personnel.  [Graphic Omitted: Subscription Version Modify Active: Resend Successful to Local SMS]         Action is taken by NPAC personnel to resend the failed modified active version.      1.   NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionVersionStatus is updated to “sending”.      2.   NPAC SMS issues M-SET response indicating success or failure.      3.   NPAC SMS issues M-SET to all Local SMSs that previously failed for the updated attributes, and are accepting downloads for the NPA-NXX of the subscriptionVersion.      4.   Local SMSs reply to M-SET.          All Local SMSs have reported the object modification.      5.   NPAC SMS issues M-SET to update the current subscriptionVersionNPAC object subscriptionVersionStatus to “active.”      6.   NPAC SMS responds to M-SET.      7.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current provider of the subscriptionVersionStatus update.      8.   Service provider SOA issues M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      171                                      Appendix B: Message Flow Diagrams            B.4.2.6    Subscription Version Modify Active: Resend Failure to Local SMS    This scenario shows a failure on a resend of a modified active subscription that failed previously to one or more of the Local SMSs. The resend of a failed modified active version can only be performed by authorized NPAC personnel.  [Graphic Omitted: Subscription Version Modify Active: Resend Failure to Local SMS]         The NPAC SMS has an active subscription version that has been unsuccessfully modified by the current service provider. The NPAC personnel issues a resend for the failed modified version and the subscription version now has a status of “sending”.       1.   The NPAC SMS issues M-SET to all Local SMSs that previously failed for the updated attributes, and are accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   Local SMSs should respond successfully to the M-SET.      3.   NPAC SMS waits for responses from each Local SMS.      4.   NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from at least one or all Local SMSs.      5.   NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “active” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.      6.   NPAC SMS responds to the M-SET.      7.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.      8.   The current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      172                                      Appendix B: Message Flow Diagrams            B.4.2.7    SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA    This scenario shows the modification of a disconnect pending subscription. The modification of a disconnect pending subscription version can be performed using an M-ACTION only by the current service provider SOA.  [Graphic Omitted: SubscriptionVersion Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA]  Action is taken by current service provider to modify a disconnect pending subscription version by specifying the TN, TN range, and the version status, or by specifying the version ID of the subscription version to be modified; and the data to be modified.  The current service provider can only modify the following attributes:  subscriptionCustomerDisconnectDate subscriptionEffectiveReleaseDate     1.   Current service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the disconnect pending version. The NPAC SMS validates the data.      2.   If the M-ACTION data is valid, NPAC SMS issues M-SET to the subscriptionVersionNPAC. The subscriptionModifiedTimeStamp is set, and any other modified attributes are updated.      3.   NPAC SMS issues M-SET response indicating success or failure.      4.   NPAC SMS replies to the M-ACTION with success or failure and reasons for failure to the service provider SOA. If the action fails, no modifications are applied and processing stops. Failure reasons include accessDenied (not the current service provider) and invalidArgumentValue (validation problems).    If the newly modified ERD is the current date or a previous date, the NPAC will follow the “immediate disconnect” flow (B.5.4.1). Otherwise, the NPAC waits for the subscriptionEffectiveReleaseDate to arrive, at which point it will follow the “immediate disconnect” flow (B.5.4.1).                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      173                                      Appendix B: Message Flow Diagrams            B.4.3    Cancel Scenarios    A subscription version can be canceled when the current status is conflict, pending or disconnect pending.     B.4.3.1    SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred    In this scenario, the old service provider initiates the cancel after both the old and new service provider SOAs have issued their create actions. Once the new service provider SOA’s cancellation acknowledgment is received, the version status is set to “canceled”. Since the old service provider SOA initiated the cancel, its cancellation acknowledgment is optional.  [Graphic Omitted: SubscriptionVersion Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred]         Action is initiated by the old or new service provider SOA to cancel a subscription version by specifying the TN, TN range, or version ID of the subscription version to be canceled.       1.   Service provider SOA issues an M-ACTION subscriptionVersionCancel to the NPAC SMS to the lnpSubscriptions object.         Note:  When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionCancelWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.       2.   NPAC SMS issues M-SET to update subscriptionVersionStatus to “cancel-pending” in the subscriptionVersionNPAC object and the subscriptionModifiedTimeStamp.      3.   NPAC SMS issues M-SET response.      4.   NPAC SMS returns the M-ACTION reply. This either reflects a success or failure. Failure reasons are version in wrong state, no version to cancel, and authorization service provider. If successful, the subscriptionPre-CancellationStatus is set to the current subscriptionVersionStatus and then the subscriptionVersionStatus is set to “cancel-pending.” If the action fails, no modifications are applied and processing stops.      5.   Depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus change is sent from the NPAC SMS to the old service provider SOA.      6.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   Depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChangeM-EVENT-REPORT for the subscriptionVersionStatus change is sent from the NPAC SMS to the new service provider SOA.      8.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      174                                      Appendix B: Message Flow Diagrams            B.4.3.1.1    Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)    [Graphic Omitted: Subscription Version Cancel by Service Provider SOA After Both Service Provider SOAs Have Concurred (continued)]     1.   The old service provider SOA sends an M-ACTION subscriptionVersionOldSP-CancellationAcknowledge to the NPAC SMS lnpSubscription object. This acknowledges the cancellation of the subscriptionVersionNPAC with a status of cancel-pending.      Note:    When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionOldSP-CancellationAcknowledgeWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.      2.   The NPAC SMS issues M-SET for the subscriptionOldSP-CancellationTimeStamp in the subscriptionVersionNPAC object and subscriptionModifiedTimeStamp.      3.   NPAC SMS issues an M-SET response.      4.   NPAC SMS responds to the M-ACTION with either a success or failure and failure reasons. If the action fails, no modifications are applied.      5.   The new service provider SOA sends an M-ACTION subscriptionVersionNewSP-CancellationAcknowledge to the NPAC SMS lnpSubscriptions object.      Note:    When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionNewSP-CancellationAcknowledgeWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.      6.   The NPAC SMS issues M-SET for the subscriptionNewSP-CancellationTimeStamp, subscriptionModifiedTimeStamp, subscriptionCancellationTimeStamp, and subscriptionVersionStatus to “canceled.”      7.   NPAC SMS issues M-SET response.      8.   NPAC SMS replies to M-ACTION with success or failure and reasons for failure. If the action fails, no modifications are applied.      9.   If the last M-ACTION was successful, the NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus update to canceled to the old service provider SOA.      10.   If the last M-ACTION was successful, the old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus update to canceled to the new service provider SOA.      12.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      175                                      Appendix B: Message Flow Diagrams            B.4.3.2    SubscriptionVersionCancel: No Acknowledgment from a SOA    The NPAC SMS has set the status of the subscription version to “cancel-pending” upon request of the old SOA. It is now waiting for the acknowledgments from both service provider SOAs. Acknowledgment from the old SOA is optional. In this scenario the new service provider does not respond.  [Graphic Omitted: SubscriptionVersionCancel: No Acknowledgment from a SOA]         NPAC SMS is waiting for the cancellation acknowledgments from both service provider SOAs.      1.   The old service provider SOA sends a subscriptionVersionOldSP-CancellationAcknowledge M-ACTION to the NPAC SMS lnpSubscriptions object. This acknowledges the cancellation of the subscriptionVersionNPAC with a status of cancel-pending.      Note:    When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionOldSP-CancellationAcknowledgeWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.      2.   NPAC SMS issues M-SET for the subscriptionOldSP-CancellationTimeStamp and subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.      3.   NPAC SMS responds to M-SET.      4.   NPAC SMS replies to the M-ACTION with either a success or failure and failure reasons. If the action fails, no modifications are applied and processing stops.          The NPAC SMS waits for the cancellation acknowledgment from the new service provider SOA. No reply is received after a tunable period.      5.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionCancellationAcknowledgeRequest or subscriptionVersionRangeCancellationAcknowledgeRequest M-EVENT-REPORT to the unresponsive new service provider SOA.      6.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          The “Service Provider Concurrence Cancellation Window” has expired and still no cancellation acknowledgment is received from the new service provider.      7.   NPAC SMS issues M-SET to update the subscriptionVersionStatus to conflict and the subscriptionConflictTimeStamp and subscriptionModifiedTimeStamp are set.      8.   NPAC SMS issues M-SET response.      9.   The NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORTto the old service provider SOA.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      176                                      Appendix B: Message Flow Diagrams            11.   The NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORTto the new service provider SOA.      12.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      13.   The NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider SOA.      14.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      15.   The NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider SOA.      16.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.          At this point, the flow follows the conflict resolution scenarios.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      177                                      Appendix B: Message Flow Diagrams            B.4.3.3    Subscription Version Cancels With Only One Create Action Received    Once one of the subscriptionVersionNewSP-Create or subscriptionVersionOldSP-Create actions has been received, the subscription version can be canceled by the same service provider who created the subscription version. In this case, the subscription version status is set to “canceled”, not “cancel-pending”, and no further acknowledgments are necessary by either the old or new service provider.  If the new service provider SOA creates the pending subscription version and the old service provider attempts to cancel it (or vice-versa), an error is returned to the service provider who requested the cancel.  In this scenario, the new service provider SOA has already successfully issued the subscriptionVersionNewSP-Create action. The old service provider has not issued its subscriptionVersionOldSP-Create action. Now, the new service provider needs to cancel the pending subscription version.  [Graphic Omitted: Subscription Version Cancels With Only One Create Action Received]  Action is taken by the new service provider to cancel a subscription version they created.     1.   The new service provider SOA sends M-ACTION subscriptionVersionCancel to the NPAC SMS lnpSubscriptions object to cancel a pending subscriptionVersionNPAC.      Note:   When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionCancelWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.      2.   NPAC SMS issues M-SET to update the subscriptionVersionStatus to “canceled” and update the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.      3.   NPAC SMS issues M-SET response.      4.   NPAC SMS returns the M-ACTION reply. This either reflects a success or failure. Failure reasons are version in wrong state, no version to cancel, and service provider not authorized.          If successful, the subscriptionPreCancellationStatus is set to the current subscriptionVersionStatus, and then the subscriptionVersionStatus is set to “canceled”. If the action fails, no modifications are applied and processing stops.      5.   Depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT is sent to the old service provider SOA.      6.   The old service provider confirms the M-EVENT-REPORT.      7.   Depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT is sent to the new service provider SOA.      8.   The new service provider confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      178                                      Appendix B: Message Flow Diagrams            B.4.3.4    Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison    In this scenario, the current service provider initiates a cancel for a subscription version that has a current status of ‘disconnect-pending’. Once the current service provider’s cancellation request is received, the version status is set to “active”.  [Graphic Omitted: Subscription Version Cancel by Current Service Provider for Disconnect Pending Subscription Verison]  Action is initiated by the current service provider SOA to cancel a disconnect pending subscription version by specifying the TN, or version ID of the subscription version to be canceled.     1.   The current service provider SOA sends M-ACTION subscriptionVersionCancel to the NPAC SMS lnpSubscriptions object to cancel one or more pending subscriptionVersionNPAC.      Note:   When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionCancelWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.      2.   NPAC SMS issues an M-SET to update subscriptionVersionStatus to “active” in the subscriptionVersionNPAC object and the subscriptionModifiedTimeStamp.      3.   NPAC SMS issues M-SET Response.      4.   NPAC SMS returns the M-ACTION reply. This either reflects a success or failure.          Failure reasons are version in wrong state, no version to cancel, and service provider not authorized. If successful, the subscription status is set to “active”.          If the action fails, no modifications are applied and processing stops.      5.   Depending on the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus change is sent to the current Service Provider SOA.      6.   The current service provider SOA returns an M-EVENT-REPORT confirmation back to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      179                                      Appendix B: Message Flow Diagrams            B.4.3.5    Un-Do Cancel-Pending Subscription Version Request    This scenario can only be performed when the subscription VersionStatus is cancel-pending.  [Graphic Omitted: Un-Do Cancel-Pending Subscription Version Request]         Action is taken by a service provider to un-do a cancel-pending subscription version request by specifying the TN and the version status, or by specifying the version ID of the subscription version to be modified; and the new-version-status set to pending.          Only the service provider that issued the initial cancel request for the subscription version will be allowed to issue an un-do cancel-pending subscription version request.          This flow indicates the Old service provider SOA initiates the request, however either the Old or New service provider SOA is allowed to submit the request so long as they submitted the cancel request.          In this situation the service provider (regardless of whether they are the new or old service provider indicated in the subscription version) can only update the following attribute:    new-version-status=pending     1.   Service provider SOA issues M-ACTION subscriptionVersionModify to the NPAC SMS lnpSubscriptions object to update the version. The NPAC SMS validates the data.      2.   If validation is successful, NPAC SMS will M-SET the attributes modified in the subscriptionVersionNPAC object and set the subscriptionModifiedTimeStamp.      3.   The NPAC SMS will issue an M-SET response.      4.   NPAC SMS replies to the M-ACTION with success or failure and reasons for failure.      5.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA, indicating the status is now pending.      6.   The old service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.      7.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA, indicating the status is now pending.      8.   The new service provider SOA returns M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3ã1997 — 2006 NeuStar, Inc.      180                   Appendix B: Message Flow Diagrams    B.4.4 Disconnect Scenarios  B.4.4.1 SubscriptionVersion Immediate Disconnect  The current service provider can disconnect an active subscription version. In this scenario, the disconnect is immediate.  [Graphic Omitted: SubscriptionVersion Immediate Disconnect]         Current service provider SOA personnel take action to disconnect a subscription version.      1.   Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs. The subscription version status must be active and no pending, failed, conflict or cancel-pending versions can exist.      2.   NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action.      3.   NPAC SMS responds to whether M-SET was successful.      4.   NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.      5.   NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action. The subscriptionVersionStatus goes to “sending ” and the subscriptionModifiedTimeStamp and the subscriptionBroadcastTimeStamp are both set accordingly.      6.   NPAC SMS responds to whether M-SET was successful.      7.   NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the donor service provider SOA that the subscription version is being disconnected with the customer disconnect date.      8.   The donor service provider SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      181                   Appendix B: Message Flow Diagrams    B.4.4.1.1 SubscriptionVersion Immediate Disconnect (continued)  [Graphic Omitted: SubscriptionVersion Immediate Disconnect (continued)]     1.   NPAC SMS sends out an M-DELETE on the subscriptionVersion to all Local SMSs, that are accepting downloads for the NPA-NXX of the subscriptionVersion. If the M-DELETE is for multiple subscription versions, a scoped and filtered operation will be sent.      2.   Each Local SMS responds with a successful M-DELETE reply.          All Local SMSs respond successfully.      3.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.      4.   NPAC SMS responds to M-SET.      5.   NPAC SMS issues, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange an M-EVENT-REPORT for the subscriptionVersionStatus equal to “old.”      6.   Service provider SOA responds to M-EVENT-REPORT.          After a tunable amount of days, the subscription version is purged by the NPAC SMS housekeeping process.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      182                   Appendix B: Message Flow Diagrams    B.4.4.2 SubscriptionVersion Disconnect With Effective Release Date  In this scenario, a future dated request is submitted to disconnect an active subscriptionVersion.  [Graphic Omitted: SubscriptionVersion Disconnect With Effective Release Date]         Service provider SOA personnel take action to disconnect a subscription version.      1.   Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs, and also has future dated the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict, or cancel-pending versions can exist.      2.   NPAC SMS M-SETs the status to disconnect-pending, and sets the subscriptionEffectiveReleaseDate of the existing subscriptionVersionNPAC and also the subscriptionModifiedTimeStamp.      3.   NPAC SMS responds to M-SET.      4.   NPAC SMS responds to M-ACTION. If the action fails, no modifications are applied and the processing stops.      5.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA.      6.   The current service provider SOA issues the M-EVENT-REPORT confirmation.          The NPAC SMS waits for the subscriptionEffectiveReleaseDate date to arrive.    At this point, the flow follows an immediate disconnect scenario. First the NPAC SMS sets the subscriptionVersionStatus to sending, then the donor service provider’s SOA is notified of the impending disconnect. The NPAC SMS proceeds to issue M-DELETEs for the subscriptionVersion to the Local SMS.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      183                   Appendix B: Message Flow Diagrams    B.4.4.3 SubscriptionVersion Disconnect: Failure to Local SMS  This scenario shows the broadcast of a disconnected subscription that fails to all of the Local SMSs.  [Graphic Omitted: SubscriptionVersion Disconnect: Failure to Local SMS]         The NPAC SMS has an active subscription version that has been successfully disconnected by the current service provider using the subscriptionVersionDisconnect action. The subscription version now has a status of “sending”.      1.   NPAC SMS issues the M-DELETE to all Local SMSs for the subscriptionVersion, that are accepting downloads for the NPA-NXX of the subscriptionVersion.          NPAC SMS waits for a response from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from all Local SMSs.      2.   NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “active” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of all the Local SMSs.      3.   NPAC SMS responds to the M-SET.      4.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.      5.   Current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      184                   Appendix B: Message Flow Diagrams    B.4.4.4 SubscriptionVersion Disconnect: Partial Failure to Local SMS  This scenario shows the broadcast of a disconnected subscription that fails to one or more, but not all, of the Local SMSs.  [Graphic Omitted: SubscriptionVersion Disconnect: Partial Failure to Local SMS]         The NPAC SMS has an active subscription version that has been successfully disconnected by the current service provider using the subscriptionVersionDisconnect action. The subscription version now has a status of “sending”.      1.   NPAC SMS issues the M-DELETE to all Local SMSs for the subscriptionVersion, that are accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   Local SMSs should respond successfully to the M-DELETE.          NPAC SMS waits for a response from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from at least one Local SMS.      3.   NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “old” from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.      6.   Current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      185                   Appendix B: Message Flow Diagrams    B.4.4.5 Subscription Version Disconnect: Resend Successful to Local SMS  This scenario shows a successful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. The resend of a failed disconnect can only be performed by authorized NPAC personnel.  [Graphic Omitted: Subscription Version Disconnect: Resend Successful to Local SMS]         NPAC personnel take action to resend a failed disconnect for a subscription version.      1.   NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending”.      2.   NPAC SMS responds to whether M-SET was successful.      3.   NPAC SMS sends out an M-DELETE on the subscriptionVersion to all previously failed Local SMSs, that are accepting downloads for the NPA-NXX of the subscriptionVersion.      4.   Each Local SMS responds with a successful M-DELETE reply.          All Local SMSs respond successfully.      5.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects. It also sets the subscriptionModifiedTimeStamp and subscriptionDisconnectCompleteTimeStamp.      6.   NPAC SMS responds to M-SET.      7.   NPAC SMS issues, depending upon the service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT for the subscriptionVersionStatus equal to “old.”      8.   Service provider SOA responds to M-EVENT-REPORT.          After a tunable amount of days, the subscription version is purged by the NPAC SMS housekeeping process.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      186                   Appendix B: Message Flow Diagrams    B.4.4.6 Subscription Version Disconnect: Resend Failure to Local SMS  This scenario shows a failure on a resend of a subscription disconnect that failed previously to one or more of the Local SMSs. The resend of a failed disconnect for a subscription can only be performed by authorized NPAC personnel.  [Graphic Omitted: Subscription Version Disconnect: Resend Failure to Local SMS]         NPAC personnel take action to resend a failed disconnect for a subscription version.      1.   NPAC SMS issues the M-DELETE to all Local SMSs for which the disconnect previously failed for the subscriptionVersion, and are accepting downloads for the NPA-NXX of the subscriptionVersion.      2.   Local SMSs should respond successfully to the M-DELETE.          NPAC SMS waits for a response from each Local SMS.          NPAC SMS retries any Local SMS that has not responded.          No response or an error is received from at least one or all Local SMSs.      3.   NPAC SMS issues the M-SET to update the current subscriptionVersionNPAC object’s subscriptionVersionStatus to “old” or “active” (if all Local SMSs failed) from “sending”. It will also update the subscriptionFailed-SP-List with the service provider ID and name of the Local SMSs that failed to successfully receive the broadcast.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status and failedSP-List.      6.   Current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      187                   Appendix B: Message Flow Diagrams    B.4.4.7 Disconnect Subscription Version Scenarios for TNs that are part of a Number Pool Block                B.4.4.7.1    SOA Initiates Successful Disconnect Request of Ported Pooled TN (previously NNP flow 4.1.1)     The current service provider can disconnect an active subscription version that will return to the block holder after the number pool block has been activated. In this scenario, the disconnect is immediate where the TN returns to the block holder and the number pool block is active. In this scenario:       •   SV1 is the currently active Subscription Version that will be disconnected.        •   SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.    SV1 will be broadcast to the EDR Local SMSs to disconnect the ported TN and revert to the number pool block routing information. SV2 will be broadcast to the non-EDR Local SMSs with the number pool block routing information.  In this scenario, the SOA sends in the disconnect action to a ported, pooled TN.  [Graphic Omitted: SOA Initiates Successful Disconnect Request of Ported Pooled TN]  Current service provider SOA personnel take action to disconnect a subscription version.     1.   Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs, and also has NOT future dated (i.e., used the current date) the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict or cancel-pending versions can exist.      2.   NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action for SV1. The subscriptionVersionStatus for SV1 goes to “sending ”. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp are set accordingly.      3.   NPAC SMS responds to the M-SET.      4.   NPAC SMS issues M-CREATE to create SV2. The routing information comes from the numberPoolBlock object that contains the TN. The status is set to ‘sending’. The subscriptionActivationTimeStamp, subscriptionBroadcastTimeStamp, subscriptionCreationTimeStamp and subscriptionModifiedTimeStamp are all set.      5.   NPAC SMS responds to M-CREATE.      6.   NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.      7.   NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the Donor service provider SOA that the subscription version is being disconnected with the customer disconnect date. This SOA is the block holder SOA.      8.   The donor service provider SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      188                   Appendix B: Message Flow Diagrams    B.4.4.7.2 Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation (previously NNP flow 4.1.2)  The NPAC SMS is ready to broadcast the disconnect of the ported, pooled TN.  [Graphic Omitted: Successful Broadcast of Disconnect for a Ported Pooled TN After Block Activation]     1.   NPAC SMS sends the M-DELETE request to the EDR Local SMS to delete the existing subscription version and cause the routing to return to the number pool block. If a range of subscription versions is being removed, the M-DELETE will be scoped and filtered for the appropriate subscription versions by TN.      2.   At the same time as step 1, the NPAC SMS sends out the M-CREATE of a subscription version to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscription version for SV2. If the M-CREATE is for multiple subscription versions, the subscriptionVersionLocalSMS-Create M-ACTION will be sent. The subscription version for the TN has a LNP type of ‘pool’.      3.   EDR Local SMS sends its successful M-DELETE reply.      4.   Non-EDR Local SMS responds with a successful M-CREATE reply.      5.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to active for subscriptionVersionNPAC objects for SV2. The subscriptionModifiedTimeStamp is also set.      6.   NPAC SMS responds to M-SET.      7.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for subscriptionVersionNPAC objects for SV1. It also sets the subscriptionModifiedTimeStamp. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      8.   NPAC SMS responds to M-SET.      9.   NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA for the subscriptionVersionStatus being set to old on SV1.      10.   The current service provider SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      189                   Appendix B: Message Flow Diagrams    B.4.4.7.3 Subscription Version Disconnect With Effective Release Date (replace/update existing flow B.5.4.2 with this flow here – NNP flow 4.2)  In this scenario, a future dated request is submitted to disconnect an active subscription version that will return to the block holder.  [Graphic Omitted: Subscription Version Disconnect With Effective Release Date]  Current service provider SOA personnel take action to disconnect a subscription version.     1.   Current service provider SOA issues an M-ACTION request to disconnect the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN, or range of TNs, and also has future dated the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict, conflict-pending, or cancel-pending versions can exist.      2.   NPAC SMS issues an M-SET to set the status to disconnect-pending, and set the subscriptionEffectiveReleaseDate, and the subscriptionModifiedTimeStamp of the existing subscriptionVersionNPAC.      3.   NPAC SMS responds to M-SET.      4.   NPAC SMS responds to M-ACTION. If the action fails, no modifications are applied and the processing stops.      5.   NPAC SMS sends, depending upon the block holder service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA.      6.   The current service provider SOA issues the M-EVENT-REPORT confirmation.    The NPAC SMS waits for the subscriptionEffectiveReleaseDate date to arrive.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      190                   Appendix B: Message Flow Diagrams    B.4.4.7.4 Subscription Version Disconnect of a Ported Pooled TN After Block Activation: Failure to Local SMS (previously NNP flow 4.3.1)  This scenario shows the broadcast of a disconnect subscription after block activation that fails to all of the Local SMSs. In this scenario:       •   SV1 is the currently active Subscription Version.        •   SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.    [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN After Block Activation: Failure to Local SMS]  NPAC SMS has a subscription version that is in the process of being disconnected. The subscription version TN is part of a number pool block. SV1, the subscription being disconnected, and SV2, the reinstatement of the routing data in the number pool block, are in a state of ‘sending’.     1.   NPAC SMS sends the M-DELETE request to the EDR Local SMS for SV1.      2.   At the same time as step 1, the NPAC SMS sends the M-CREATE request to the non-EDR Local SMS for SV2.    NPAC SMS waits for responses from all Local SMSs.  NPAC SMS retries each Local SMS that has not responded.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      191                   Appendix B: Message Flow Diagrams    B.4.4.7.5 Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates (previously NNP flow 4.3.2)  NPAC SMS is attempting to disconnect a subscription version whose TN is a part of a number pool block. It has broadcast the data to the LSMSs.  [Graphic Omitted: Subscription Version Disconnect for a Ported Pooled TN Broadcast Failure NPAC SMS Updates]  No response occurs from any of the Local SMS, or all return failures to the M-CREATE or M-DELETE request, or a combination of the two.     1.   NPAC SMS issues the M-SET to update the SV2 subscriptionVersionStatus from “sending” to “failed”. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues the M-SET to update the SV1 subscriptionVersionStatus from “sending” to “active”. It also updates the subscriptionFailed-SP-List with the service provider ID and name of all the Local SMSs. The subscriptionModifiedTimeStamp is also set.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current status for SV1 along with the subscriptionFailed-SP-List.      6.   Current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      192                   Appendix B: Message Flow Diagrams     B.4.4.7.6 Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS (previously NNP flow 4.4.1)  This scenario shows the broadcast of a disconnect subscription version after the number pool block activation that fails to one or more, but not all, Local SMSs. In this scenario:       •   SV1 is the currently active Subscription Version.        •   SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.    NPAC SMS has a subscription version that is in the process of being disconnected. The subscription version TN is part of a number pool block. SV1, the subscription being disconnected, and SV2, the reinstatement of the routing data in the number pool block, are in a state of ‘sending’.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Partial Failure to Local SMS]     1.   NPAC SMS sends the M-DELETE request to the EDR Local SMS for SV1.      2.   At the same time as step 1, the NPAC SMS sends the M-CREATE request to the non-EDR Local SMS for SV2.      3.   The EDR Local SMS responds to the M-DELETE.      4.   The non-EDR Local SMS responds to the M-CREATE.    NPAC SMS waits for responses from all Local SMSs.  NPAC SMS retries each Local SMS that has not responded.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      193                   Appendix B: Message Flow Diagrams    B.4.4.7.7 Subscription Version Disconnect of a Ported Pooled TN Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.4.2)  NPAC SMS is attempting to disconnect a subscription version whose TN is a part of a number pool block.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Partial Failure Broadcast NPAC SMS Updates]  A response does not occur from at least one, but not all Local SMSs and/or at least one, but not all, Local SMSs respond with an error to the M-DELETE or M-CREATE request.     1.   NPAC SMS issues the M-SET to update the SV2 subscriptionVersionStatus from “sending” to “partially-failed”. The subscriptionModifiedTimeStamp and subscriptionActivationTimeStamp are also set.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues the M-SET to update the SV1 subscriptionVersionStatus from “sending” to “old”. It also updates the subscriptionFailed-SP-List with the service provider ID and name of all the non-EDR and EDR Local SMSs that failed the broadcast. The subscriptionModifiedTimeStamp is also set. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the status of ‘old’ for SV1 along with the subscriptionFailed-SP-List.      6.   Current service provider SOA issues the M-EVENT-REPORT confirmation.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      194                   Appendix B: Message Flow Diagrams    B.4.4.7.8 Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS (previously NNP flow 4.5.1)  This scenario shows a successful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. The resend of a failed disconnect can only be performed by authorized NPAC personnel. In this scenario:       •   SV1 is the currently active Subscription Version.        •   SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder.    NPAC Personnel take action to resend a failed disconnect for a subscription version (SV1) that took place after the activation of the number pool block.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Resend Successful to Local SMS]     1.   NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues an M-SET to update the subscriptionVersionNPAC object for SV2. The subscriptionVersionStatus is set to “sending” for SV2 and the subscriptionModifiedTimeStamp is updated.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-DELETE on the subscriptionVersion SV1 to all previously failed EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV1 TN.      6.   At the same time as step 5, the NPAC SMS issues an M-CREATE on the subscription version SV2 to all non-EDR Local SMSs that are accepting downloads for the NPA-NXX and had previously failed.      7.   EDR Local SMS responds successfully to the M-DELETE on SV1.      8.   Each non-EDR Local SMS responds successfully to the M-CREATE on SV2.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      195                   Appendix B: Message Flow Diagrams    B.4.4.7.9 Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates (previously NNP flow 4.5.2)  All non-EDR Local SMSs have responded successfully to the M-CREATE for SV2 and all EDR Local SMSs have responded successfully to the M-DELETE for SV1.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Resend Successful NPAC SMS Updates]     1.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to ‘active’ for SV2. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to M-SET.      3.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to ‘old’ for SV1. The subscriptionModifiedTimeStamp is also set.      4.   NPAC SMS responds to M-SET.      5.   NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider for SV1 with the subscriptionVersionStatus set to ‘old’.      6.   Current service provider confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      196                   Appendix B: Message Flow Diagrams    B.4.4.7.10 Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS (previously NNP flow 4.6.1)  This scenario shows an unsuccessful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. the resend of a failed disconnect can only be performed by NPAC personnel. In this scenario:       •   SV1 is the currently active Subscription Version.        •   SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder with a status of failed.    NPAC Personnel take action to resend a failed disconnect for a subscription version (SV1). This rebroadcast will result in failure again.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Resend Failure to Local SMS]     1.   NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.      2.   NPAC SMS responds to the M-SET.      3.   NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV2 and the subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.      5.   NPAC SMS issues an M-DELETE on the subscriptionVersion SV1 to all previously failed EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV1 TN.      6.   At the same time as step 5, the NPAC SMS issues an M-CREATE on the subscriptionVersion SV2 to all previously failed non-EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV2 TN.    NPAC SMS waits for responses from all Local SMSs.  NPAC SMS retries each Local SMS that has not responded.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      197                   Appendix B: Message Flow Diagrams    B.4.4.7.11 Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates (previously NNP flow 4.6.2)  None of the non-EDR Local SMSs has responded successfully to the M-CREATE and none of the EDR Local SMSs responded successfully to the M-DELETE.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Resend Failure NPAC SMS Updates]     1.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to failed for SV2. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to M-SET.      3.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to active for SV1. The subscriptionFailed-SP-List and subscriptionModifiedTimeStamp is also set.      4.   NPAC SMS responds to M-SET.      5.   NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider for SV1 with the subscriptionVersionStatus set to ‘active’ and the subscriptionFailed-SP-List.      6.   Current service provider confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      198                   Appendix B: Message Flow Diagrams    B.4.4.7.12 Subscription Version Disconnect of a Ported Pooled TN: Resend Partial Failure to Local SMS (previously NNP flow 4.7.1)  This scenario shows an unsuccessful resend of a disconnect for a subscription that fails to one or more of the Local SMSs. the resend of a failed disconnect can only be performed by NPAC personnel. In this scenario:       •   SV1 is the previously active Subscription Version now with a status of old.        •   SV2 is the pool reinstatement Subscription Version with LNP type = pool that reinstates default routing to the block holder with a status of partially failed.    The NPAC SMS is initiating the resend of a previously partially failed disconnect of a ported, pooled TN for a number pool block that was active at the time of the initial broadcast.     1.   If a non-EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV1 and set the subscriptionModifiedTimeStamp.      2.   NPAC SMS responds to the M-SET.      3.   If an EDR Local SMS failed the broadcast, the NPAC SMS issues an M-SET to the existing subscriptionVersionNPAC object to set the status to “sending” for SV2 and the subscriptionModifiedTimeStamp.      4.   NPAC SMS responds to the M-SET.      5.   If the status of SV1 is set to sending, the NPAC SMS issues an M-DELETE on the subscriptionVersion SV1 to all previously failed EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV1 TN.      6.   At the same time as step 5 and if the status of SV2 is set to sending, the NPAC SMS issues an M-CREATE on the subscriptionVersion SV2 to all previously failed non-EDR Local SMSs that are accepting downloads for the NPA-NXX of the subscriptionVersion SV2 TN.      7.   The EDR Local SMS responds to the M-DELETE request.      8.   The non-EDR Local SMS responds to the M-CREATE request.    NPAC SMS waits for responses from all Local SMSs.  NPAC SMS retries each Local SMS that has not responded.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN: Resend Partial Failure to Local SMS]  B.4.4.7.13 Subscription Version Disconnect of a Ported Pooled TN Resend Partial Failure Broadcast NPAC SMS Updates (previously NNP flow 4.7.2)  At least one of the non-EDR Local SMSs has not responded successfully to the M-CREATE and/or at least one of the EDR Local SMSs has not responded successfully to the M-DELETE.  [Graphic Omitted: Subscription Version Disconnect of a Ported Pooled TN Resend Partial Failure Broadcast NPAC SMS]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      199                   Appendix B: Message Flow Diagrams       1.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to partially-failed for SV2. The subscriptionModifiedTimeStamp is also set.      2.   NPAC SMS responds to M-SET.      3.   NPAC SMS issues M-SET updating the subscriptionVersionStatus to old for SV1. The subscriptionFailed-SP-List and subscriptionModifiedTimeStamp is also set.      4.   NPAC SMS responds to M-SET.      5.   NPAC SMS issues, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider for SV1 with the subscriptionVersionStatus set to ‘old’ along with the subscriptionFailed-SP-List.      6.   Current service provider confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      200                   Appendix B: Message Flow Diagrams    B.4.4.7.14 Subscription Version Immediate Disconnect of a Contaminated Pooled TN Prior to Block Activation (after Effective Date) (previously NNP flow 4.8)  In this scenario, the current service provider disconnects an active subscription version that will return to the block holder. However, the NPA-NXX-X is past the effective date, but has not yet been activated.  [Graphic Omitted: Subscription Version Immediate Disconnect of a Contaminated Pooled TN Prior to Block Activation]  Current service provider SOA personnel take action to disconnect a subscription version.     1.   Service provider SOA issues an M-ACTION request to disconnect to the lnpSubscriptions object. The M-ACTION specifies either the subscriptionVersionId, or subscriptionTN or range of TNs, and also has NOT future dated (i.e., used the current date) the subscriptionEffectiveReleaseDate and the subscriptionCustomerDisconnectDate. The subscription version status must be active and no pending, failed, conflict or cancel-pending versions can exist.      2.   NPAC SMS issues an M-SET to set the subscriptionCustomerDisconnectDate according to the disconnect action for SV1. The subscriptionVersionStatus for SV1 goes to “sending ”. The subscriptionModifiedTimeStamp and subscriptionBroadcastTimeStamp are set accordingly.      3.   NPAC SMS responds to whether M-SET was successful.      4.   NPAC SMS responds to the M-ACTION. If the action failed, an error will be returned and processing will stop on this flow.      5.   NPAC SMS sends, depending upon the donor service provider’s TN Range Notification Indicator, a subscriptionVersionDonorSP-CustomerDisconnectDate or subscriptionVersionRangeDonorSP-CustomerDisconnectDate notification to the Donor service provider SOA that the subscription version is being disconnected with the customer disconnect date. This SOA is the block holder SOA.      6.   The donor service provider SOA confirms the M-EVENT-REPORT.      7.   NPAC SMS sends the M-DELETE request to the Local SMS to delete the existing subscription version.      8.   Local SMS sends its M-DELETE reply.    All Local SMSs have responded successfully.     9.   NPAC SMS sets the subscriptionVersionStatus to ‘old’ and sets the subscriptionModifiedTimeStamp. The subscriptionDisconnectCompleteTimeStamp is set when the first successful response is received.      10.   NPAC SMS responds to the M-SET.      11.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange notification to the current service provider’s SOA with the subscriptionVersionStatus set to ‘old’.      12.   Service provider SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      201                   Appendix B: Message Flow Diagrams    B.4.5 Conflict Scenarios  A situation has arisen which causes the NPAC SMS or NPAC personnel to place the subscriptionVersion into conflict.  A subscription version can be removed from conflict by the NPAC personnel or the new service provider SOA.  B.4.5.1 SubscriptionVersion Conflict by the NPAC SMS  This scenario shows a version being placed into conflict by the NPAC personnel.  [Graphic Omitted: SubscriptionVersion Conflict by the NPAC SMS]         NPAC personnel or NPAC SMS take action to set the status of a subscription to “conflict.”      1.   NPAC SMS issues M-SET request to update subscriptionVersionStatus to “conflict,” subscriptionConflictTimeStamp, and subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.      2.   NPAC SMS issues an M-SET response. If the M-SET fails, processing for this scenario stops.      3.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to old service provider SOA.      4.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange to new service provider SOA.      6.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider to set the old service provider’s authorization to “FALSE”. Since the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider to set the old service provider’s authorization to “FALSE”. Since the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      202                   Appendix B: Message Flow Diagrams    B.4.5.1.1 Subscription Version Conflict Resolution by the NPAC SMS (continued)  [Graphic Omitted: Subscription Version Conflict Resolution by the NPAC SMS (continued)]         Once the conflict is resolved, NPAC personnel take action to remove the subscriptionVersion from conflict.      1.   NPAC SMS issues an M-SET request to update the subscriptionModifiedTimeStamp and the subscriptionVersionStatus to “pending.”      2.   NPAC SMS issues an M-SET response. If the M-SET fails, processing for this scenario stops.      3.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the new status to the old service provider SOA.      4.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for the new status to the new service provider SOA.      6.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider’s SOA indicating the authorization has been set to “TRUE”.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider’s SOA indicating the authorization has been set to “TRUE”.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      203                   Appendix B: Message Flow Diagrams    B.4.5.2 Subscription Version Conflict Removal by the New Service Provider SOA  In this scenario, the new service provider elects to remove the subscription version from conflict.  [Graphic Omitted: Subscription Version Conflict Removal by the New Service Provider SOA]         A subscription version exists on the NPAC SMS with a status of conflict.          The new service provider SOA personnel take action to remove the subscription version from conflict.      1.   The new service provider SOA sends the M-ACTION Request subscriptionVersionRemoveFromConflict specifying the subscription version TN or subscription version ID of the subscription version in conflict.                  Note:    When the Service Provider supports Application Level Errors (SOA Application Level Errors Indicator set to TRUE in their Service Provider Profile), the SOA will utilize the subscriptionVersionRemoveFromConflictWithErrorCode ACTION that supports detailed error codes. The NPAC will provide an M-ACTION response based on the submitted message.        2.   If the request is valid, the NPAC SMS will set the status to “pending”.          The request will be denied and an error returned if the subscriptionOldSP-Authorization was set to conflict by the old service provider and the conflict restriction window has not expired and/or the old service provider specified cause code value 50 or 51, regardless of the conflict restriction window expiration.      3.   The NPAC SMS responds to its own M-SET.      4.   The NPAC SMS sends an M-ACTION Response with success or failure and reason for failure.      5.   The NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider’s SOA.      6.   The New SOA sends the M-EVENT-REPORT confirmation.      7.   The NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider’s SOA.      8.   The Old SOA sends the M-EVENT-REPORT confirmation.      9.   NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to set the old service provider’s authorization to “TRUE”.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider indicating the authorization has been set to “TRUE”.      12.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      204                   Appendix B: Message Flow Diagrams    B.4.5.3 SubscriptionVersion Conflict: No Conflict Resolution  This scenario shows the action taken at the NPAC SMS when service providers do not reach a conflict resolution.  [Graphic Omitted: SubscriptionVersion Conflict: No Conflict Resolution]         NPAC personnel or NPAC SMS take action to set a subscriptionVersionStatus to “conflict.”      1.   NPAC SMS issues an M-SET request to set the subscriptionVersionStatus to “conflict,” the subscriptionConflictTimeStamp, and the subscriptionModifiedTimeStamp in the subscriptionVersionNPAC object.      2.   NPAC SMS responds to M-SET. If the M-SET fails, processing stops for this scenario until the M-SET completes successfully.      3.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange to old service provider SOA for the new “conflict” status.      4.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange to new service provider SOA for the “conflict” status.      6.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      7.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider to set the authorization to “FALSE”. Since the Subscription Version Status was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.      8.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      9.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider to set the authorization to “FALSE”. Since the Subscription Version Status was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.      10.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      205                   Appendix B: Message Flow Diagrams    B.4.5.3.1 Subscription Version Conflict: No Conflict Resolution (continued)  [Graphic Omitted: Subscription Version Conflict: No Conflict Resolution (continued)]         “Version Conflict Cancellation Window” expires without conflict resolution.      1.   NPAC SMS issues an M-SET request to set the subscriptionVersionStatus to “cancel” in the subscriptionVersionNPAC object and sets the subscriptionCancellationTimeStamp and subscriptionModifiedTimeStamp.      2.   NPAC SMS responds to M-SET. If the M-SET fails, processing stops for this scenario until the M-SET is successfully completed.      3.   NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for status to old service provider SOA for the “cancel” status.      4.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      5.   NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange for status to new service provider SOA for the “cancel” status.      6.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      206                   Appendix B: Message Flow Diagrams    B.4.5.4 Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)  The old service provider SOA can put a pending subscription version into conflict by setting its authorization flag to FALSE. This can be done on the subscriptionVersionOldSP-Create action, subscriptionVersionModify action, or M-SET of the attribute on the subscription version object.  This scenario shows the old service provider putting a new pending subscription version into conflict by turning the authorization flag FALSE on the subscriptionVersionOldSP-Create. In this case, the old service provider’s create action is the second sent to the NPAC SMS.  [Graphic Omitted: Subscription Version Conflict by Old Service Provider Explicitly Not Authorizing (2nd Create)]         Action is taken by the old service provider to set a subscription version to conflict using the subscriptionVersionOldSP-Create action.      1.   The old service provider SOA sends M-ACTION subscriptionVersionOldSP-Create to the NPAC SMS lnpSubscriptions object to create a new subscriptionVersionNPAC with the status of “conflict”.          The old service provider SOA specifies the following valid attributes:          subscriptionTN or valid subscriptionVersionTN-Range subscriptionNewCurrentSP subscriptionOldSP subscriptionOldSP-DueDate (seconds set to zeros) subscriptionOldSP-Authorization subscriptionLNPType subscriptionStatusChangeCauseCode          In this case, the subscriptionOldSP-Authorization is set to FALSE.      2.   NPAC SMS issues M-CREATE to create the subscriptionVersionNPAC with a status of “conflict” and sets all the other attribute values from the subscriptionVersionOldSP-Create action.      3.   NPAC SMS issues M-CREATE response.      4.   NPAC SMS returns M-ACTION reply. This either reflects a success or failure and reasons for the failure.      5.   If the action was successful, the NPAC SMS issues, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA notifying them of the updates.      6.   The old service provider SOA confirms the M-EVENT-REPORT.      7.   If the action was successful, the NPAC SMS issues, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      207                   Appendix B: Message Flow Diagrams           subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the new service provider SOA notifying them of the updates.      8.   The new service provider SOA confirms the M-EVENT-REPORT.      9.   NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to set the old service provider’s authorization to “FALSE”. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to set the new service provider authorization to “FALSE”. If the subscriptionVersionStatus was set to conflict, include the subscriptionConflictTimeStamp attribute in the broadcast.      12.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      208                   Appendix B: Message Flow Diagrams    B.4.5.5 Subscription Version Conflict Removal by the Old Service Provider SOA  In this scenario, the old service provider elects to remove the subscription version from conflict.  [Graphic Omitted: Subscription Version Conflict Removal by the Old Service Provider SOA]         A subscription version exists on the NPAC SMS with a status of conflict.          The old service provider SOA personnel take action to remove the subscription version from conflict.      1.   The old service provider SOA sends the M-ACTION subscriptionVersionRemoveFromConflict specifying the subscription version TN or subscription version ID of the subscription version in conflict.      2.   If the request is valid, the NPAC SMS will set the status to “pending”.      3.   The NPAC SMS responds to its own M-SET.      4.   The NPAC SMS responds to the M-ACTION with success or failure and reason for failure.      5.   The NPAC SMS sends, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the Old SOA.      6.   The Old SOA sends the M-EVENT-REPORT confirmation.      7.   The NPAC SMS sends, depending upon the new service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the New SOA.      8.   The New SOA sends the M-EVENT-REPORT confirmation.      9.   NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the old service provider indicating the authorization has been set to “TRUE”.      10.   The old service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.      11.   NPAC SMS sends, depending upon the service provider’s TN Range Notification Indicator, an attributeValueChange or subscriptionVersionRangeAttributeValueChange to the new service provider indicating the authorization has been set to “TRUE”.      12.   The new service provider SOA returns an M-EVENT-REPORT confirmation to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3 ©1997—2006 NeuStar, Inc.      209                   Appendix B: Message Flow Diagrams    B.4.6      SubscriptionVersion Query  This scenario shows subscriptionVersion query from service provider systems to the NPAC SMS.  [Graphic Omitted: SubscriptionVersion Query]         Action is taken by either a service provider SOA or Local SMS for retrieving one or more versions of a subscription.      1.   The service provider SOA or Local SMS issues a scoped filtered M-GET from the lnpSubscriptions object to retrieve a specific version for a subscription version TN or can request all subscription versions. However, the service provider SOA is limited by a scope and filter in their search capabilities. The filter will currently support all the attributes on the subscriptionVersionNPAC.      2.   For Service Providers that DO NOT support the enhanced SV Query Functionality (Service Provider SV Query Indicator tunable parameter set to FALSE), the NPAC SMS replies with the first requested subscriptionVersion data if the requested number of records is less than or equal to “Max SubscriberQuery” specified in the NPAC SMS. Otherwise a complexityLimitation error will be returned.          For Service Providers that support the enhanced SV Query functionality (Service Provider SV Query Indicator tunable parameter set to TRUE,) the NPAC SMS replies with the requested subscriptionVersion data if the requested number of records is less than or equal to “Maximum Subscription Query” tunable value specified in the NPAC SMS. If the requested subscriptionVersion data exceeds the tunable value, then the number of subscriptionVersion records that equal the tunable value will be returned. The service provider SOA or Local SMS will use the data returned to submit a subsequent query, starting with the next record from where the previous query finished. Only when subscriptionVersion data is returned that contains less than the tunable value, is it safe for the service provider SOA or Local SMS to assume all data has been retrieved from the NPAC SMS.    The query return data includes:                     subscriptionVersionId (SOA, LSMS)        subscriptionTN (SOA, LSMS)        subscriptionLRN (SOA, LSMS)        subscriptionNewCurrentSP (SOA, LSMS)        subscriptionOldSP (SOA)        subscriptionNewSP-DueDate (SOA)        subscriptionNewSP-CreationTimeStamp (SOA)        subscriptionOldSP-DueDate (SOA)        subscriptionOldSP-Authorization (SOA)        subscriptionOldSP-AuthorizationTimeStamp (SOA)        subscriptionActivationTimeStamp (SOA)        subscriptionBroadcastTimeStamp (SOA)        subscriptionConflictTimeStamp (SOA)                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      210                   Appendix B: Message Flow Diagrams                       subscriptionCustomerDisconnectDate (SOA)        subscriptionDisconnectCompleteTimeStamp (SOA)        subscriptionEffectiveReleaseDate (SOA)        subscriptionVersionStatus (SOA, LSMS)        subscriptionCLASS-DPC (SOA, LSMS)        subscriptionCLASS-SSN (SOA, LSMS)        subscriptionLIDB-DPC (SOA,LSMS)        subscriptionLIDB-SSN (SOA, LSMS)        subscriptionCNAM-DPC (SOA, LSMS)        subscriptionCNAM-SSN (SOA, LSMS)        subscriptionISVM-DPC (SOA, LSMS)        subscriptionISVM-SSN (SOA, LSMS)        subscriptionWSMSC-DPC — if supported by the Service Provider SOA (SOA, LSMS)        subscriptionWSMSC-SSN — if supported by the Service Provider SOA (SOA, LSMS)        subscriptionEndUserLocationValue (SOA)        subscriptionEndUserLocationType (SOA)        subscriptionBillingId (SOA)        subscriptionLNPType (SOA)        subscriptionPreCancellationStatus (SOA)        subscriptionCancellationTimeStamp (SOA)        subscriptionOldTimeStamp (SOA)        subscriptionModifiedTimeStamp (SOA)        subscriptionCreationTimeStamp (SOA)        subscriptionOldSP-CancellationTimeStamp (SOA)        subscriptionNewSP-CancellationTimeStamp (SOA)        subscriptionOldSP-ConflictResolutionTimeStamp (SOA)        subscriptionNewSP-ConflictResolutionTimeStamp (SOA)        subscriptionPortingToOriginal-SPSwitch (SOA)        subscriptionFailedSP-List (SOA)        subscriptionDownloadReason (SOA)        subscriptionTimerType (SOA) — if supported by the Service Provider        subscriptionBusinessType (SOA) — if supported by the Service Provider        subscriptionStatusChangeCauseCode (SOA)        subscriptionSVType – if supported by the Service Provider        subscriptionAlternativeSPID – if supported by the Service Provider        3.   The NPAC SMS replies with the rest of the subscription version data that matches the requested criteria.      4.   The NPAC SMS replies with the final, empty M-GET response.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      211                   Appendix B: Message Flow Diagrams    B.4.6.1 Subscription Data Download  DELETED. This scenario is superceded by the text and flows in section B.7, Local SMS and SOA Recovery.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      212                   Appendix B: Message Flow Diagrams    B.5       LSMS Filter NPA-NXX Scenarios  B.5.1            lsmsFilterNPA-NXX Creation by the Local SMS  [Graphic Omitted: lsmsFilterNPA-NXX Creation by the Local SMS]         Action is taken by the Local SMS personnel to create an lsmsFilterNPA-NXX object.      1.   The Local SMS sends the M-CREATE request to the NPAC for the lsmsFilterNPA-NXX object to be created.      2.   The NPAC SMS attempts to create the object. If successful, the M-CREATE response is returned. Otherwise, an error is returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      213                   Appendix B: Message Flow Diagrams    B.5.2      lsmsFilterNPA-NXX Deletion by the Local SMS  [Graphic Omitted: lsmsFilterNPA-NXX Deletion by the Local SMS]         Action is taken by the Local SMS personnel to delete an lsmsFilterNPA-NXX object.      1.   The Local SMS sends the M-DELETE request to the NPAC for the lsmsFilterNPA-NXX object to be removed.      2.   The NPAC SMS attempts to delete the object. If successful, the M-DELETE response is returned. Otherwise, an error is returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      214                   Appendix B: Message Flow Diagrams    B.5.3      lsmsFilterNPA-NXX Query by the Local SMS  [Graphic Omitted: lsmsFilterNPA-NXX Query by the Local SMS]         Action is taken by the Local SMS personnel to query for one or all lsmsFilterNPA-NXX object(s).      1.   The Local SMS sends the M-GET request to the NPAC for the lsmsFilterNPA-NXX object(s).      2.   If the Service Provider ID was specified, all lsmsFilterNPA-NXX objects for that Service Provider are returned. If only one object was requested, that object is returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      215                   Appendix B: Message Flow Diagrams    B.5.4      lsmsFilterNPA-NXX Creation by the SOA  [Graphic Omitted: lsmsFilterNPA-NXX Creation by the SOA]         Action is taken by the SOA personnel to create an lsmsFilterNPA-NXX object.      1.   The SOA sends the M-CREATE request to the NPAC for the lsmsFilterNPA-NXX object to be created.      2.   The NPAC SMS attempts to create the object. If successful, the M-CREATE response is returned. Otherwise, an error is returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      216                   Appendix B: Message Flow Diagrams    B.5.5      lsmsFilterNPA-NXX Deletion by the SOA  [Graphic Omitted: lsmsFilterNPA-NXX Deletion by the SOA]         Action is taken by the SOA personnel to delete an lsmsFilterNPA-NXX object.      1.   The SOA sends the M-DELETE request to the NPAC for the lsmsFilterNPA-NXX object to be removed.      2.   The NPAC SMS attempts to delete the object. If successful, the M-DELETE response is returned. Otherwise, an error is returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      217                   Appendix B: Message Flow Diagrams    B.5.6      lsmsFilterNPA-NXX Query by the SOA  [Graphic Omitted: lsmsFilterNPA-NXX Query by the SOA]         Action is taken by the SOA personnel to query for one or all lsmsFilterNPA-NXX object(s).      1.   The SOA sends the M-GET request to the NPAC for the lsmsFilterNPA-NXX object(s).      2.   If the Service Provider ID was specified, all lsmsFilterNPA-NXX objects for that Service Provider are returned. If only one object was requested, that object is returned.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      218                   Appendix B: Message Flow Diagrams    B.6      Local SMS and SOA Recovery  For all download requests in this section, the Local SMS or SOA should behave as follows in response to the possible download M-ACTION response from the NPAC SMS:  Success – process the data received from the NPAC SMS, continue processing.  No-data-selected – no data was found, continue processing.  Criteria-too-large (using the Maximum Number of Download Records tunable) – break up the request into a smaller time range and re-issue the request to the NPAC SMS (only applies to SV requests).  OR  Criteria-too-large (using the Maximum Number of Download Notifications tunable) – break up the request into a smaller time range and re-issue the request to the NPAC SMS (only applies to notification requests).  Time-range-invalid (using the Maximum Download Duration tunable) – break up the request into shorter time ranges and re-issue the request to the NPAC SMS.  Failed – go into retry mode. Re-issue the request configurable number of additional retry attempts with an “x” amount of delay between requests (“x” is based on a configurable amount of time after receiving the failure for each request). If a failed response is received for the final retry request, abort the association and re-start the recovery process. Note: It is recommended that the Local SMS or SOA use the same value that the NPAC SMS uses for retry interval.  For activities that specify “continue processing”, the Local SMS or SOA should send the NPAC SMS, either the next lnpDownload Action for a different type of data, or an lnpRecoveryComplete request, depending on where the response appears in the flow.  It is optional as to whether the Local SMS recovers Service Provider Data, Network Data, Subscription Data, Notification Data, or any combination of the four; and if the SOA recovers the Service Provider Data, Network Data, and/or Notification Data, or any combination of the three. Number Pool Block information may (optionally) be recovered by EDR-capable LSMSs. For a Local SMS or SOA that initiates recovery, the only step that is required is the lnpRecoveryComplete message, at the end of all previous data recovery requests. This instructs the NPAC SMS to send previously queued messages and resume normal processing.  Due to prerequisite data requirements on some local systems (service provider object must exist before subtending network data, which must exist before subtending subscription versions, etc.), it is also expected that the order of recovery would be Service Provider Data, followed by Network Data, Subscription Data, Number Pool Block Data (for LSMSs that are EDR-capable), then Notification Data.  If the Local SMS or SOA supports the receipt of linked action replies (based on the Local SMS Linked Replies Indicator and SOA Linked Replies Indicator, in the NPAC Customer record), the NPAC SMS will send linked action replies when a recovery request is initiated and the amount of data returned is greater than the associated Blocking Factor.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      219                   Appendix B: Message Flow Diagrams    B.6.1      Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS (previously NNP flow 5.2)  This scenario demonstrates how a non-EDR Local SMS resynchronizes itself with the NPAC SMS.  This scenario demonstrates the recovery of additions, deletions and modifications of network and subscription version data. The recovery of this data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.  [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of Non-EDR Local SMS]  Local SMS personnel take action to resynchronize their Local SMS with the NPAC SMS.  The Non-EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set. The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.     1.   Non-EDR Local SMS sends the lnpDownload M-ACTION to start network data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified. If one of the following is selected (all-network-data, all NPA-NXX-X data, a range of NPA-NXX-X data, a single NPA-NXX-X), the NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.       2.   If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies. . In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).       3.   Non-EDR Local SMS sends the lnpDownload M-ACTION to start subscription data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified.       4.   If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data). All creates, modifies and                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      220                   Appendix B: Message Flow Diagrams           deletes are received, a single record for each subscription version. (i.e. no ranges). The Non-EDR Local SMS will receive all the activity on subscription versions with a LNP type of ‘pool’.      5.   If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).      6.   The old service provider SOA confirms the M-EVENT-REPORT.      7.   If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA of the status change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).      8.   The current service provider SOA confirms the M-EVENT-REPORT.      9.   If any corrections were issued to the resyncing Local SMS for subscription versions with LNP type equal to ‘pool’, the NPAC SMS will send the numberPoolBlockStatusAttributeValueChange to the current block holder SOA, if the numberPoolBlockSOA-Origination indicator is TRUE, with the current number pool block status and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains the discrepancy).      10.   The block holder SOA confirms the M-EVENT-REPORT.      11.   If deletes were sent for any subscription versions with LNP type equal to ‘pool’ that completed the broadcast of the M-DELETEs for a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs, who support the serviceProvNPA-NXX-X object, the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.      12.   Local SMS responds to the M-DELETE.      13.   Non-EDR Local SMS sends M-ACTION, lnpNotificationRecovery, to the NPAC SMS. The Non-EDR Local SMS specifies a time range.      14.   If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with the notification updates that occurred within the given time range. If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).      15.   Non-EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.      16.   NPAC SMS replies to the M-ACTION.    Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      221                   Appendix B: Message Flow Diagrams    B.6.1.1      Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM  This scenario demonstrates how a non-EDR Local SMS resynchronizes itself with the NPAC SMS using SWIM criteria.  This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, subscription version, and notification data. The recovery of network and subscription version data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.  [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM]  [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of Non-EDR Local using SWIM]  Local SMS personnel take action to resynchronize their Local SMS with the NPAC SMS. The Non-EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set. The Service Provider LSMS SWIM Recovery Indicator in the recovering Service Provider’s profile on the NPAC SMS must be set to TRUE and the recovery requests (lnpDownload and lnpNotificationRecovery) must include the SWIM attribute to recover only the messages that were missed. The Linked Replies indicator must also be set to TRUE.  The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.     1.   Non-EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: service provider data download. In this case, the Local SMS specifies the SWIM attribute.      2.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      3.   Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      4.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      5.   Non-EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: network data download. In this case, the Local SMS specifies the SWIM attribute.      6.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      222                   Appendix B: Message Flow Diagrams           In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.          The NPAC SMS sends the missed, serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.      7.   Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      8.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      9.   Non-EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: subscription data download. In this case, the Local SMS specifies the SWIM attribute.      10.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.          All creates, modifies and deletes are received, a single record for each subscription version. (i.e. no ranges). The Non-EDR Local SMS will receive all the activity on subscription versions with a LNP type of ‘pool’.      11.   Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      12.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      13.   If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA of the subscriptionVersionStatus change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).      14.   The old service provider SOA confirms the M-EVENT-REPORT.      15.   If any corrections were issued to the resyncing Local SMS, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA of the status change and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      223                   Appendix B: Message Flow Diagrams       16.   The current service provider SOA confirms the M-EVENT-REPORT.      17.   If any corrections were issued to the resyncing Local SMS for subscription versions with LNP type equal to ‘pool’, the NPAC SMS will send the numberPoolBlockStatusAttributeValueChange to the current block holder SOA, if the numberPoolBlockSOA-Origination indicator is TRUE, with the current number pool block status and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains the discrepancy).      18.   The block holder SOA confirms the M-EVENT-REPORT.      19.   If deletes were sent for any subscription versions with LNP type equal to ‘pool’ that completed the broadcast of the M-DELETEs for a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs, who support the serviceProvNPA-NXX-X object, the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.      20.   Local SMS responds to the M-DELETE.      21.   Non-EDR Local SMS sends the lnpNotificationRecovery M-ACTION to start SWIM: notification data download. The Non-EDR Local SMS specifies the SWIM attribute.      22.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      23.   Non-EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      24.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.                  Note:    If any of the SWIM processing recovery responses from the NPAC SMS (SwimProcessing-Recovery Response) include a stop-date (timestamp), this indicates that the SWIM Maximum tunable has been exceeded, and SWIM data accumulation stopped at the provided stop-date (timestamp). In order to fully synchronize with the NPAC SMS, since additional messages may have been missed, the Service Provider will want to issue additional recovery requests specifying criteria other than SWIM to get all missing data (see B.7.1 for example). Alternatively, upon receiving the stop-date timestamp the Service Provider may perform time-based recovery after each SWIM-based recovery request for each data type. For example, the Service Provider would request SWIM-based recovery for SP data and if they receive a stop-date timestamp they would then perform time-base recovery for SP data; then the Service Provider would request SWIM-based recovery for Network Data and if they receive a stop-date timestamp they would then perform time-based recovery for Network Data – and so on and so forth for each data type.          Upon successful recovery, SWIM accumulation will be turned back on for the Service Provider.        25.   Non-EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.      26.   NPAC SMS replies to the M-ACTION.    Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      224                   Appendix B: Message Flow Diagrams    B.6.2      Sequencing of Events on Initialization/Resynchronization of EDR Local SMS (previously NNP flow 5.1)  This scenario demonstrates how an EDR Local SMS resynchronizes itself with the NPAC SMS.  These scenarios demonstrate the recovery of additions, deletions and modifications of network, subscription version and number pool block data. The recovery of this data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.  [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of EDR Local SMS]  The EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set.  The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.     1.   EDR Local SMS sends lnpDownload M-ACTION to start network data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified. If one of the following is selected (all-network-data, all NPA-NXX-X data, a range of NPA-NXX-X data, a single NPA-NXX-X), the NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.      2.   If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).      3.   EDR Local SMS sends the lnpDownload M-ACTION to start subscription data download. In this case, the Local SMS specifies the start time and end time. There are criteria other than time which may be specified.      4.   If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data). All creates, modifies and deletes are received, a single record for each subscription version. (i.e. no ranges). The EDR Local SMS will not receive any activity on subscription versions with LNP type of ‘pool’.      5.   If any corrections were issued to the resyncing Local SMS that involved the activation of a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      225                   Appendix B: Message Flow Diagrams       6.   The old service provider SOA confirms the M-EVENT-REPORT.      7.   If any corrections were issued to the resyncing Local SMS that involved a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).      8.   The current service provider SOA confirms the M-EVENT-REPORT.      9.   EDR Local SMS sends the lnpDownload M-ACTION to start number pool block data download. The Local SMS specifies the start time.      10.   NPAC SMS responds to M-ACTION with updates.      11.   NPAC SMS sends the M-EVENT-REPORTs to the block holder SOAs for any number pool block with the SOA-Origination indicator set to true whose numberPoolBlockFailed-SP-List and possibly numberPoolBlockStatus were just updated due to the number pool block download.      12.   Block holder SOA confirms to the M-EVENT-REPORT.      13.   If deletes were sent for any number pool blocks that completed the broadcast of the M-DELETEs of a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.      14.   Local SMS responds the M-DELETE.      15.   EDR Local SMS sends M-ACTION, lnpNotificationRecovery, to the NPAC SMS. The EDR Local SMS specifies a time range.      16.   If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with the notification updates that occurred within the given time range. If the requested notification(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).      17.   EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.      18.   NPAC SMS replies to the M-ACTION.    Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      226                   Appendix B: Message Flow Diagrams    B.6.2.1     Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM  This scenario demonstrates how an EDR Local SMS resynchronizes itself with the NPAC SMS using SWIM criteria.  This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, subscription version, number pool block, and notification data. The recovery of network, subscription version and number pool block data can cause status attribute value changes and serviceProvNPA-NXX-X deletions.  [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of EDR Local SMS using SWIM]  Local SMS personnel take action to resynchronize their Local SMS with the NPAC SMS.  The EDR Local SMS establishes an association to the NPAC SMS with the resynchronization flag on, along with the network data management (networkDataMgmt) and data download (dataDownload) association functions set. The Service Provider LSMS SWIM Recovery Indicator in the recovering Service Provider’s profile on the NPAC SMS must be set to TRUE and the recovery request (lnpDownload and lnpNotificationRecovery) must include the SWIM attribute to recover only the messages that were missed. The Linked Replies indicator must also be set to TRUE.  The NPAC SMS will queue all current activity on the NPAC SMS until the Local SMS sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.     1.   EDR Local SMS sends lnpDownload M-ACTION to start SWIM: service provider data download. In this case, the Local SMS specifies the SWIM attribute.      2.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      3.   EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      4.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      5.   EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: network data download. In this case, the Local SMS specifies the SWIM attribute.      6.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      227                   Appendix B: Message Flow Diagrams           a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.          The NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the Local SMS’s “NPAC Customer LSMS NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.      7.   EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      8.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      9.   EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: subscription data download. In this case, the Local SMS specifies the SWIM attribute.      10.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.          All creates, modifies and deletes are received, a single record for each subscription version. (i.e. no ranges). The EDR Local SMS will not receive any activity on subscription versions with LNP type of ‘pool’.      11.   EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      12.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      13.   If any corrections were issued to the resyncing Local SMS that involved the activation of a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the old service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the old service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).      14.   The old service provider SOA confirms the M-EVENT-REPORT.      15.   If any corrections were issued to the resyncing Local SMS that involved a subscription version with the LNP type not equal to ‘pool’, the NPAC SMS will send, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA with the current subscriptionVersionStatus and a list of failed Local SMSs (minus the resyncing Local SMS that no longer contains a discrepancy).      16.   The current service provider SOA confirms the M-EVENT-REPORT.      17.   EDR Local SMS sends the lnpDownload M-ACTION to start SWIM: number pool block data download. The Local SMS specifies the SWIM attribute.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      228                   Appendix B: Message Flow Diagrams       18.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      19.   EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      20.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      21.   NPAC SMS sends the M-EVENT-REPORTs to the block holder SOAs for any number pool block with the SOA-Origination indicator set to true whose numberPoolBlockFailed-SP-List and possibly numberPoolBlockStatus were just updated due to the number pool block download.      22.   Block holder SOA confirms to the M-EVENT-REPORT.      23.   If deletes were sent for any number pool blocks that completed the broadcast of the M-DELETEs of a number pool block and corresponding subscription versions, then the NPAC SMS will send to all other Local SMSs the M-DELETE for the serviceProvNPA-NXX-X object. The NPAC SMS will queue up the M-DELETE request for the recovering Local SMS and send it at the completion of recovery mode.      24.   Local SMS responds the M-DELETE.      25.   EDR Local SMS sends the lnpNotificationRecovery M-ACTION to start SWIM: notification data download. The EDR Local SMS specifies the SWIM attribute.      26.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the Local SMS should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      27.   EDR Local SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      28.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.                  Note:    If any of the SWIM processing recovery responses from the NPAC SMS (SwimProcessing-RecoveryResponse) include a stop-date (timestamp), this indicates that the SWIM Maximum tunable has been exceeded, and SWIM data accumulation stopped at the provided stop-date (timestamp). In order to fully synchronize with the NPAC SMS, since additional messages may have been missed, the Service Provider will want to issue additional recovery requests specifying criteria other than SWIM to get all missing data (see B.7.2 for example). Alternatively, upon receiving the stop-date timestamp the Service Provider may perform time-based recovery after each SWIM-based recovery request for each data type. For example, the Service                               March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      229                   Appendix B: Message Flow Diagrams                       Provider would request SWIM-based recovery for SP data and if they receive a stop-date timestamp they would then perform time-base recovery for SP data; then the Service Provider would request SWIM-based recovery for Network Data and if they receive a stop-date timestamp they would then perform time-based recovery for Network Data – and so on and so forth for each data type.        Upon successful recovery, SWIM accumulation will be turned back on for the Service Provider.        29.   EDR Local SMS sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.      30.   NPAC SMS replies to the M-ACTION.    Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      230                   Appendix B: Message Flow Diagrams    B.6.3      Sequencing of Events on Initialization/Resynchronization of SOA  This scenario demonstrates how a SOA resynchronizes itself with the NPAC SMS. In this example, the SOA supports network data over the SOA.  If the SOA supports a separate SOA channel for notifications, then they should associate with the notificationDownload function bit.  This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, and notification data.  [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of SOA]  SOA takes action to resynchronize their SOA with the NPAC SMS.  The SOA establishes an association to the NPAC SMS with the resynchronization flag on, and the network data management (networkDataMgmt) association function set. The NPAC SMS will queue all current activity on the NPAC SMS until the service SOA sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.     1.   SOA sends the lnpDownload M-ACTION to start network data download. In this case, the SOA specifies the start time and end time. There are criteria other than time which may be specified. If one of the following is selected (all-network-data, all NPA-NXX-X data, a range of NPA-NXX-X data, a single NPA-NXX-X), the NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the SOA’s “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.      2.   If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to FALSE, the SOA responds to the M-ACTION with updates. If the requested object(s) exist and the Local SMS Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).      3.   SOA sends M-ACTION, lnpNotificationRecovery, to the NPAC SMS. The SOA specifies a time range.      4.   If the requested notification(s) exist and the SOA Linked Replies Indicator is set to FALSE, the NPAC SMS responds to the M-ACTION with the notification updates that occurred within the given time range. If the requested notification(s) exist and the SOA Linked Replies Indicator is set to TRUE, the NPAC SMS will respond with either a single M-ACTION reply or with a linked M-ACTION reply. In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response). In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies, followed by a non-linked empty normal response (indicating the end of the linked reply data).      5.   SOA sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.      6.   NPAC SMS replies to the M-ACTION.    Any activity that the NPAC SMS had queued up during the recovery period will now be sent.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      231                   Appendix B: Message Flow Diagrams    Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      232                   Appendix B: Message Flow Diagrams    B.6.3.1       Sequencing of Events on Initialization/Resynchronization of SOA using SWIM  This scenario demonstrates how a SOA resynchronizes itself with the NPAC SMS using SWIM criteria. In this example, the SOA supports network data, data downloads and notifications over the SOA. If the SOA supports a separate SOA channel for notifications, then they should associate with the notificationDownload function bit. This scenario demonstrates the recovery of additions, deletions and modifications of service provider, network, and notification data. [Graphic Omitted: Sequencing of Events on Initialization/Resynchronization of SOA using SWIM]  SOA takes action to resynchronize their SOA with the NPAC SMS. The SOA establishes an association to the NPAC SMS with the resynchronization flag on, and the network data management (networkDataMgmt) association function set. The Service Provider SOA SWIM Indicator in the recovering Service Provider’s profile on the NPAC SMS must be set to TRUE and the recovery requests (lnpDownload and lnpNotificationRecovery) must include the SWIM attribute to recover only the messages that were missed. The Linked Replies indicator must also be set to TRUE. The NPAC SMS will queue all current activity on the NPAC SMS until the SOA sends in the lnpRecoveryComplete action. All updates issued since the association establishment will be sent at the next normally scheduled retry interval.    1.   SOA sends the lnpDownload M-ACTION to start swim: service provider data download. In this case, the SOA specifies the SWIM attribute.      2.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the SOA should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      3.   SOA issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      4.   NPAC SMS issues an M-EVENT-REPORT Reply SwimProcessing-RecoveryResponse.      5.   SOA sends lnpDownload M-ACTION to start SWIM: network data download. In this case, the SOA specifies the SWIM attribute.      6.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      233                   Appendix B: Message Flow Diagrams           In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the SOA should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.          The NPAC SMS sends the serviceProvNPA-NXX-X updates (creates, modifies, deletes) if the SOA’s “NPAC Customer SOA NPA-NXX-X Indicator” in their service provider profile on the NPAC SMS states it supports the object.      7.   SOA issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACITON reply.      8.   NPAC SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResponse.      9.   SOA sends lnpNotificationRecovery M-ACTION to start SWIM: notification data download. The SOA specifies the SWIM attribute.      10.   The NPAC SMS will respond with either a single M-ACTION reply or with linked M-ACTION replies for the messages that were missed.          In the case where the amount of data to be returned is less than or equal to the associated Blocking Factor (including the case where no objects are found), the M-ACTION response will be a single normal response (i.e., non-linked response) including a status and ACTION ID.          In the case where the amount of data to be returned is greater than the associated Blocking Factor, the M-ACTION response will be multiple linked M-ACTION replies (including a status and ACTION ID) followed by a non-linked empty normal response (indicating the end of the linked reply data). When a status of “swim-more-data” is provided, this indicates there is more data of this type to be recovered and the SOA should initiate subsequent M-ACTION requests for this data including the ACTION ID provided by the NPAC SMS in the M-ACTION linked reply.      11.   SOA issues an M-EVENT-REPORT SwimProcessing-RecoveryResults notification to the NPAC SMS indicating the replies for this data type were successfully processed. This notification must include the ACTION ID provided by the NPAC SMS in the M-ACTION reply.      12.   NPAC SMS issues an M-EVENT-REPORT SwimProcessing-RecoveryResponse.                  Note:    If any of the SWIM processing recovery responses from the NPAC SMS (SwimProcessing-RecoveryResponse) include a stop-date (timestamp), this indicates that the SWIM Maximum tunable has been exceeded, and SWIM data accumulation stopped at the provided stop-date (timestamp). In order to fully synchronize with the NPAC SMS, since additional messages may have been missed, the Service Provider will want to issue additional recovery requests specifying criteria other than SWIM to get all missing data (see B.7.3 for example). Alternatively, upon receiving the stop-date timestamp the Service Provider may perform time-based recovery after each SWIM-based recovery request for each data type. For example, the Service Provider would request SWIM-based recovery for SP data and if they receive a stop-date timestamp they would then perform time-base recovery for SP data; then the Service Provider would request SWIM-based recovery for Network Data and if they receive a stop-date timestamp they would then perform time-based recovery for Network Data – and so on and so forth for each data type.                Upon successful recovery, SWIM accumulation will be turned back on for the Service Provider.        13.   SOA sends M-ACTION, lnpRecoveryComplete, to set the resynchronization flag off.      14.   NPAC SMS replies to the M-ACTION.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      234                   Appendix B: Message Flow Diagrams    Normal processing resumes and any activity that the NPAC SMS had queued up during the recovery period will now be sent at the next scheduled retry interval.                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      235                   Appendix B: Message Flow Diagrams    B.7       Miscellaneous  B.7.1            SOA/Local SMS Notification of Scheduled NPAC Downtime  This scenario shows SOA/Local SMS notification of scheduled NPAC downtime. [Graphic Omitted: SOA/Local SMS Notification of Scheduled NPAC Downtime]       Action is taken by NPAC SMS personnel to schedule downtime for the NPAC SMS system     1.   The NPAC SMS sends an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT to the Local SMSs.      2.   The Local SMSs respond by sending an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT confirmation back to the NPAC SMS.      3.   The NPAC SMS sends an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT to all SOAs.      4.   The SOA(s) respond by sending an lnpNPAC-SMS-Operational-Information M-EVENT-REPORT confirmation back to the NPAC SMS.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      236                   Appendix B: Message Flow Diagrams    B.7.2            NPA-NXX Split  This scenario shows NPAC SMS personnel initiation of an NPA-NXX split that does not involve a Number Pool Block object. [Graphic Omitted: NPA-NXX Split]  The NPAC SMS will create NPA-NXX split data based on information in the NPA Split Load Flat File from an industry source. The old NPA-NXX exists and is past the effective date of the object. The NPAC SMS will automatically generate the add/delete of the new NPA-NXX based on information in the NPA Split Load Flat File from an industry source. The permissive dialing period begins.  The NPAC SMS updates all subscription version records in its local database that are affected by the NPA-NXX Split. The TN field will be updated with the new NPA. Internal mapping between the old and new NPA-NXXs for the TNs is maintained. The NPAC SMS accepts requests involving the old and new NPA-NXX values but only broadcasts using the new NPA-NXX value. The permissive dialing period expires.     1.   NPAC SMS deletes the old serviceProvNPA-NXX object locally.      2.   NPAC SMS responds to the M-DELETE.      3.   The NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the Local SMSs who are accepting downloads for this NPA-NXX.      4.   At the same time as step 7, the NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the SOAs who are accepting downloads for this NPA-NXX.      5.   The Local SMS responds to the M-DELETE.      6.   The SOA responds to the M-DELETE.    The NPAC SMS updates all subscription version records in its local database that match the specified TN range by updating the TN value for each object and removing the internal field. All Local SMS, SOA and NPAC SMS will now use the new NPA-NXX for all requests.                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      237                   Appendix B: Message Flow Diagrams    B.7.2.1       NPA-NXX Split that contains a block of pooled TNs Part 1 (previously NNP flow 7)  In this scenario, the NPAC SMS personnel initiate an NPA-NXX split that contains a block of pooled TNs. [Graphic Omitted: NPA-NXX Split that contains a block of pooled TNs Part 1]  The NPAC SMS will create NPA-NXX split data based on information in the NPA Split Load Flat File from an industry source. The old NPA-NXX and NPA-NXX-X exist and are past the effective date of the objects. The NPAC SMS will automatically generate the add/ delete of the new NPA-NXX based on information in the NPA Split Load Flat File from an industry source.    1.   The NPAC SMS automatically creates the new serviceProvNPA-NXX-X objects with the effective date equal to the date of the start of permissive dialing.      2.   The NPAC SMS responds to the M-CREATE.      3.   The NPAC SMS broadcasts each serviceProvNPA-NXX-X M-CREATE to the Local SMSs that support the object according to their NPAC Customer LSMS NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.      4.   At the same time as step 3, the NPAC SMS broadcasts each serviceProvNPA-NXX-X M-CREATE to the SOAs that support the object according to their NPAC Customer SOA NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.      5.   The Local SMS responds to the M-CREATE request.      6.   The SOA responds to the M-CREATE request.    The NPAC SMS updates all subscription version and number pool block records in its local database that match the specified TN range. The TN or NPA-NXX-X field will be updated with the new NPA and a data field internal to the NPAC SMS will be set to the previous TN or NPA-NXX-X value (old NPA). The permissive dialing period starts.  During the permissive dialing period, the NPAC SMS accepts requests involving the old and new NPA-NXX values according to the following rules:      •   For subscription versions and number pool blocks, the NPAC SMS will accept either the new or old NPA-NXX value, but only broadcast using the new NPA-NXX value.        •   The creation of a new serviceProvNPA-NXX-X object using either the old or new NPA-NXX value, but the NPAC SMS will create and broadcast both the old and new serviceProvNPA-NXX-X object creations to those service providers who support the serviceProvNPA-NXX-X object according to their NPAC Customer LSMS NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.        •   If a serviceProvNPA-NXX-X is to be removed (de-pooled), the NPAC SMS will broadcast the M-DELETEs for both the old and new serviceProvNPA-NXX-X objects.        •   The removal of a NXX from the NPA-NXX split will cause the broadcast of the M-DELETE of the new serviceProvNPA-NXX-X object to the Local SMSs.    The permissive dialing period continues into the next flow.                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      238                   Appendix B: Message Flow Diagrams    B.7.2.2       NPA-NXX Split that contains a block of pooled TNs Part 2 (previously NNP flow 7)  The Permissive Dialing Period is in progressive for an NPA-NXX split. This flow shows what occurs at the end of the Permissive Dialing Period. [Graphic Omitted: NPA-NXX Split that contains a block of pooled TNs Part 2]                            March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      239                   Appendix B: Message Flow Diagrams    The permissive dialing period expires.     1.   NPAC SMS deletes the old serviceProvNPA-NXX-X object locally.      2.   NPAC SMS responds to the M-DELETE.      3.   The NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX-X objects to the Local SMSs who are supporting the object according to the NPAC Customer LSMS NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.      4.   At the same time as step 3, the NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX-X objects to the SOAs who are supporting the object according to the NPAC Customer SOA NPA-NXX-X Indicator in their service provider profile on the NPAC SMS.      5.   The Local SMS responds to the M-DELETE.      6.   The SOA responds to the M-DELETE.      7.   NPAC SMS deletes the old serviceProvNPA-NXX object locally.      8.   NPAC SMS responds to the M-DELETE.      9.   The NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the Local SMSs who are supporting downloads of the object according to their NPA-NXX filters on the NPAC SMS.      10.   At the same time as step 9, the NPAC SMS sends individual M-DELETE for all the old serviceProvNPA-NXX objects to the SOAs who are supporting the object according to their NPA-NXX filters on the NPAC SMS.      11.   The Local SMS responds to the M-DELETE.      12.   The SOA responds to the M-DELETE.    The NPAC SMS updates all subscription version and number pool block records in its local database that match the specified TN range by updating the TN or NPA-NXX-X value for each object and removing the internal field. All Local SMS, SOA and NPAC SMS will now use the new NPA-NXX and NPA-NXX-X for all requests.                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      240                   Appendix B: Message Flow Diagrams    B.7.3            Mass Update  NPAC SMS personnel can perform a mass update on subscription data. [Graphic Omitted: Mass Update]         Action is taken by the NPAC SMS personnel to request that a mass update be performed on active subscription data.          Search the subscription database for subscription versions that match the specified mass update criteria. Perform steps 1 through 4 for the allowable range of subscription versions. The NPAC logs as errors subscription versions that match the mass update criteria but are in the wrong state.      1.   The NPAC SMS sends an M-SET on the subscription versions to the Local SMS, that is accepting downloads for the NPA-NXX of the subscription versions.      2.   The Local SMS replies to the M-SET.      3.   The NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA.      4.   The service provider SOA sends a confirmation to the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      241                   Appendix B: Message Flow Diagrams    B.7.3.1       Mass Update for a range of TNs that contains a Number Pool Block (previously NNP flow 8)  In this scenario, the NPAC SMS personnel perform a mass update on a range of TNs that includes a number pool block object. [Graphic Omitted: Mass Update for a range of TNs that contains a Number Pool Block]     Action is taken by NPAC SMS personnel to perform a mass update.      The NPAC SMS may specify the service provider ID, LNP type and TN-Range in its selection criteria. The LNP type can be restricted as only LISP, only LSPP, only POOL, or none (which would then include all three types).      The NPAC SMS can update only the routing information (LRN, DPC and SSN data).      If the LNP type includes ‘pool’ TNs, the TN-Range specified must include a number pool block’s entire TN-Range.      The NPAC SMS searches the number pool block and subscription version databases for the objects that match the selection criteria. For all objects that match the criteria, the following occurs:      1.   NPAC SMS sends the M-SET for the number pool block objects to the EDR Local SMSs who are accepting updates for the NPA-NXX.      2.   NPAC SMS sends the M-SET, scope and filtered for the appropriate criteria, for the non-pooled subscription version updates to the EDR Local SMS who are accepting updates for the NPA-NXX.      3.   NPAC SMS sends the M-SET, scope and filtered for the appropriate criteria, for the subscription version updates to the non-EDR Local SMSs who are accepting updates for the NPA-NXX.      4.   EDR Local SMS responds to the M-SET for the number pool block object.      5.   EDR Local SMS responds to the M-SET for the subscription versions.      6.   Non-EDR Local SMS responds to the M-SET for the subscription versions.      7.   NPAC SMS sends, depending upon the current service provider’s TN Range Notification Indicator, a subscriptionVersionStatusAttributeValueChange or subscriptionVersionRangeStatusAttributeValueChange M-EVENT-REPORT to the current service provider SOA for any subscription versions, not of LNP type set to ‘pool’, that were updated to a status of ‘active’.      8.   SOA confirms the M-EVENT-REPORT.      9.   NPAC SMS sends the M-EVENT-REPORT numberPoolBlockStatusAttributeValueChange for the status being set to ‘active’ to the block holder service provider SOA for any number pool block objects updated to a status of ‘active’ if the numberPoolBlockSOA-Origination indicator is ‘TRUE’.      10.   SOA confirms the M-EVENT-REPORT.                              March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      242                   Appendix B: Message Flow Diagrams    B.7.4            Application Level Heartbeat Requests  B.7.4.1       NPAC initiated Application Level Heartbeat Request to local system       This scenario shows the NPAC sending an Application Level Heartbeat Message to the SOA/LSMS.  [Graphic Omitted: NPAC initiated Application Level Heartbeat Request to local system]     1.   The NPAC SMS sends an M-EVENT-REPORT ApplicationLevelHeartbeat Request to the SOA/Local SMS that support this feature, after a configurable amount of time with no message traffic      2.   The SOA/Local SMS issues an M-EVENT-REPORT ApplicationLevelHeartbeat Response back to the NPAC SMS.    If the response in step 2 is not provided within the timeout period, the association is aborted by the NPAC SMS.                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      243                   Appendix B: Message Flow Diagrams    B.7.4.2       Local system initiated Application Level Heartbeat request  This scenario show the SOA/LSMS sending an Application Level Heartbeat Message to the NPAC SMS. [Graphic Omitted: Local system initiated Application Level Heartbeat request]     1.   The SOA/LSMS sends an M-EVENT-REPORT ApplicationLevelHeartbeat Request to the NPAC SMS, after a configurable amount of time with no message traffic       2.   The NPAC SMS issues an M-EVENT-REPORT ApplicationLevelHeartbeat Response back to the SOA/LSMS.    If the response in step 2 is not provided within the timeout period, the expectation is that the SOA/LSMS would abort their association to the NPAC SMS.                           March 9, 2006    NANC Version 3.3.2a    NPAC SMS Interoperable Interface Specification   Release 3.3©1997 — 2006 NeuStar, Inc.      244                   -----END PRIVACY-ENHANCED MESSAGE-----