> ![](media/image1.emf){width="2.415277777777778in"
> height="0.7361111111111112in"}

+------------------------+---------------------------------------------+
| Alliance for           | > **INDUSTRY NUMBERING COMMITTEE (INC)**    |
| Telecommunications     | >                                           |
|                        | > **INITIAL REPORT TO THE**                 |
| Industry Solutions     | >                                           |
|                        | > **NORTH AMERICAN NUMBERING COUNCIL        |
| *Sponsor of*           | > (NANC)**                                  |
|                        | >                                           |
| ![](media/image        | > **ON**                                    |
| 2.emf){width="2.375in" | >                                           |
| height="               | > **NUMBER POOLING**                        |
| 0.6333333333333333in"} | >                                           |
|                        | > **Version 2**                             |
| Industry Numbering     | >                                           |
|                        | > **December 4, 1997**                      |
| Committee              |                                             |
|                        |                                             |
| A forum of the Carrier |                                             |
| Liaison Committee      |                                             |
|                        |                                             |
| 1200 G Street NW       |                                             |
|                        |                                             |
| Suite 500              |                                             |
|                        |                                             |
| Washington DC 20005    |                                             |
|                        |                                             |
| www.atis.org           |                                             |
|                        |                                             |
| Jo Gallagher           |                                             |
|                        |                                             |
| Moderator              |                                             |
|                        |                                             |
| Cathy Handley          |                                             |
|                        |                                             |
| Assistant Moderator    |                                             |
|                        |                                             |
| Susan Miller           |                                             |
|                        |                                             |
| Vice President and     |                                             |
| General Counsel        |                                             |
|                        |                                             |
| ATIS                   |                                             |
|                        |                                             |
| John C. Manning        |                                             |
|                        |                                             |
| Director - Industry    |                                             |
| Forums                 |                                             |
|                        |                                             |
| ATIS                   |                                             |
|                        |                                             |
| 202.434.8842           |                                             |
|                        |                                             |
| Fax: 202.393.5453      |                                             |
|                        |                                             |
| jmanning@atis.org      |                                             |
+------------------------+---------------------------------------------+
|                        |                                             |
+------------------------+---------------------------------------------+

> **INDUSTRY NUMBERING COMMITTEE (INC)**
>
> **INITIAL REPORT TO THE**
>
> **NORTH AMERICAN NUMBERING COUNCIL (NANC)**

**ON NUMBER POOLING**

[Table of Contents]{.underline}

[Page]{.underline}

Section 1.0 Introduction 3

Section 2.0 Definition of Pooling 3

Section 3.0 Background - Concept of Pooling 4

Section 4.0 The Attributes of Pooling 6

Section 5.0 General Areas of Impact 10

Section 6.0 Principles, Assumptions and Constraints 13

Section 7.0 Functional Considerations 15

Section 8.0 Number Assignment 32

Section 9.0 Operations/Provisioning 32

Section 10.0 Number Administration 36

Section 11.0 Alternative Arrangements for Number Pooling 39

Section 12.0 Criteria for Assessment of Alternatives 41

Section 13.0 Evaluation of Alternatives 44

Section 14.0 Considerations Related to the Implementation of Pooling 44

Section 15.0 Transition 45

Section 16.0 Recommendations 46

Appendix 1 48

Appendix 2 60

**INDUSTRY NUMBERING COMMITTEE (INC)**

**INITIAL REPORT TO THE**

**NORTH AMERICAN NUMBERING COUNCIL (NANC)**

**ON NUMBER POOLING**

**1.0 INTRODUCTION**

This report defines, describes, and analyzes the number administration
and assignment process known as number pooling. The report identifies
the attributes or parameters associated with pooling, discusses the
principles, assumptions, and constraints under which pooling can
potentially be provided, develops specific alternatives for the
implementation of pooling, and describes the impact of number pooling on
network architecture, number assignment and administration processes. In
addition, the report assesses the practicality of pooling with respect
to certain criteria and identifies criteria for the characterization of
the pooling alternatives, uses those criteria to assess the
alternatives, explains how the transition from the current (central
office based) number assignment process to pooling could potentially
take place, and offers recommendations and conclusions relative to the
use of pooling.

The report was compiled under the leadership of the Industry Numbering
Committee (INC), which operates as part of the Carrier Liaison Committee
(CLC) of the Alliance for Telecommunications Industry Solutions (ATIS).
This industry effort was directed in part by the North American
Numbering Council (NANC), a federal advisory committee for the FCC, and
included participation of the two NANC Working Groups: the North
American Numbering Plan Administration (NANPA) Working Group and the
Local Number Portability Administration (LNPA) Working Group.

**2.0 DEFINITION OF POOLING**

*Pooling of geographic numbers in a local number portability environment
is a number administration and assignment process which allocates
numbering resources to a shared reservoir associated with a designated
geographic area*.

Initially, the designated geographic area is limited to an existing rate
center within a geographic Numbering Plan Area (NPA) with possible
future expansion to beyond the rate center.[^1] The numbering resource
in the shared reservoir would be available, potentially, in blocks of
numbers or on an individual telephone number basis for assignment to
competing service providers participating in local number portability
for the purpose of providing services to customers in that area.

**3.0 BACKGROUND - THE CONCEPT OF POOLING**

The concept of number pooling as an alternative to the current number
administration and assignment processes has generated considerable
interest as a potential means for the more efficient utilization of
numbering resources.

The concept of pooling is mentioned in the Carrier Liaison Committee
Industry Carriers Compatibility Forum (CLC ICCF) Routing and Rating
Workshop (ICCF Report on Rating and Routing in a Competitive Local
Environment - ICCF96-1220-016 - Issued 12/20/96) which suggested that
pooling be investigated as an alternative to the various techniques that
were evaluated in the ICCF report. Subsequent to this report various
pooling type approaches have been suggested by different industry
participants. These include the NXX-X/LRN and the pooling of unassigned
numbers.

The potential need for and the anticipated advantages of number pooling
are described below.

3.1 THE POTENTIAL NEED FOR NUMBER POOLING

The onset of local exchange competition, and in particular the need that
under current call rating mechanisms all local exchange carriers require
a central office code per rate center, has resulted in the increased
incidence of central office code exhaust and the associated need for NPA
relief. This situation is compounded by the increasing demand for
telephone numbers, fueled by the demand for second lines for both
residential and business applications, as well as the use of fax
machines, modems, and wireless services. The resulting demand has, in
many areas, created a shortage of central office (NXX) codes even if
there remains a significant quantity of unassigned line numbers. An
alternative to the current number assignment practice which assigns
service providers a full central office code (i.e., a block of 10,000
numbers) could offer relief from this condition.

3.2 ANTICIPATED ADVANTAGES OF NUMBER POOLING

Number pooling may promote number conservation and is therefore
potentially advantageous. Specifically, the assignment of numbers to
service providers in finer granularity than blocks of 10,000 -- that is,
for example, in blocks of 1000 or by individual telephone number---could
afford improved utilization of numbering resources. Further, a, pool of
numbers, if available to all providers serving a defined area, need only
be large enough to accommodate the collective needs of those providers.
Within a pooled environment the total number of NXX codes assigned
should be fewer than if a full NXX code were assigned to each service
provider, and the numbering resources should last for a longer period of
time.

In addition to providing improved number utilization, number pooling may
enhance local service competition by reducing the incentive for
customers to select a service provider based solely on the ability of
that provider to offer a specific telephone number.

3.3 ACCOMMODATION OF NUMBER POOLING

The potential advantages associated with number pooling cannot be
realized without the necessary network, operations, and administrative
modifications required to implement the pooling process. The time,
effort, and cost associated with these modifications must be recognized
and weighed against the potential benefits to be derived before a
decision to develop and implement pooling in any one particular
geographic area can be made. It is further recognized, however, that
specific regulatory directives may demand the implementation of pooling
regardless of the perceived cost/benefit considerations.

3.4 APPLICABILITY OF NUMBER POOLING

Although pooling may be considered generally beneficial, its
implementation may not prove to be desirable in all areas. The
understanding that number pooling will enhance the efficiency of number
utilization, and therefore delay the need for area code relief is based
upon the belief that current number assignment practices (the assignment
of full NXXs per rate center) are inherently inefficient because some
NXXs may never achieve optimum utilization levels. There is no doubt
that in many, if not most areas, this is indeed the case. It may be,
however, that in some environments, perhaps specifically in those which
are densely populated and where there is a large demand for
communications services, number utilization is quite high and the level
of unused numbers within central office codes assigned to any service
provider in that area is quite small. In such areas, the benefit
provided by number pooling may not be significant. Accordingly, the
implementation of pooling may need to be area specific, with deployment
only in those areas where the benefit of increased utilization and
delayed exhaust exceeds some yet to be determined threshold.

3.5 THE CURRENT USE OF NUMBER POOLING

Individual telephone number pooling is currently used only for the toll
free (800/888) numbering resources. Toll free numbers reside in the
800/888 Service Management System (SMS) and are available to all SMS
users (i.e., toll free service providers). Users interface with the SMS
database system, via either a manual or mechanized process, to
interrogate the system to identify spare and reserved numbers for their
subscribers. Because the toll free numbering resources are
non-geographic, the area of pooling covers most of the NANP area and all
numbers are available for service in all areas. Pooling of geographic
numbers would demand the definition of areas of pooling and constrain
the assignment of given geographic numbers to designated areas.

**4.0 THE ATTRIBUTES OF POOLING**

The attributes of pooling describe key characteristics or parameters
from which different pooling alternatives can be derived. The attributes
defined here include level, scope, applicable numbering resources, and
the type of number inventory.

4.1 LEVEL

The level of pooling refers to the granularity with which numbers are
assigned and/or allocated to the service provider. Pooling might be
implemented by provisioning blocks of numbers in quantities smaller than
the block of 10,000 numbers offered under the current CO Code Assignment
Guidelines. Quantities that might be considered include 1000s blocks or
100s blocks. It is assumed that block assignments will provide numbers
in sequential order. That is, a service provider who is assigned the
"2000s" block within a given NXX code would receive the numbers 2000
through 2999.

Pooling may also provide service providers the capability to request the
assignment and/or allocation of numbers at the individual telephone
number t level. With this level of pooling, service providers would be
able to request one or more numbers at a time. Individual telephone
number pooling, although oriented to the random selection of numbers,
could support the assignment of a group of sequential numbers if
available.

4.2 SCOPE

The scope of pooling defines the geographic area within which the
pooling of numbers is supported. Initially, the area of pooling is
confined to within a rate center. This will permit current wireline call
rating mechanisms to be maintained. Limiting pooling to within a rate
center would maintain the current association of telephone numbers --
specifically, the NXX code -- with a known, given geographic area (i.e.,
rate center).

It is possible, however, that an area of pooling could extend beyond a
single rate center. In general, increasing the area of pooling offers
the ability to serve more end user customers with the numbering
resources within the pool and could potentially increase number
utilization. Implementation of pooling beyond a rate center boundary
would require additional capabilities to properly rate the call,
specifically the capability associated with the implementation of number
portability out of the rate center. With pooling out of the rate center,
additional questions regarding the absolute extent of the area of
pooling must be addressed. The area of pooling could extend beyond a
rate center but still be within an NPA boundary; or the area of pooling
could conceivably comprise an entire state. It is not contemplated that
the area of pooling would extend beyond a state boundary.

4.3 NUMBERING RESOURCES SUBJECT TO POOLING

The initial establishment of a numbering pool could include only growth
numbers \-- that is, numbers in unassigned NXX codes; or, it could
include embedded numbers (subject to the possibility of a threshold, yet
to be determined) \-- that is, numbers from NXX codes previously
assigned to a given service provider; or both. For example, if pooling
were implemented with 1000s block assignments, the pool would be
populated with all 1000s blocks from unassigned NXX codes. However, it
is certainly feasible that the pool could also contain 1000s blocks from
NXXs allocated to service providers but in which there were no end user
assignments. It is also possible that even those 1000s blocks within an
NXX code allocated to a given service provider which have a minimal
number of end user assignments (yet to be determined) could be allocated
to another service provider.

If individual telephone number pooling were implemented, similar
considerations relative to growth and embedded numbers would have to be
addressed. The establishment of the industry inventory pool would no
doubt contain numbers from unassigned NXX codes but could also include
numbers from allocated NXXs.

4.4 NUMBER INVENTORY

Numbers assigned to a given service provider can be placed in an
inventory maintained by that service provider (Service Provider
Inventory) and subsequently assigned from that inventory to end users.
This is what is done today after an NXX code is assigned to a service
provider. A pictorial representation of number pooling with the use of
service provider inventories is shown below.

Alternatively, it is possible that a service provider would not maintain
its own inventory but use only an industry inventory, which the service
provider would access to search for and obtain assignments based upon
specific end user requests for service. The use of an industry inventory
is represented below.

Scenarios for number pooling will therefore be classified as supporting
a *service provider inventory* of numbers or an *industry inventory* of
numbers, or a combination of both. The figure below represents a pooled
environment where assignments could be populated in service provider
inventories or service provider provisioning systems might interact
directly with the industry pool.

Numbers can be made available to a given service provider using either a
batch process or a real time/interactive process. A batch assignment is
associated with a specific request for resources based upon a service
provider forecast, and the allocation of those resources to a service
provider for subsequent assignment to subscribers. The real time process
implies the assignment of numbers based upon a specific subscriber need
and the immediate assignment of the resource to the subscriber.

The use of a service provider inventory could be associated with either
a batch or real time assignment mechanism. A number pooling scenario
which allocates numbers by 1000s blocks would support a batch process
through which the 1000s block is provided to the service provider's
inventory, from which future subscriber assignments can be made. Real
time assignments could also be made from the pool to a service
provider's inventory to satisfy the demand of a given subscriber, either
for an individual number or a block of numbers. Alternatively, a
scenario which does not include service provider inventories, but relies
on the use of an industry inventory, would only be associated with real
time assignments.

**5.0 GENERAL AREAS OF IMPACT**

Number pooling represents a major change in number assignment and
administration. Its impact, however, extends beyond these areas and
requires modifications to network infrastructure, changes in operations
support systems, and variations in call processing, including call
routing and rating.

5.1 ROUTING

Historical network routing mechanisms are based upon the understanding
that geographic numbers are assigned on a central office (NXX) basis and
associated with a specific switch, and the recognition that the network
address to which the call must be routed is embedded in the first six
digits (NPA-NXX) of the called number. The use of number pooling
eliminates this association of NXX to end office and demands an
alternative routing mechanism for call completion. Such a mechanism is
provided with the infrastructure associated with Location Routing Number
(LRN) Local Number Portability (LNP). Accordingly, and most importantly,
any implementation of pooling can only be supported if permanent LRN LNP
is available.[^2] The current implementation of this capability will
only support pooling within the rate center.

Similarly, non-call associated signaling messages associated with
database (e.g., LIDB or HLR) queries, or the processing of certain CLASS
services, are traditionally routed using six digit analysis of a
designated telephone number. Again, number pooling breaks the
association of NPA-NXX with the required destination and demands more
granular analysis and (global title) translations. The mechanisms
available with LRN LNP also provide this capability.

5.2 RATING

Today call rating is derived from the geographic information embedded in
the calling and called party numbers, specifically the first six digits
of those numbers (the NPA-NXX). The use of number pooling supports these
rating mechanisms assuming that the area of pooling \-- that is, the
area in which numbers are assigned and shared among different service
providers \-- is consistent with the established rate center boundaries,
and that the NPA-NXX(s) assigned to the pool uniquely identify the rate
center in which subscribers assigned numbers reside.[^3]

If an area of pooling is defined that extends beyond existing rate
center boundaries and numbers from a given NPA-NXX can be assigned over
multiple rate centers, an alternative to the current call rating
mechanisms would be required to accommodate changes to billing
structures. This mechanism, which is not now available, may associate
rating information with a given 10 digit number (i.e., the subscriber),
perhaps through the use of a separate, additional location parameter.
This location information may be provided in call detail records and
used in downstream rating processes.

5.3 THE REQUIRED INFRASTRUCTURE

The use of number pooling will require the development and deployment of
the necessary network infrastructure. Specific architectural issues
include whether the number administration database will be used simply
as a repository of number assignments or will function on an immediate
basis, allowing service providers to search for and reserve numbers as a
result of a specific customer request.

In addition, it appears that routing requirements demand close
coordination between the number assignment process and the Service
Management System (SMS) associated with LRN LNP. Accordingly, this may
require a link between the number administration database and the LNP
SMS. Upon the allocation of numbering resources within the number
administration database, or perhaps later when a specific subscriber
assignment is made, a record associating the assigned number with the
appropriate service provider, along with routing information necessary
to direct any calls dialed with that number to the designated central
office switch, would be transmitted to the LNP SMS. Information in the
LNP SMS would be downloaded to the network routing databases (SCPs) and
thereby made available for call processing.

Finally, it is recognized that the architecture associated with pooling
is directly related to the process flows which will be used in the
number assignment process. These process flows will be dependent on the
specific implementation of the number administration database and the
possible use of service provider inventories. Specific number pooling
architecture proposals and their associated number assignment process
flows are described in Section 7.0.

5.4 ADMINISTRATION

As is the case with all number administration processes, number pooling
will require the oversight of an administrator to establish the pool,
allocate the resources from the pool, monitor the utilization of the
pool, determine the rate of growth, determine its projected exhaust, and
plan for its relief in accordance with industry guidelines. It is
expected that a neutral third party will perform this function.
Administration of the resources will be subject to regulatory oversight.
A detailed description of number administration in a pooled environment
is given in Section 10.0.

5.5 ADMINISTRATIVE AND ASSIGNMENT GUIDELINES

Guidelines will be required to describe the specific methods and
procedures through which numbers will be assigned in a number pooling
environment. The manner in which numbers are allocated, reserved, aged,
or designated spare must be determined. Further, limitations on the
quantity of numbers that may be reserved at any one time by a given
service provider must be considered. Definitions and practices related
to number assignment in a pooled environment are provided in Section
8.0.

5.6 OPERATIONS SUPPORT SYSTEMS

Operations Support Systems (OSSs), especially those associated with
service provisioning, will be directly impacted by the implementation
and use of number pooling. Systems which provision new services for
customers are typically based upon the availability of numbering
resources within a central office code (block of 10,000 numbers) and
will have to be modified and, in some cases, possibly replaced to
accommodate number pooling. Other OSSs used for maintenance and repair
are similarly configured and may also require modification. It is
recognized that some of the necessary modifications may have been made
to accommodate LNP. The extent that additional changes may be needed to
support number pooling is described in Section 9.0. It is also
recognized that in some cases new system(s) may need to be developed and
deployed to accommodate number pooling.

5.7 CAPACITY

Number pooling will increase the quantity of numbers treated as ported
numbers. This increases the storage requirements for LNP databases and
billing systems, and increases SSP real-time processing and 10-digit
Global Title Translations (GTT). Additional details concerning SCP
capacity are provided in Section 7.2.4.3.

**6.0 PRINCIPLES, ASSUMPTIONS AND CONSTRAINTS**

The following principles, assumptions, and constraints form the
framework from which number pooling can be implemented in a fair and
equitable manner that does not disadvantage any LNP capable local
service provider from competing in the pooling area.

6.1 PRINCIPLES

Number pooling shall be implemented under the following principles. It
is recognized that considerations involving the recovery of costs
associated with the development and implementation of number pooling, as
well as the consideration of the initial and subsequent economic effects
on all impacted entities are very important. Any solution should not
preclude the development of appropriate cost recovery mechanisms.
However, such considerations are not included in these principles.

6.1.1 Number Pooling Availability Principle

Number pooling can only be implemented in locations where local number
portability has been implemented. Specifically, number pooling will only
be implemented where LRN LNP is available.

6.1.2 Reciprocity Principle

Carriers obtaining numbers from the pool shall be obligated to
contribute their eligible numbers to the pool.

The introduction of number pooling should not disadvantage any industry
segment to a degree greater than any other.

6.1.3 Participation Principle

Service providers offering local number portability in accordance with
the Telecommunications Act of 1996, and as ordered by FCC Report and
Order CC Docket No. 95-116, shall also participate in number pooling
where number pooling is implemented. Service providers offering local
number portability are also encouraged to participate in number pooling
development, deployment and associated administrative functions.

6.1.4 Non-participation Principle

Service providers should not be required to participate in number
pooling before they are required to offer local number portability.
Number pooling should not preclude such service providers from obtaining
non-pooled geographic numbering resources.

6.1.5 Equal Availability Principle

Numbering resources in the industry inventory pool shall be equally
available and allocated to service providers in a fair and
non-discriminatory manner.

6.1.6 Architectural Flexibility Principle

The architecture selected for the support of number pooling should allow
service providers reasonable flexibility in the manner in which they
interface with the systems supporting number pooling.

6.1.7 Customer Transparency Principle

The mechanism by which pooling is provided should be transparent to the
customer regardless of the number of times a customer changes service
providers.

6.1.8 Technical Equity Principle

The technical characteristics of existing interconnection arrangements
with non-participating networks should not be fundamentally changed as a
result of number pooling.

6.1.9 Network Reliability Principle

The pooling of numbers shall not degrade network reliability nor
negatively impact network performance.

6.1.10 LNP Impact Principle

The implementation of any number pooling mechanism or methodology will
not impact the functionality of, or schedule for, LNP as ordered by the
FCC. In particular, schedules for LNP implementation should not be
advanced in any way to support number pooling.

6.1.11 Uniform Interface Principle

The number pooling architecture selected shall support interoperability
such that service providers will interface with a number pool and obtain
numbers for their use uniformly nationwide.

6.2 ASSUMPTIONS AND CONSTRAINTS

1.  Number pooling will not be implemented until a neutral number
    pooling administrator is in place and able to perform the number
    administration function.

```{=html}
<!-- -->
```
1.  Number pooling will not be industry segment specific. Although there
    may be additional considerations unique to particular segments of
    the industry, number pooling must be available to all carriers.

```{=html}
<!-- -->
```
1.  Initially, each number pooling area will be constrained to within a
    rate center boundary. This does not presume that the use of number
    pooling will ultimately be limited to existing rate center
    boundaries.

```{=html}
<!-- -->
```
1.  The current wireline call rating paradigm, in which call rating for
    wireline carriers is based upon the rate centers associated with the
    calling and called party, will be maintained.

```{=html}
<!-- -->
```
1.  Implementation of number pooling will be subject to applicable
    local, state and federal regulatory requirements.

**7.0 FUNCTIONAL CONSIDERATIONS**

A number pooling environment must support several basic
functions/processes necessary for number assignment and administration.
These include the administration of the number pool, the interaction of
that pool with the LNP SMS, and, in general, accommodation of the "life
cycle" of the numbering resources, from the initial availability of
numbers within the pool, through their assignment, activation,
disconnection and return (snapback). Architectural considerations and
related process flows necessary for the support of these functions are
described for the two distinct forms of pooling -- block pooling and
individual telephone number pooling.

7.1 FUNCTIONS REQUIRED IN A NUMBER POOLING ENVIRONMENT

The functions of 1) industry inventory administration, 2) LNP
administration, 3) CO code administration, and 4) service provider
inventory administration are described in the following sections. These
descriptions and the associated process flows are functional and present
a basis for architectural considerations. However, within this Section,
no attempt is made to identify the specific system (e.g., database)
where these functions may reside.

7.1.1 Industry Inventory Administration

The industry inventory pool is the reservoir of numbers from which
service providers will be allocated numbers. This pool will be overseen
by an administrator whose responsibilities will include the
establishment of the pool and the ongoing assurance that number
allocation is made consistent with industry guidelines so that the
industry inventory pool contains sufficient resources to satisfy
industry needs.

7.1.2 LNP Administration

LNP, as previously stated, is a requirement for the implementation of
number pooling. Because the mechanisms associated with LNP will be used
to route pooled numbers, the LNP SMS must be directly involved in the
pooling process. The manner in which information is transmitted from the
industry inventory pool to the LNP SMS is a key item in the pooling
process and is discussed further in Section 7.2.4. The LNP SMS will be
overseen by the Number Portability Administration Center (NPAC) and its
Administrator.

7.1.3 CO Code Administration

CO code administration, in some form, will continue to be necessary with
number pooling. The CO code administrator, upon request of the pool
administrator, will make available additional CO codes for the pool. The
CO code administrator will also continue to be responsible for the
tracking of CO code usage, the forecast of CO code exhaust, and the
planning for NPA relief. Finally, there may be service providers who,
because of technical or other considerations (e.g., lack of LNP
capability, pooling may not be required in a specific area), will not
participate in pooling and will continue to be assigned full CO codes
for their numbering needs. These service providers will likely continue
to interface with the CO code administrator.

7.1.4 Service Provider Inventory Administration

A service provider may be required to maintain or have access to a
service provider inventory of numbers from which it will make
assignments to its subscribers as necessary.[^4] This service provider
inventory of numbers will be supplied from the industry inventory
consistent with the prescribed pooling arrangement and industry
assignment guidelines. Each service provider will be responsible for the
administration of its own inventory.

7.1.5 Additional Required Functional Capabilities

The infrastructure deployed to support pooling, regardless of whether
the implementation provides for block or line level pooling, must
accommodate the following needs:

> \- the ability to query the industry inventory pool to determine what
> resources are available for allocation
>
> \- the ability of the pool administrator to obtain information
> relevant to the utilization of the allocated resources in service
> provider inventories for auditing and/or reclamation purposes
>
> \- the availability within the industry inventory pool of information
> regarding all assignable resources as well as whether those resources
> have been allocated, and to whom
>
> \- the availability within service provider inventories of specific
> information regarding the status of individual telephone numbers
> (e.g., spare, working, reserved, intercepted, etc.)

7.2 Architecture and Process Flows - Block Pooling

The key parameters of block pooling are described. They include the
characteristics of the pool, the manner in which assignments are made
from the pool, the industry documentation required, the provision of
information to the NPAC/SMS, and the treatment of disconnected numbers.

7.2.1 Characteristics of the Industry Inventory Pool

Within a block pooling environment the industry inventory pool of
numbering resources will provide blocks of numbers (e.g., 1000s blocks)
for allocation to eligible service providers. The pool will provide
these numbering resources for use in a specific geographic area -- the
area of pooling -- initially to be associated with a rate center.
Accordingly, service providers which are allocated numbers from a given
industry inventory pool will assign those numbers to subscribers who
reside in or choose to obtain service in the area of pooling.[^5]

Blocks of numbers may be allocated to the industry inventory pool from
CO codes not assigned to any service provider. In addition, blocks of
numbers may be allocated to the pool from CO codes assigned to service
providers but in which there exist no subscribers within six months of
the assignment. It is also possible that blocks from CO codes assigned
to a given service provider which contain a minimal number of subscriber
assignments might also be placed in the industry inventory pool. These
"contaminated" blocks could be assigned to a service provider other than
the service provider assigned the CO code with calls to the existing
subscribers properly routed through use of the mechanisms of LRN LNP.
Specific guidelines (e.g., % fill) to determine the eligibility and the
exceptions of a given block for placement in the industry inventory pool
will have to be developed.

7.2.2 Assignments from the Industry Inventory Pool

A service provider will request an assignment from a given industry
inventory pool consistent with its needs for numbering resources in the
area of pooling and the industry assignment guidelines. These guidelines
will describe the parameters under which such a request can be made and
could include, for example, the percent utilization of the service
provider's current inventory of numbers, or the months remaining before
that inventory exhausts.

Assignments of blocks of numbers will likely be made using a procedure
through which a service provider will request the block assignment based
upon its forecasted need. Upon assignment, the block will be populated
in the service provider's inventory for assignment to individual
subscribers.

The pool administrator will make the block assignment based upon
certification by the service provider that its request is consistent
with the assignment guidelines. On an ongoing basis the pool
administrator will monitor the supply of numbering resources within the
pool to assure an adequate supply of numbers for the participants within
the pool. If that supply is not adequate, the pool administrator will
request from the CO code administrator that additional resources (i.e.,
a new CO code) be made available to the pool. The CO code Administrator
will supply a new CO code for use in the pool consistent with industry
administrative guidelines.

7.2.3 Industry Documentation

Currently, CO code assignments are documented in the Local Exchange
Routing Guide (LERG) where the information is available to the industry
for routing purposes.[^6] LERG assignment on a CO code basis will
continue to be necessary in a pooled environment. A LERG designated CO
code assignee will provide default routing if routing information is
unavailable or inaccessible from an LNP routing database.[^7]

The Pooling Administrator will select the LERG Assignee for newly
assigned CO Codes in accordance with the industry pooling administration
guidelines. The LERG Assignee should be a qualified code applicant
providing service in the rate center to which the NXX is assigned.

7.2.4 Provision of Information to the NPAC/SMS

The use of block level pooling raises the issue of the manner in which
information related to a block assignment will be provided to the
NPAC/SMS. As previously discussed, the provision of the assignment in
the NPAC/SMS is essential for accurate call routing. Two potential
methods have been identified for the transfer of this information. The
first method would, immediately upon the assignment, place all numbers
within the block into the NPAC/SMS thereby creating a record for each
line number to associate that number with an LRN. Alternatively,
information relative to each line number might be provided to the
NPAC/SMS only when a line number was assigned to a subscriber. The
former arrangement has been identified as "pre-porting"; the latter as
"port on demand". Not surprisingly, each method has characteristics that
might be viewed as either advantages or disadvantages. The
characteristics of the methods are described below.

7.2.4.1 Characteristics of Pre-Porting

The following is a list of characteristics associated with pre-porting:

a)  porting performed once upon block assignment (if service provider
    maintains only a single switch in the area of pooling);

b)  vacant treatment and billing/fraud obligation associated with block
    holder;

c)  no porting delay on assignment; numbers already ported into network;

d)  numbers within pooled blocks can be administered in the same manner
    as those within resident (DEFINE) NXXs;

e)  eliminates a concern for potential overload of NPAC transaction
    capacity; and

f)  requires larger LNP databases; potential capacity concerns.

7.2.4.2 Characteristics of Port on Demand

The following is a list of characteristics associated with port on
demand:

a)  uses smaller LNP database (only numbers assigned to subscribers are
    ported);

b)  vacant numbers are default routed to code holder, not the block
    holder;

c)  must use LNP porting process upon each subscriber assignment; adds
    potential complexity and delay;

d)  presents risk that numbers in block allocated to a given service
    provider could (inappropriately) be used by the code holder; and

e)  ambiguity of billing and fraud obligations (LIDB validation).

7.2.4.3 SCP Capacity Concerns

Arrangements have been proposed to minimize concerns associated with
database capacity (that is, the need to accommodate the added number of
records that would be stored in LNP SCPs as a result of number pooling).
These arrangements suggest that a range or block of numbers allocated to
a given service provider need not be represented in databases as
individual records, but could instead be identified as a single record.

Two specific proposals have been offered. The first would provide
separate tables for storing both individual (ported) numbers and
sequential ranges. The second proposal incorporates an algorithm change
which would be implemented as part of the query process to perform a
second search after the initial query associated with a single number
did not locate a specific record. Although it is generally agreed that
both arrangements have merit, it is also understood that because of
differences in provisioning requirements the two alternatives could not
co-exist in the same area.

The first proposal suggests that an LNP query would be routed through
two database tables: one in which a record represents a single ported
number, and one in which the record represents an entire range of
numbers. The first table is actually an exception table, containing only
those numbers that cannot be represented in a range. Such numbers would
include those ported for service provider portability purposes only
(i.e., not ported for pooling) or numbers that have been ported away
from the range holder. With this arrangement the query would first
initiate a search of the exception table -- the table that contains
records of individual number -- and, if the appropriate record was not
found, initiate a search of the range table. Implementation of this
arrangement would likely require modifications to the current NPAC
interface.

The second proposal suggests a change in the manner in which the range
is identified and submitted to the NPAC SMS. Specifically, the range
record would be encoded in an entry that maintains the format of a
single number record, but uses unique digits to identify the record as
representing a range of numbers. Importantly, it appears that this
method could only be used to accommodate the allocation of a 1000s
block. The associated query process would require an initial search of
the LNP database and, if a record for the individual telephone number
were not found, specific digit reformatting of the queried number would
also be required. This reformatting would place the number in the unique
format of the range record and a second search of the database would be
initiated. No change in the NPAC interface is required with this
arrangement.

7.2.4.4 Proposed Target Implementation

The INC recommends a target implementation no later than the first half
1999 for thousands block number pooling which does not require the
exclusive use of either pre-port or port-on-demand. Subject to further
industry analysis to determine technical feasibility, the INC recommends
an implementation procedure which would provide carriers the flexibility
to activate their allocated numbers (i.e., 1000s blocks) consistent with
their needs. Numbers could be activated (i.e., records placed in the
LNP/SMS) immediately upon allocation, only when assigned to subscribers,
or anytime in between.

The target implementation requires significant development effort, not
all of which has been completely identified. Further examination of this
proposal should be undertaken by the LNPA Working Group. The areas of
development identified to date are listed below.

1.  Modification to NPAC/SMS which permits activation of pooled number
    records in the SMS and associated downloads to LNP SCPs within a 15
    minute interval; and development of a pooled number indicator.

2.  Modifications to Service Provider OSSs which permits the mechanized
    provisioning and TN administration for 1000s blocks

3.  Modifications to Service Provider Switches and Switch Administration
    to permit the automation of the translations activities required for
    vacant number treatment of pooled numbers

4.  SMSs, SCPs, NPAC and associated interfaces require modification to
    permit the representation of a range of numbers in the SMS and SCPs,
    rather that the exclusive use of individual records, i.e., Efficient
    Data Representation.

The timeframe for the development associated with these capabilities is
presently unknown, but the capabilities are required no later than 2Q99
to meet CMRS needs.

If the NANC endorses this INC recommendation, the NANC should
immediately direct the LNPA Working Group to undertake a detailed
analysis of the specific requirements to support the target
implementation.

Prior to the availability of all the capabilities to support the target
implementation, number pooling might be implemented in specific areas
with some, but not all of the above features.

The timeframes depicted below are based on the October 1997 vendor
responses to the Illinois Commerce Commission analysis regarding number
pooling in the 847 NPA. The analysis assumed pre-port, 1000 block
pooling with snapback to the block holder. These timeframes are based on
limited vendor input and should only be considered as preliminary
estimates which are subject to change.

Based on current understanding, early implementation of number pooling
would be constrained as follows:

Implementation prior to mid 1998

1\. Service Providers activate "as needed" (see definition below)
pursuant to industry

guidelines.

2\. Manual processes needed by some service providers

3\. Service Provider concerns due to potential 3 day interval (delay)
for activation

(porting)

4\. Service Provider/Vendor SCP capacity limitations

Implementation mid 1998 - end 1998

1\. Service Providers activate "as needed" pursuant to industry
guidelines

2\. Potential mechanized capabilities used for provisioning, TN
administration

3\. NPAC/SMS development permits 15 minute activation

4\. SCP capacity limitations continue

Implementation no later than first half 1999 (target implementation)

1\. Efficient data representation developed; SCP capacity limitations
are

potentially resolved

2\. Service Providers activate at their discretion

7.2.4.5 Definition of Activation "As Needed"

Activation "as needed" is a number administration process which would
permit a service provider to immediately activate a portion of the
numbers within its allocated thousands blocks subject to limitations
defined in yet to be developed industry guidelines. That is, a carrier
might be constrained to activate, for example, only the amount of
numbers within its allocated thousands blocks that a service provider
requires to satisfy its forecasted needs for the near term, e.g., one
month. This process could mitigate some SCP capacity concerns while
still providing carriers with an inventory of numbers from which
subscribers could be assigned numbers without a three day delay. Until
efficient data representation is available, it should be recognized that
control mechanisms should be implemented by service providers to monitor
their own SCP capacity utilization to ensure adequate capacity for both
number portability and number pooling.

7.2.5 Treatment Upon Disconnect

Within a block pooling environment, careful attention must be given to
the manner in which numbers are administered upon disconnect. Of
particular concern is whether a number, when disconnected, should be
returned (or snapped back) to the block holder, the code holder (i.e.,
the LERG assignee), the industry inventory pool, or remain with the
disconnecting service provider.

The INC recommends that within a thousands block pooling environment,
snapback to the block holder is the preferred scenario, but recognizes
that early deployment of number pooling will generate situations where
snapback to the code holder may occur.

7.2.6 Schematic Representation of Process Flows for Block Pooling

**BLOCK POOLING - OVERVIEW**

The following figure depicts the process flows associated with number
assignment in a general block pooling environment.

![](media/image3.emf){width="6.072916666666667in" height="3.46875in"}

1\. Industry Inventory Pool Administrator creates and maintains
inventory of NXX-X TN blocks from growth (and embedded) NXXs necessary
to satisfy forecasted demand. LERG assignees need to be identified for
new NXXs. (Under existing procedures this is a 66 day process).

2\. If necessary, LERG Assignee restricts TN block from
selection/assignment in their Service Provider Inventory System(s).
(Note: LERG Assignee is still required to perform vacant number
treatment for unallocated numbers.).

3\. Service Provider requests a TN(s) block from the Industry Inventory
Pool Administrator.

4\. Industry Inventory Pool Administrator forwards TN(s) block to
Service Provider. (Assumption: An agreed upon date is set as to when
Service Provider controls TNs). Industry Inventory Pool Administrator
notifies NPAC and all carriers of pending TN assignments.

5\. Service Provider loads TN(s) block into their Service Provider
Inventory System(s) and restricts selection/assignment until Service
Provider specified agreed until it is activated in the network.

6\. The Service Provider, after receipt of the allocation, forwards an
LNP Local Service Request (LSR)[^8] to the NPAC to begin the actual
activation process. Existing confirmation and activation message flows
will prevail.

7\. Service Provider removes date restrictions from their Service
Provider Inventory System(s) and allows selection/assignment on TN(s).

**Additional Assumptions:**

1.  NPAC must keep track of owner of TN block.

**BLOCK POOLING - PRE-PORTING FLOW**

The following figure depicts the process flows associated with number
assignment in a block pooling, pre-porting environment.

![](media/image4.emf){width="5.916666666666667in"
height="3.421527777777778in"}

1\. Industry Inventory Pool Administrator creates and maintain inventory
of NXX-X TN blocks from growth (and embedded) NXXs necessary to satisfy
forecasted demand. LERG assignees need to be identified for new NXXs.
(Under existing procedures this is a 66 day process).

2\. If necessary, LERG Assignee restricts TN block from
selection/assignment in their Service Provider Inventory System(s).
(Note: LERG Assignee is still required to perform vacant number
treatment for each unallocated NXX.).

3\. Service Provider requests a TN block from the Industry Inventory
Pool Administrator.

4\. Industry Inventory Pool Administrator forwards TN block to Service
Provider (now referred to as the Block Holder). (Assumption: An agreed
upon date is set as to when Block Holder controls TNs). Industry
Inventory Pool Administrator notifies NPAC and all carriers of pending
TN block assignment to Block Holder. (This assumes the existing LERG
assignment processes whereby all carriers are notified when an NXX is
assigned).

5\. Block Holder loads TN block into their Service Provider Inventory
System(s)

and restricts selection/assignment until Service Provider specified
date.

6\. Block Holder loads default routing data:

a)  loads TN block into SSP and creates group record in LIDB and
    LIDB/AS,

b)  loads default routing data in both STPs and SSPs and

c)  establishes vacant code announcements, etc. in the SSP.

7\. Block Holder provides LSR with Global Title Translations (GTT) and
LRN(s) to NPAC, who verifies block ownership and processes order.

8\. Upon the Service Provider specified date, NPAC activates TN block by
sending an LSR to the NPAC. (Currently this process requires 3 days.)

9\. NPAC downloads TN block into SCPs via LSMSs.

10\. Block Holder removes date restrictions from their Service Provider
Inventory System(s) and allows selection/assignment from TN block.
Numbers can be activated as quickly as the OSSs can accommodate new
subscribers .

11\. If necessary, LERG Assignee removes TN block from their Service
Provider Inventory System(s) and TN block from their SSP. LERG Assignee
removes group record from LIDB and LIDB/AS.

**Additional Assumptions:**

1.  NPAC must keep track of owner of TN block.

```{=html}
<!-- -->
```
1.  Block Holder is responsible for vacant code treatment on non-working
    numbers.

```{=html}
<!-- -->
```
1.  LERG Assignee is still required to perform vacant number treatment
    for each unallocated NXX block.

**BLOCK POOLING - PORT ON DEMAND FLOW**

The following figure depicts the process flows associated with number
assignment in a block pooling, porting on demand environment.

![](media/image5.emf){width="5.909027777777778in"
height="3.3826388888888888in"}

1\. Industry Inventory Pool Administrator creates and maintain inventory
of NXX-X TN blocks from growth (and embedded) NXXs necessary to satisfy
forecasted demand. LERG assignees need to be identified for new NXXs.
(Under existing procedures this is a 66 day process)

2\. If necessary, LERG Assignee restricts TN block from
selection/assignment in their Service Provider Inventory System(s).
(Note: LERG Assignee is still required to perform vacant number
treatment for each unallocated NXX.).

3\. Service Provider requests a TN block from the Industry Inventory
Pool Administrator.

4\. Industry Inventory Pool Administrator forwards TN block to Service
Provider (now referred to as the Block Holder). Industry Inventory Pool
Administrator notifies NPAC and all carriers of TN block assignment to
Block Holder. (This assumes the existing processes whereby all carriers
are notified when an NXX is assigned).

5\. Block Holder loads TN block into their Service Provider Inventory
system.

6\. Block Holder creates group record in LIDB and LIDB/AS:

a)  creates TN block into record in LIDB and LIDB/AS,

b)  opens allocated TN blocks in SSPs and

c)  assures that all unallocated numbers are given unallocated
    treatment.

7\. As Customers in TN block request service, service provider must have
a means of identifying that these numbers require LNP treatment . LNP
flow for service activation starts by sending an LSR to the NPAC. (3 day
process based on existing procedures):[^9]

a)  Block Holder provides Global Title Translations (GTT) and LRN(s) to
    NPAC and

b)  NPAC downloads TN into SCPs via LSMSs using standard LNP flows.

**Additional Assumptions:**

1.  NPAC must keep track of owner of TN block.

```{=html}
<!-- -->
```
1.  LERG Assignee is responsible for vacant number treatment.

7.3 Architecture and Process Flows - Individual Telephone Number Pooling

7.3.1 Characteristics of the Industry Inventory Pool

Individual telephone number pooling places telephone numbers in an
industry inventory pool and provides service providers participating in
the pool the capability to request variable quantities of numbers
consistent with industry assignment guidelines. The numbers within a
given pool will be designated for allocation to service providers who
choose to provide service to their subscribers from the rate center
covered by the pool.

The source for telephone numbers placed in the industry inventory pool
could be from unassigned CO codes. In addition, spare TNs from existing,
assigned CO codes could also be designated for placement in the pool.
Specific guidelines for selection of TNs from assigned CO codes for use
in the pool will have to be determined.

7.3.2 Assignments from the Industry Inventory Pool

As with block pooling, requests by a service provider for assignments
from an industry inventory pool will be made consistent with that
service provider's needs and industry assignment guidelines.

Numbers might be obtained by the service provider using a process in
which assignments are requested based upon a general forecasted need,
and numbers allocated to the service provider's inventory for subsequent
assignment to subscribers.

A service provider may also choose to interact with the industry
inventory pool to obtain numbers specifically to meet the demands of
given subscribers and to accommodate the need for the immediate or near
term assignment of numbers to those subscribers. With this type
interaction with the industry inventory a service provider might employ
its own number inventory from which it makes its assignments to
subscribers, or possibly use only the industry inventory (pool) with
which it would establish an interface with its Operations Support
Systems (OSSs) for service provisioning.

The use of individual telephone number pooling with direct interaction
to an industry inventory pool would require specific assignment
guidelines. This would discourage the misuse of the assignment process
and minimize the possibility of number hoarding.

Finally, as with block pooling, the pool administrator will be
responsible for tracking the supply of numbers in the pool, and assuring
the supply of numbers is adequate for the participant's needs.

7.3.3 Industry Documentation

Designation of a service provider as the LERG assignee of a given CO
code is again required. As with block pooling, such an assignment
provides a destination for default routing, should routing information
be unavailable from the LNP routing database. The method with which
selection of the LERG assignee is made in an individual telephone number
pooled environment must be determined.

7.3.4 Provision of Information to the NPAC/SMS

In theory, individual telephone number pooling presents the same choices
for interaction from the industry inventory pool to the NPAC/SMS as
those identified for block pooling. That is, numbers can be identified
in the NPAC/SMS as ported immediately upon their assignment from the
pool or only after they are activated (i.e., assigned by the service
provider to a subscriber).

7.3.5 Treatment Upon Disconnect

Upon disconnect of a telephone number, the disconnecting service
provider will age that number according to industry guidelines.
Depending upon the pooling alternative that is chosen by the industry,
the disconnected telephone number may be made available for reassignment
via snapback to the industry inventory pool or by remaining with the
disconnecting service provider.

7.3.6 Schematic Representation of Process Flows for Individual Telephone
Number Pooling

**INDIVIDUAL TN POOLING**

The following figure depicts the process flows associated with number
assignment in a Individual Telephone Number pooled environment.

![](media/image6.emf){width="5.986805555555556in"
height="3.5965277777777778in"}

1\. Industry Inventory Pool Administrator creates and maintains
inventory of TNs from growth (and embedded) NXXs necessary to satisfy
forecasted demand. LERG assignees need to be identified for new NXXs.
(Under existing procedures this is a 66 day process)

2\. LERG Assignee(s) restricts all poolable TNs from assignment in their
Service Provider Inventory System.

3\. Service Provider requests a TN(s) for inventory replenishment or
customer orders from the Industry Inventory Pool Administrator.

4\. Service Provider receives a TN(s) from the Industry Inventory Pool
Administrator .

5\. Service Provider creates record in LIDB and LIDB/AS for TN.

6\. LNP flow for service activation starts by sending an LSR to the NPAC
based on standard LNP procedures. Current intervals for porting numbers
is 3 days.

7\. If necessary, LERG Assignee removes TN(s) from their Service
Provider Inventory System(s) and TN(s) from their SSP. LERG Assignee
removes group record from LIDB and LIDB/AS.

**Additional Assumptions:**

1.  Flow supports both single number and inventory TN replenishment.

```{=html}
<!-- -->
```
1.  LERG Assignee responsible for vacant number treatment.

```{=html}
<!-- -->
```
1.  Service Provider (ported TN) is responsible for aging treatment.

```{=html}
<!-- -->
```
1.  Industry Inventory Pool Administrator identifies the TNs assigned to
    each service provider.

```{=html}
<!-- -->
```
1.  Synchronization is required between Industry Inventory Pool
    Administrator and the Regional NPAC.

The Industry Inventory Pool Administrator will have the ability to
provide TNs to service providers in real time and non-real time; single
and batch. Line level pooling may cause group records to be eliminated
from LIDB and LIDB/AS. If so, all information will be done at the line
level.

**8.0 NUMBER ASSIGNMENT**

Number assignment refers to the process through which numbering
resources are allocated to eligible service providers. Some aspects of
the assignment/allocation process in a pooled environment will remain
consistent with the guidelines currently in place for central office
code assignment. For example, the criteria for assignment/allocation of
resources will continue to be dependent upon a service provider's
certification that:

1.  it is authorized to provide service in a given area,

```{=html}
<!-- -->
```
1.  it will use the resources for assignment to its subscribers to
    terminate PSTN traffic at a switch or point of interconnection under
    its control, and

```{=html}
<!-- -->
```
1.  it has a need (i.e., a forecast or specific customer request) for
    the resources.

Additionally, the assignment process in a pooled environment will
include significant changes relative to the current procedures:

1.  First, the CO Code Assignment Guidelines must be modified to enable
    the pool administrator to obtain CO/NXX Codes for the Industry
    Inventory Pool

```{=html}
<!-- -->
```
1.  Second, the increment of assignable resources will change from an
    NXX code (10,000 TNs) to the designated block or range of TNs.

```{=html}
<!-- -->
```
1.  Third, total resources assignable at any one time will have to be
    prescribed; that is, whether there will be limits on the number of
    blocks, or the number of TNs that can be allocated at any one time.

```{=html}
<!-- -->
```
1.  Fourth, the request process will need to be reviewed. It must be
    determined if the use of request forms, similar to those used today,
    will continue OR if having an industry inventory pool requires an
    electronic process to supplement or replace existing forms. It may
    also be necessary to review the time frames associated with
    assignment and determine if number pooling allows or requires those
    intervals to be modified.

Finally, the use of pooling demands that additional items be considered
and included in assignment guidelines. These include criteria:

a)  to keep the service provider inventory sufficiently maintained;

b)  for assignment to customers needing a large block of consecutive TNs
    that are not currently in the service provider inventory;

c)  for assignment for customers wanting TNs that are not in the service
    provider inventory;

d)  for the assignment of vanity numbers;

e)  for blocks of numbers that span across thousands blocks; and

f)  to assist large end users that have difficulty using numbers within
    certain blocks, e.g., 0000 and 9000.

**9.0 OPERATIONS/PROVISIONING**

The implementation of number pooling will have significant impact on
operations support systems of some service providers, particularly those
OSSs which are used in the provisioning process. Typically, existing
systems are based upon the availability of a full central office code
(i.e., NPA-NXX) and will therefore require modification. In some cases,
additional functionality is required. In other cases pooling causes an
increase in the volume of system processing. The impact on OSSs varies
depending on the pooling alternative recommended in this report and the
service provider's systems.

9.1 The Industry Inventory Pool

Number pooling will require the establishment of an industry inventory
of numbering resources (i.e., the pool) and associated systems which
will support the administrative functions of, for example, inquiry,
number reservation, and assignment. This system or systems will need to
support the combined volume of transactions forecast for all the service
providers who interface with the industry inventory pool.

9.2 Industry Inventory Pool Interface

Standard interfaces between the industry inventory pool and service
provider inventories will be required. These interfaces will support the
transactions and the transfer of information associated with the request
and assignment of resources or information requests from the industry
inventory to the service provider inventory pool.

9.3 Service Order Support

For some service providers considerable interaction is required among
the multiple OSSs which are involved with the provision of customer
service. Such OSSs assign a specific telephone numbers to subscribers,
and identify the services to be provided to customers, including the
local calling area. To the extent that these OSSs must now interface
with a new inventory of numbering resources, modifications may be
necessary.

9.4 Service Order Mechanization

The generation of service orders, necessary for the provision of
service, is a mechanized process which is currently based on the
traditional association of a full central office code (NPA-NXX) to a
given switch. Modifications are necessary to accommodate the allocation
of less than full CO codes to service providers, the association of
those numbers or blocks of numbers to a given rate center, and the
possibility that those numbers will serve customers in multiple switches
in that rate center.

9.5 Telephone Number Selection - Customer Location Identification

TN selection is typically based upon customer location and the
association of an NPA-NXX with a switch that serves that location.
Number pooling will no longer support the association of a full NPA-NXX
with a given location (switch) and will therefore require the
modification of systems that perform TN selection.

9.6 Telephone Administration/Assignment

Systems which inventory working and spare office equipment and perform
associated functions of load balancing are again based upon the
assignment of a full CO code (NPA-NXX) to a given switch. Modifications
to these systems will be required to reflect the assignment practices
associated with a number pooling environment.

9.7 Emergency Administration - Selective Routing

Routing and customer location information associated with emergency
services (i.e., E911) is presently based upon NPA-NXX. It appears that
additional modifications to E911 will not be required for pooling beyond
what is needed for LNP. However, E911 configurations in a specific
pooling area should be reviewed prior to pooling implementation to
ensure that no E911 changes are necessary.

9.8 End User Billing - Billing Cycles

The "balancing" of end user billing cycles as well as the utilization of
bill inserts associated with specific geographic areas (e.g., wire
centers) are currently supported through the traditional association of
NPA-NXX with a given switch. Number pooling requires modification to the
OSSs which support these functions to accommodate the use of number
pooling and the loss of the ability to associate NPA-NXX with a given
switch.

9.9 Service Provider Identification

There are different OSSs that have used the NPA/NXX as a means to
identify the associated service provider. This is particularly true for
billing and collections, and impacts systems such as CMDS and LIDB. LNP
breaks the tie that permitted identification of the entity providing the
service by an examination of the associated NPA/NXX. Depending on the
method selected pooling may exacerbate this problem. To resolve this
other means will have to be found to perform identification of the
service provider. This may advance the need for investment required to
support changes to OSSs over and above those required to support LNP.

9.10 Translations Support

With the introduction of number pooling, switch translations required
for call routing and associated with class of service, specialized
routes, calls to presubscribed carriers (both interLATA and intraLATA
toll) will no longer be established based upon NPA-NXX, but will instead
be provisioned on a per line basis. The added complexity required by
pooling may require modifications to the translations process and the
OSSs which are used for this function.

9.11 Pool Administration

Currently service provider numbering resources are typically augmented
with full CO codes. Because number resources will be allocated in
smaller quantities, pooling is likely to require increased activity
(i.e., additional transactions) to maintain their numbering resources
and will therefore add some administrative burden to this process

9.12 Generic Service Provider System Impacts

Some service providers, especially CMRS, have combined billing,
provisioning and inventory systems. If a service provider with combined
systems elects to obtain numbers only from the industry inventory pool
or needs numbers to immediately satisfy a specific customer request, new
interfaces and potentially new hardware would be needed to permit these
systems to interface with external systems or to function individually.

**10.0 NUMBER ADMINISTRATION**

Number administration in a pooled environment is primarily concerned
with the management of the number pool and the need to assure that
resources are readily available, consistent with industry guidelines.
The administrator must monitor the supply of numbers in the industry
inventory pool, track the demand for numbers, and grow the pool as
necessary. Administrative responsibilities extend beyond those of the
industry inventory pool administrator and include those associated with
the service provider, the NPAC, and the CO code administrator. Specific
responsibilities of the pool administrator, along with other involved
entities, are described in Sections 10.2 - 10.6.

10.1 Basic Assumptions

The administrative responsibilities and activities in a number pooling
environment identified in this Section are based upon the following
assumptions.

a)  Multiple service providers may offer service in any given rate
    center.

b)  Any switch based service provider operating within the specified
    geographic area is allowed to be involved in the pooling transition
    planning meetings.

c)  A single administrator will oversee all the (rate center) pools
    within a given NPA. A pool administrator may oversee industry
    inventory pools for more than one NPA.

d)  The CO Code Administrator will continue to perform CO Code
    administration functions.

e)  The existing CO Code Guidelines will be used as a baseline for
    Pooling Administration Guidelines.

f)  Within a given area of pooling, number pooling will be implemented
    per industry guidelines.

g)  Growth (i.e., unassigned) codes will be assigned to the pool.

h)  Embedded (i.e., assigned) codes may be used to populate the industry
    inventory pool subject to industry guidelines.

i)  Growth CO Codes placed in the industry inventory pool will require
    the selection of a LERG assignee (selection method to be
    determined).

j)  Service providers will obtain numbering resources from the industry
    inventory pool consistent with industry guidelines.

k)  The industry inventory pool will be administered in such a way that
    it always contains numbering resources adequate to satisfy demand.

l)  Pooling will be implemented in such a manner to permit timely
    activation of TNs to meet customer and service provider
    requirements.

m)  Pooling will be implemented in a manner that will minimize the
    impact to existing internal service order processes currently used
    by service providers.

n)  New service providers wishing to participate in an industry
    inventory pool after pooling is in operation will be provided an
    initial quantity of TNs to populate their inventory in accordance
    with industry guidelines.

o)  The CO code activation process used to activate new CO codes in a
    pooling environment will be the same for all pooling alternatives.

10.2 The Pool Administrator

It is assumed that the administrator of the industry inventory pool will
be a neutral third party.

10.3 General Responsibilities of the Pool Administrator

The pool administrator will:

a)  maintain an internal secured database that will include all pooled
    number resources, the status of the resource (i.e., assigned,
    non-assigned), and if assigned, the identity of the service provider
    to which the resource is allocated;

b)  maintain an industry database accessible by all service providers
    that will include all pooled number resources and the status of the
    resource (i.e., assigned, non-assigned);

c)  process applications from service providers for numbering resources
    consistent with industry guidelines;

d)  manage a reservation process for numbering resources in the industry
    inventory in accordance with industry guidelines;

e)  receive and compile forecasts of demand from service providers for
    numbering resources within given rate centers;

f)  analyze service provider forecasts to determine the numbering
    resources required to maintain the industry inventory pool;

g)  assure the availability, based upon industry established criteria,
    of numbering resources within the industry inventory for a given
    rate center;

h)  add to the resources in the industry inventory pool when necessary,
    by requesting additional CO codes from the CO code administrator,
    consistent with yet to be established process;

i)  coordinate the transfer of information to the NPAC as necessary;

j)  arrange for and/or perform audits of service provider utilization of
    assigned resources, as required; and

k)  assume responsibility for the creation and distribution for any
    reports the industry deems needed or desirable.

10.4 General Responsibilities of the Service Provider

The service provider will:

a)  determine and request resources for a given rate center, consistent
    with industry guidelines;

b)  provide to the pool administrator a forecast of its number resource
    requirements for a given rate center ;

c)  maintain, at a minimum, a record of specific information regarding
    the status of individual telephone numbers (e.g. working, reserved,
    aging, etc.) within their inventory;

d)  be capable, at a minimum, of supporting the following number
    administration functions: TN assignment , maintenance of the
    integrity of blocks of TNs, maintain all TN status', e.g., spare,
    working, aging, and reserved status, etc., of all TNs allocated to
    that service provider; and

e)  provide snapback notification to the pooling administrator (if
    necessary) for non-ported disconnected telephone numbers.

10.5 General Responsibilities of the NANPA/CO Code Administrator

The NANPA/CO Code Administrator will:

a)  perform those functions currently specified in industry guidelines
    (e.g., CO Code (NXX) Assignment Guidelines, NPA Relief Planning
    Guidelines, etc.) or as modified to accommodate number pooling.

10.6 General Responsibilities of the NPAC

The NPAC will:

a)  provide the pool administrator with any necessary information (e.g.,
    SPI, LRN, Effective Date) of pooled numbering resources that are
    ported;

b)  coordinate service provider requests and execute the pool
    administrator's authorizations to change the porting status of
    pooled resources;

c)  interact with the pool administrator, as identified in industry
    guidelines; and

d)  provide the notification of snapback for only ported disconnected
    telephone numbers.

**11.0 ALTERNATIVE ARRANGEMENTS FOR NUMBER POOLING**

The following sections describe four alternatives which might be used to
provide number pooling. The alternatives involve different levels of
pooling and assume different types of number inventories with the
allocation of numbering resources based upon a either a forecast of the
exhaust of a service provider's inventory or that service provider's
need to immediately satisfy a specific customer's needs. Two levels of
pooling are described -- block pooling and line level pooling. Although
a single level of block pooling is identified -- 1000s blocks -- the
architecture, process flows, and associated impacts should be the same
for all practical levels of block pooling (e.g., 100s blocks) should
they be considered. Specifically, the alternatives include one scenario
which supports block pooling (Alternative 2) and three alternatives
which consider line level or telephone number (TN) pooling.
(Alternatives 1, 3 and 4)

11.1 Alternative 1

1.  Level - Individual Telephone Number (TN) with the capability to
    request variable quantities of numbers

```{=html}
<!-- -->
```
1.  Inventory - Service Provider Inventory Optional (supports use of a
    service provider inventory, industry inventory pool, or both, at
    discretion of service provider) Allocation Mechanism - Supports
    assignment based upon a forecast of exhaust of resources within a
    SP's inventory or the capability to immediately satisfy a specific
    customer request.

This alternative would provide a service provider the flexibility to
request telephone numbers on an individual basis or in multiple
quantities. Assignable numbers would be resident in an industry
inventory and would typically be obtained by a service provider upon
request based upon forecasted demand or on an immediate basis to satisfy
a specific customer request.

11.2 Alternative 2

1.  Level -- 1000s block assignment only

```{=html}
<!-- -->
```
1.  Inventory - Service provider inventory required

```{=html}
<!-- -->
```
1.  Allocation Mechanism -- Supports assignment based upon a forecast of
    exhaust of resources within a SP's inventory.

This alternative allocates numbering resources to service providers in
blocks of 1000 sequential numbers, specifically in 1000s blocks defined
by the range of line numbers from "X000" to "X999". Number allocation is
based upon a forecast consistent with industry guidelines.

11.3 Alternative 3

1.  Level - Individual telephone number (TN) (with the capability to
    request variable quantities of numbers)

```{=html}
<!-- -->
```
1.  Inventory - Service provider inventory required

```{=html}
<!-- -->
```
1.  Allocation Mechanism - Supports assignment based upon a forecast of
    exhaust of resources within a SP's inventory

This alternative (as with Alternative 1) allows a service provider to
request numbering resources either as a single number or in variable
quantities. However, this arrangement would only support allocation
based upon a service provider's forecast, and does not allow for the
immediate allocation of numbers based upon a specific subscriber need.
Assignment of numbers to subscribers would only be made by a service
provider using numbers available in its own inventory.

11.4 Alternative 4

1.  Level - Individual telephone number (TN) with the capability to
    request variable quantities of numbers

```{=html}
<!-- -->
```
1.  Inventory - Demands the use of an industry inventory only; does not
    allow for the use of a service provider inventory

```{=html}
<!-- -->
```
1.  Allocation Mechanism - Supports immediate assignment based upon
    specific customer needs

This alternative also permits the allocation of resources as individual
numbers or variable quantities of numbers. This arrangement, however,
allows for an industry inventory only and the associated process of
immediate assignment based upon specific customer need. Accordingly,
with this arrangement, service providers will search for and obtain
numbers through direct interaction with the industry inventory of
numbering resources.

11.4.1 On The Viability of Alternative 4

Current number provisioning systems and service order processes rely on
the interaction of a multitude of OSSs with a locally administered
(service provider) inventory of numbers. Alternative 4 precludes the use
of such an inventory and demands the sole availability of an industry
inventory which would be directly involved in all number search and
assignment activities associated with provisioning of subscriber
services. The continued use of a service provider inventory affords a
natural evolution from the existing environment and avoids the
significant changes and potential burdens that would accompany its
elimination.

The INC therefore concludes that service provider inventories must be
available -- at least as an option \-- as a characteristic of all viable
alternatives for number pooling. Alternative 4, which precludes the use
of a service provider inventory, is therefore eliminated and will not be
considered for further evaluation.

**12.0 CRITERIA FOR ASSESSMENT OF ALTERNATIVES**

The following criteria/characteristics are key to the study of the
alternatives identified in Section 11.0. They are explained here and
used in Section 13.0 to assess the alternatives.

12.1 Improvement in number utilization

The primary potential benefit of number pooling is an increase in the
utilization of numbering resources and the associated delay in the
possible need for NPA relief. Accordingly, each alternative should be
evaluated based upon its ability to promote efficient use of numbers.

12.2 Impact on Infrastructure

As described in Sections 5 and 7, the deployment of number pooling
demands changes within the infrastructure. The use of number
administration databases, the need for service provider maintained
number inventories, and the linkage to the LNP LSMS are examples of
network additions/modifications that may be required. The extent of the
effort associated with each alternative must therefore be considered.

12.3 Impact on Operations

The impact of number pooling on operations, especially service
provisioning, could be significant. Changes to OSSs associated with
provisioning, as well as downstream processes such as
billing/settlements, must be understood and included as part of any
assessment of a given alternative.

12.4 Impact on End Users

End user concerns and needs must be considered with any implementation
of number pooling. Specifically, the degree to which any number pooling
scenario might contribute to customer confusion should be determined.
Moreover, the ability to meet customer needs and specific requests for
telephone number assignments such as the request of a business customer
for a large, sequential block of numbers must be addressed and
understood.

12.5 Impact on Number Assignment

The number assignment process associated with each alternative described
for number pooling must be described and understood. The process should
be consistent with the Equal Availability Principle and, to the extent
possible, be easy to implement and without undue complexity.

12.6 Impact on Administration

The pool of numbers available for assignment within a given geographic
area will be overseen by an administrator. The responsibilities of the
pool administrator, which might include monitoring the utilization of
the Industry Inventory Pool and planning for its growth, should be
easily performed, thereby assuring the continued availability of
numbers. Any distinction among the alternatives relative to the ease of
administration should be identified and used as a criterion for
assessment.

The following is a list of suggested criteria to be used in evaluating
the impact on the administration of the pooling alternatives:

[1. Complexity of Administration Process]{.underline}

This criterion measures the overall complexity of the administrative
functions and processes that make up the pooling option. These include:

1.  Forecast/Demand

```{=html}
<!-- -->
```
1.  Application/Response

```{=html}
<!-- -->
```
1.  Approval/Notification

```{=html}
<!-- -->
```
1.  Jeopardy

```{=html}
<!-- -->
```
1.  Transition to Pooling

```{=html}
<!-- -->
```
1.  Audit Procedures

```{=html}
<!-- -->
```
1.  Interdependencies

[2. Record Keeping]{.underline}

Record keeping refers to the amount of information for each record and
the quantity of records required to implement a given pooling
arrangement. It may also address the quantity of code requests,
necessary documentation, retention period, etc.

[3. Size Of Industry Inventory Database]{.underline}

This criterion is a measure of the size of the required database
necessary for a given pooling option. The size (e.g., quantity of
entries in the database) reflects the necessary memory and hardware
requirements that a given pooling option would require.

[4. Security Considerations]{.underline}

This criterion measures the complexity of the security requirements for
administration of the industry inventory database.

[5. Impact On Industry Pooling Administration System Infrastructure /
Architecture]{.underline}

This criterion measures the complexity of the pooling administration
system infrastructure / architecture, (e.g., quantity of data links,
number of interfaces, system performance measurement, etc.).

[6. Impact on Service Provider Administration]{.underline}

This criterion measures the impact of the pooling alternatives on
service providers' administrative requirements.

[7. Ease of Implementation]{.underline}

This criterion evaluates the length of time and complexity involved with
implementation of each pooling alternative.

[8. Service Provider Impacts]{.underline}

This criterion evaluates the ease with which a service provider obtains
the numbering resources required.

12.7 Relative Cost

The relative cost to develop and deploy any form of number pooling is a
key factor in the assessment of any pooling alternative. The costs of
interest are the differences that can be identified that might make the
cost of one alternative more or less expensive than another. The
relative costs will be those associated with estimated industry costs,
as it is not expected that any individual service provider's cost be
documented. It is recognized that cost associated with any alternative
for pooling, in and of itself, may not be the overriding factor, but
rather that cost must be considered in the ultimate assessment of
choices for implementation.

12.8 Time for Availability

The timeframe for implementation for any alternative should be
determined, with merit associated with those alternatives that can be
deployed sooner rather than later.

**13.0 EVALUATION OF ALTERNATIVES**

Due to time constraints, the INC was unable to review Section 13. The
text of this section can be found in Appendix A.

**14.0 CONSIDERATIONS RELATED TO THE IMPLEMENTATION OF POOLING**

As described in Section 3.4, the primary benefit provided by pooling is
derived from the increased utilization of numbering resources that
pooling can potentially provide. This benefit must be weighed against
the effort and costs associated with the implementation of pooling,
which involve deployment of the necessary modifications to network
architecture, the changes mandated in administration and assignment
processes, and the modifications required in operations support systems.

It is therefore necessary to assess the potential benefit of pooling
specific to any jurisdiction in which it is being considered. Such an
assessment should address the following questions:

1.  How long will pooling extend the life of the NPA?

```{=html}
<!-- -->
```
1.  How many service providers cannot participate in pooling (i.e., they
    are not LNP capable) and therefore, will require full CO/NXX Codes
    which will not be available for the pool?

```{=html}
<!-- -->
```
1.  How might pooling impact the infrastructure deployed to support LNP?

```{=html}
<!-- -->
```
1.  How soon can pooling be deployed?

```{=html}
<!-- -->
```
1.  Can pooling be implemented without significant negative impact to
    any particular industry segment?

    Determination of the increase that pooling might provide to the life
    of the NPA is dependent upon the use of industry data which quantify
    the available resources and industry forecasts which identify the
    future demand for resources. A Lockheed Martin/Bellcore contribution
    (LNPA-60) to this workshop effort described such an assessment. The
    results of this type study are wholly reliant on data unique to the
    area for which they are performed, and cannot generally be
    extrapolated to other areas.

    It does appear however that the benefit associated with pooling --
    that is, the ability to better utilize numbering resources and delay
    the need for NPA relief -- is better realized if pooling is
    initiated "early in the life" of a given NPA, when there exist a
    large number of NXX codes still unassigned. It further appears that
    the implementation of pooling "late in the life" of an NPA, for
    example when the code is already in a jeopardy situation, is likely
    to provide relatively little delay in the need for NPA relief.

    **15.0 TRANSITION**

    Transition planning is necessary to permit the effective and
    efficient migration from the current central office code based
    number assignment and administration processes to those associated
    with a pooled environment. Key to this transition is the:

```{=html}
<!-- -->
```
1.  identification of the pool administrator

```{=html}
<!-- -->
```
1.  establishment of the industry inventory of numbering resources and
    the possible use of embedded as well as growth numbers to initially
    populate the industry inventory.

```{=html}
<!-- -->
```
1.  development of assignment and administrative guidelines

15.1 Resources for the Industry Inventory Pool

Both newly assigned and embedded numbering resources will be considered
for inclusion in the industry inventory pool subject to yet to be
developed industry guidelines. These guidelines should include, but not
be limited to, criteria for the initial establishment of the pool, its
ongoing maintenance, and a determination of eligibility of resources for
the pool.

The INC recommends that embedded 1000s blocks, either uncontaminated or
contaminated up to a level of 10%, be considered by the pool
administrator for placement in the industry pool, initially and on an
ongoing basis. The INC recognizes that the use of contaminated blocks,
although potentially improving number utilization, adds administrative
burden, increases capacity requirements in LNP SCPs, and may not be
warranted in all cases.

The specific level of contamination (0% to 10%) necessary to meet
industry needs in a specific area will be determined by the pool
administrator, consistent with pooling guidelines. The administrator
should attempt to satisfy industry demand with blocks associated with
the lowest level of contamination; first considering the use of
uncontaminated blocks (i.e., 0%), and only then considering employing
blocks with increasing levels of contamination (up to 10%).

Embedded 1000s blocks for which a service provider has a forecasted
demand will not be considered for placement in the industry pool.

**16.0 Recommendations** [^10]

Number pooling potentially offers improvement in number utilization. Its
implementation, however, requires significant changes to current
administrative processes, modifications to existing systems, and the
development of new systems. The extent of these changes and additions
and, therefore, the time frame in which pooling could be implemented are
specifically dependent upon the pooling alternative selected and the
local conditions where pooling is to be implemented.

The INC recommends that number pooling be implemented in an evolutionary
manner, with the initial deployment of 1000s block pooling (Alternative
2) with migration to an individual TN pooling arrangement (e.g.,
Alternative 1 or 3) as a long term goal.

Further, the INC believes that 1000s block pooling appears to be less
complex than individual TN pooling and could be implemented in a shorter
time frame. It is further recognized that individual TN pooling,
although more administratively complex, may offer even further
improvement in utilization than block pooling.

The implementation of 1000s block pooling cannot be realized without
modifications to existing systems and industry consensus on specific key
details relevant to the assignment and administration processes. These
include the need to identify the arrangement for snapback, a method for
determining the LERG Assignee, the use of pre-port or port on demand,
criteria for the identification and the possible use of embedded number
resources, a uniform pooling architecture, the development of
administrative and assignment guidelines and the selection of a pooling
administrator(s). Therefore, the INC recommends that the industry's
immediate efforts focus on these and other issues essential for the near
term implementation of block pooling.

Subsequent to resolution of the issues associated with block pooling,
the INC will develop a proposal for the transition to individual TN
pooling.

**APPENDIX 1**

**INDUSTRY NUMBERING COMMITTEE (INC) CONTRIBUTION**

**LNPA WORKSHOP**

**TITLE: Number Pooling Evaluation Matrix - Issue 105 -- LNPA-48**

**DATE: 9/29/97**

**SOURCE:** Josephine A. Gallagher

Bell Atlantic

1310 North Court House Rd.

3^rd^ Floor

Arlington, VA 22201

Tel: 703-974-8160

Fax: 703-974-0616

Email: josephine.a.gallagher@bell-atl.com

**ABSTRACT: Attached is a draft alternative evaluation matrix.**

**NOTICE:**

This contribution has been prepared by Bell Atlantic to assist the LNPA
Workshop. This document is offered to the LNPA Workshop as a basis for
discussion and is not a binding proposal on Bell Atlantic. Bell Atlantic
specifically reserves the right to amend or withdraw the statements
contained herein.

+----------------+-----------------+-----------------+-----------------+
| **Assessment   | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
| Criteria**     | SPIV optional** | blks, SPIV      | SPIV required** |
|                |                 | required**      |                 |
+----------------+-----------------+-----------------+-----------------+
| **1. Number    | Most efficient  | Provides more   | Most efficient  |
| utilization**  | use of numbers; | efficient use   | use of numbers; |
|                | only "stranded" | of numbers      | only "stranded" |
|                | numbers are     | compared to     | numbers are     |
|                | those unused in | current 10,000  | those unused in |
|                | SP inventories; | number          | SP inventories; |
|                | issue may be    | allocation;     | issue may be    |
|                | size of SP      | more "stranded" | size of SP      |
|                | inventories     | numbers for SPs | inventories     |
|                |                 | who need \<1000 |                 |
|                | Efficiency      | numbers/rate    | Efficiency      |
|                | could be        | center.         | could be        |
|                | maximized if    |                 | maximized if    |
|                | all embedded    | Could be even   | all embedded    |
|                | codes in IIV.   | less efficient  | codes in IIV.   |
|                |                 | if "slightly    |                 |
|                | Maximum benefit | contaminated"   | Maximum benefit |
|                |                 | 1000 blocks not |                 |
|                |                 | in IIV.         |                 |
|                |                 |                 |                 |
|                |                 | Relatively      |                 |
|                |                 | lower benefit   |                 |
|                |                 | compared to     |                 |
|                |                 | Alts. 1 & 3     |                 |
+----------------+-----------------+-----------------+-----------------+

+----------------+-----------------+-----------------+-----------------+
|                | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
|                | SPIV optional** | blks, SPIV      | SPIV required** |
|                |                 | required**      |                 |
+----------------+-----------------+-----------------+-----------------+
| **2.           | **IIV pool** -  | **IIV pool** -  | **IIV pool** -  |
| Infrastructure | supports TN     | supports TN     | supports TN     |
| impacts**      | inventory at    | inventory only  | inventory at    |
|                | line level;     | to thousands    | line level;     |
|                | larger database | block; smaller  | larger database |
|                | required;       | database        | required.       |
|                | database        | required;       | Supports        |
|                | functionality   | "Good" numbers  | specific        |
|                | required to     | embedded in     | number/"good    |
|                | track status of | thousands       | number"         |
|                | numbers         | blocks.         | requests but    |
|                | (assigned,      |                 | not on demand   |
|                | spare, aging,   | Low compared to | basis.          |
|                | reserved) for   | Alts. 1 & 3     |                 |
|                | SPs without     |                 | High            |
|                | SPIV; large     | **IIV pool      |                 |
|                | database could  | interface to SP | **IIV pool      |
|                | be required if  | OSSs** - lower  | interface to SP |
|                | large SPs opt   | volume          | OSSs** *-*      |
|                | for no SPIVs.   | interface;      |                 |
|                | Must support    | still in        | Downloads       |
|                | "on demand"     | critical path   | allocations at  |
|                | requests for    | for pooling     | individual TN   |
|                | specific        | implementation  | level. Still in |
|                | numbers/"good   | but lower risk  | critical path   |
|                | numbers".       | because less    | for pooling     |
|                |                 | complex.        | implementation  |
|                | Very High       |                 | but may be less |
|                | Impacts         | Lower compared  | risk compared   |
|                |                 | to Alts. 1 & 3  | to Alt. 1.      |
|                | **IIV pool      |                 |                 |
|                | interface to SP | **LNP SMS, LNP  | Medium/High     |
|                | OSSs** -        | SCPs** -        |                 |
|                | Downloads       |                 | **LNP SMS, LNP  |
|                | allocations at  | *pre-port -*    | SCPs** -        |
|                | individual TN   | very large,     |                 |
|                | level. High     | immediate       | If no pre-port, |
|                | volume          | increase in     | LNP transaction |
|                | interface for   | size or         | for disconnects |
|                | updates to IIV  | modification to | on non-LERG     |
|                | pool for every  | support         | assignee        |
|                | change in TN    | treatment by    | switches.       |
|                | status for SPs  | blocks; (open   |                 |
|                | with no SPIVs.  | issue GTTs).    | Different       |
|                | High volume     |                 | impacts if      |
|                | interface to    | *port on        | pre-port SPIV   |
|                | support search  | demand* - LNP   | or snapback to  |
|                | for, obtaining  | SMS interaction | SPIV vs. IIV.   |
|                | numbers "on     | for every       |                 |
|                | demand," as     | activated       | .               |
|                | well as for SPs | number and      |                 |
|                | with no SPIV    | disconnected    | Medium/High     |
|                | IIV pool access | number on       |                 |
|                | is in critical  | non-LERG        | **SSPs** - No   |
|                | path for volume | assignee        | impacts unless  |
|                | interface to    | switches.       | pre-port. If    |
|                | support search  |                 | pre-port SPIV,  |
|                | for, obtaining  | *Snapback* to   | unassigned      |
|                | numbers "on     | block assignee  | number must be  |
|                | demand," as     | vs. code        | acceptable in   |
|                | well as for SPs | assignee        | GAP; change     |
|                | with no SPIV    | impacts LNP SMS | from LNP        |
|                | IIV pool access | translations.   | procedures      |
|                | is in critical  |                 |                 |
|                | path for        | Low/Medium      | Potential SSP   |
|                | pooling         |                 | real time       |
|                | implementation; | **SSPs** - If   | processor issue |
|                | availability    | pre-port,       | if pre-port and |
|                | and speed of    | unassigned      | use "two pass"  |
|                | response issue. | number must be  | database search |
|                |                 | acceptable in   | method.         |
|                | High            | GAP; change     |                 |
|                |                 | from LNP        |                 |
|                | **LNP SMS, LNP  | procedures.     |                 |
|                | SCPs** -        |                 |                 |
|                | Potential LNP   | Potential SSP   |                 |
|                | SMS interaction | real time       |                 |
|                | for every       | processor issue |                 |
|                | activated       | if pre-port and |                 |
|                | number for SPs  | use "two pass"  |                 |
|                | without SPIV    | database search |                 |
|                | (if updates     | method.         |                 |
|                | done by PA).    |                 |                 |
|                |                 |                 |                 |
|                | If no pre-port, |                 |                 |
|                | LNP transaction |                 |                 |
|                | for disconnects |                 |                 |
|                | on non-LERG     |                 |                 |
|                | assignee        |                 |                 |
|                | switches.       |                 |                 |
|                |                 |                 |                 |
|                | Different       |                 |                 |
|                | impacts if      |                 |                 |
|                | pre-port SPIV,  |                 |                 |
|                | or if snapback  |                 |                 |
|                | to SPIV vs.     |                 |                 |
|                | IIV.            |                 |                 |
|                |                 |                 |                 |
|                | High            |                 |                 |
|                |                 |                 |                 |
|                | **SSPs** - No   |                 |                 |
|                | impacts unless  |                 |                 |
|                | pre-port. If    |                 |                 |
|                | pre-port SPIV,  |                 |                 |
|                | unassigned      |                 |                 |
|                | number must be  |                 |                 |
|                | acceptable in   |                 |                 |
|                | GAP; change     |                 |                 |
|                | from LNP        |                 |                 |
|                | procedures      |                 |                 |
|                |                 |                 |                 |
|                | Potential SSP   |                 |                 |
|                | real time       |                 |                 |
|                | processor issue |                 |                 |
|                | if pre-port and |                 |                 |
|                | use "two pass"  |                 |                 |
|                | database search |                 |                 |
|                | method.         |                 |                 |
+----------------+-----------------+-----------------+-----------------+

+-----------------+-----------------+-----------------+-----------------+
|                 | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
|                 | SPIV optional** | blks, SPIV      | SPIV required** |
|                 |                 | required**      |                 |
+-----------------+-----------------+-----------------+-----------------+
| **3. Operations | Interface with  | Interface with  | Interface with  |
| impacts**       | IIV (see        | IIV (see        | IIV (see        |
|                 | above).         | above). OCN     | above).         |
|                 |                 | mapping to      | Increased       |
|                 | Increased       | thousands       | administration  |
|                 | administration  | blocks in TPM,  | associated with |
|                 | associated with | LERG. OSS       | lack of block   |
|                 | lack of block   | changes to      | structure. OSS  |
|                 | structure.      | assign numbers  | changes for     |
|                 |                 | only within     | rate center     |
|                 | If no SPIV, may | assigned        | association     |
|                 | need to consult | blocks, changes | with numbers at |
|                 | IIV pool to     | to support      | line level.     |
|                 | determine       | thousands       |                 |
|                 | status of own   | block/rate      | Some manual     |
|                 | numbers. If so  | center          | "exception"     |
|                 | SPIV, OSS       | structures in   | treatment of    |
|                 | changes to      | administrative  | ported numbers  |
|                 | support updates | tables. SP OSSs | may require     |
|                 | to IIV pool     | continue to     | mechanization   |
|                 | regarding       | perform TN      | due to          |
|                 | number status.  | assignment,     | increased       |
|                 |                 | administration, | volume.         |
|                 | OSS changes for | and inventory   |                 |
|                 | rate center     | for thousands   | If port on      |
|                 | association     | blocks assigned | demand,         |
|                 | with numbers at | to them. OSS    | modifications   |
|                 | line level.     | changes to      | to service      |
|                 |                 | mechanize       | negotiation and |
|                 | Some manual     |                 | service order   |
|                 | "exception"     | If port on      | processing      |
|                 | treatment of    | demand,         | systems will be |
|                 | ported numbers  | modifications   | required to     |
|                 | may require     | to service      | indicate that   |
|                 | mechanization   | negotiation and | pooled number   |
|                 | due to          | service order   | must be ported  |
|                 | increased       | processing      | in when         |
|                 | volume.         | systems will be | assigned to a   |
|                 |                 | required to     | customer.       |
|                 | If port on      | indicate that   |                 |
|                 | demand,         | pooled number   | Medium/High     |
|                 | modifications   | must be ported  |                 |
|                 | to service      | in when         |                 |
|                 | negotiation and | assigned to a   |                 |
|                 | service order   | customer.       |                 |
|                 | processing      |                 |                 |
|                 | systems will be | Medium          |                 |
|                 | required to     |                 |                 |
|                 | indicate that   |                 |                 |
|                 | pooled number   |                 |                 |
|                 | must be ported  |                 |                 |
|                 | in when         |                 |                 |
|                 | assigned to a   |                 |                 |
|                 | customer.       |                 |                 |
|                 |                 |                 |                 |
|                 | High            |                 |                 |
+-----------------+-----------------+-----------------+-----------------+

+-----------------+-----------------+-----------------+-----------------+
|                 | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
|                 | SPIV optional** | blks, SPIV      | SPIV required** |
|                 |                 | required**      |                 |
+-----------------+-----------------+-----------------+-----------------+
| **4. End user   | Few end user    | Minimal end     | Minimal end     |
| impacts**       | impacts -       | user impacts -  | user impacts -  |
|                 | supports        | supports        | supports        |
|                 | ability to      | ability to      | ability to      |
|                 | obtain          | obtain          | obtain          |
|                 | sufficient      | sufficient      | sufficient      |
|                 | numbers to meet | blocks of       | numbers to meet |
|                 | an end user's   | numbers to meet | an end user's   |
|                 | request.        | an end user's   | request.        |
|                 | Possible        | request.        | Possible        |
|                 | concern         | Possible        | concern         |
|                 | regarding IIV   | concern         | regarding IIV   |
|                 | pool in         | regarding IIV   | pool critical   |
|                 | critical path   | pool critical   | path if         |
|                 | if no SPIV or   | path if         | insufficient    |
|                 | insufficient    | insufficient    | numbers in      |
|                 | numbers in      | numbers in SPIV | SPIV.           |
|                 | SPIV, e.g. how  |                 |                 |
|                 | to serve demand | Low             | Low             |
|                 | requests in IIV |                 |                 |
|                 | system down or  |                 |                 |
|                 | data links to   |                 |                 |
|                 | it are down.    |                 |                 |
|                 |                 |                 |                 |
|                 | Medium          |                 |                 |
+-----------------+-----------------+-----------------+-----------------+

+-----------------+-----------------+-----------------+-----------------+
|                 | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
|                 | SPIV optional** | blks, SPIV      | SPIV required** |
|                 |                 | required**      |                 |
+-----------------+-----------------+-----------------+-----------------+
| **5. Number     |                 | Most            |                 |
| assignment      |                 | straightforward |                 |
| impacts**       |                 | allocation      |                 |
|                 |                 | plan. All SPs   |                 |
|                 |                 | get blocks of   |                 |
|                 |                 | numbers based   |                 |
|                 |                 | on forecast.    |                 |
|                 |                 | "Good" numbers  |                 |
|                 |                 | allocated       |                 |
|                 |                 | equitably. Most |                 |
|                 |                 | like current    |                 |
|                 |                 | approach to     |                 |
|                 |                 | SPIVs.          |                 |
|                 |                 |                 |                 |
|                 |                 | Snapback        |                 |
|                 |                 | impacts will    |                 |
|                 |                 | differ if       |                 |
|                 |                 | snapback to IIV |                 |
|                 |                 | vs. SPIV.       |                 |
|                 |                 |                 |                 |
|                 |                 | Low compared to |                 |
|                 |                 | Alts. 1 & 3.    |                 |
+-----------------+-----------------+-----------------+-----------------+

+-----------------+-----------------+-----------------+-----------------+
|                 | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
|                 | SPIV optional** | blks, SPIV      | SPIV required** |
|                 |                 | required**      |                 |
+-----------------+-----------------+-----------------+-----------------+
| **6.            | Analysis of     | Analysis of     | Analysis of     |
| Administration  | reports from    | reports from    | reports from    |
| impacts**       | SPIV            | block assignees | SPIV assignees  |
|                 | assignees +     | to assess NXX   | to assess NXX   |
|                 | interactive     | exhaust.        | exhaust.        |
|                 | demands to      |                 |                 |
|                 | assess NXX      | Low compared to | Medium          |
|                 | exhaust.        | Alts. 1 & 3     |                 |
|                 |                 |                 |                 |
|                 | TN              |                 |                 |
|                 | administration  |                 |                 |
|                 | for SPs with no |                 |                 |
|                 | SPIVs.          |                 |                 |
|                 |                 |                 |                 |
|                 | Potential LNP   |                 |                 |
|                 | SMS interaction |                 |                 |
|                 | for every       |                 |                 |
|                 | activated       |                 |                 |
|                 | number for SPs  |                 |                 |
|                 | without SPIV    |                 |                 |
|                 | (if updates     |                 |                 |
|                 | done by Pooling |                 |                 |
|                 | Administrator). |                 |                 |
|                 |                 |                 |                 |
|                 | High            |                 |                 |
+-----------------+-----------------+-----------------+-----------------+

+-----------------+-----------------+-----------------+-----------------+
|                 | **1 -Line lvl,  | **2 - Thou      | **3 - Line lvl, |
|                 | SPIV optional** | blks, SPIV      | SPIV required** |
|                 |                 | required**      |                 |
+-----------------+-----------------+-----------------+-----------------+
| **7. Relative   | Probably        | Probably least  | Probably lower  |
| costs**         | highest cost    | cost approach   | cost than       |
|                 | relative to     | both to         | Alternative 1   |
|                 | Alternatives 2  | establish and   | but higher cost |
|                 | & 3 both to     | on-going        | than            |
|                 | establish and   | industry and SP | Alternative 2   |
|                 | on-going        | administration. | both to         |
|                 | industry and SP |                 | establish and   |
|                 | administration. |                 | on-going        |
|                 |                 |                 | industry and SP |
|                 |                 |                 | administration. |
+-----------------+-----------------+-----------------+-----------------+
| **8. Time for   | Critical path   | Critical path   | Critical path   |
| availability**  | concerns - IIV  | concerns - SCP  | concerns - IIV  |
|                 | pool database   | capacities;     | pool database   |
|                 | planning and    | modifications   | planning and    |
|                 | development,    | for             | development,    |
|                 | interface to    | pre-porting,    | interface to    |
|                 | LNP SMS,        | pooling         | LNP SMS,        |
|                 | pooling         | administrator;  | pooling         |
|                 | administrator,  | assignment      | administrator,  |
|                 | assignment      | guidelines, OSS | assignment      |
|                 | guidelines,     | impacts.        | guidelines,     |
|                 | operations      |                 | operations      |
|                 | impacts.        | Probably        | impacts.        |
|                 |                 | shortest path   |                 |
|                 | Probably        | because least   | Probably        |
|                 | longest path    | complex.        | shorter path    |
|                 | because most    |                 | than Alt. 3 but |
|                 | complex.        |                 | longer than Alt |
|                 |                 |                 | 2 because of    |
|                 |                 |                 | relative        |
|                 |                 |                 | complexities.   |
+-----------------+-----------------+-----------------+-----------------+

Acronyms

GAP Generic Address Parameter

SPIV Service Provider Inventory

IIV Industry Inventory

SSP Service Switching Point

LERG Local Exchange Routing Guide

OSS Operations support systems

LNP Local Number Portability

TPM Terminating Point Master

NPAC Number Portability Administration Center

SCP Service Control Point

SMS Service Management System

SP Service Provider

**APPENDIX 2**

The "Industry Numbering Committee (INC) Initial Report to the North
American Numbering Council (NANC) on Number Pooling" presents the
consensus view of the INC participants on the number pooling issues
addressed in the report. The report represents a concerted effort by the
industry to reach agreement on the many issues associated with the
introduction of number pooling. During the development of this report
however, individual companies may have expressed an opinion that differs
from the consensus reached by the INC.

This appendix provides an opportunity for those individual companies to
express their "minority" opinion and have them considered along with the
INC consensus report.

**MCI Comments Regarding INC Number Pooling Recommendations**

MCI hereby submits these comments as a minority opinion concerning the
contents of the Industry Numbering Committee (INC) Report To The North
American Numbering Council (NANC) On Number Pooling, as submitted to the
NANC on December 15, 1997.

MCI has participated actively in all aspects of the INC LNPA
committee\'s work, and concurs with the majority of analysis and
conclusions contained in the report. However, MCI does not concur in the
committee's consensus positions on some of the key issues discussed in
the report. Following is a statement of MCI's position on these issues
and supporting rationale.

1\) Early in the process of evaluating alternatives for number pooling,
the INC majority voted to eliminate Alternative 4 from further
consideration as a pooling alternative. While MCI readily acknowledges
that Alternative 4 represents the greatest departure from the status
quo, of all the pooling alternatives, it objectively does the most to:

1.  maximize number utilization;

```{=html}
<!-- -->
```
1.  eliminate the ability of carriers to engage in number hoarding;

```{=html}
<!-- -->
```
1.  completely remove numbering as a potential competitive barrier;

```{=html}
<!-- -->
```
1.  maximize customer choice; and

```{=html}
<!-- -->
```
1.  maximize the ability for number administrators to have accurate
    utilization information for area code relief planning.

Given the significance of these benefits, it would seem obvious that
this alternative should have at least been offered a complete
evaluation. Instead, the alternative was dismissed on its face because
it was \"too burdensome,\" and because it didn\'t allow carriers to use
their current systems. During the meetings, it was also suggested that
lack of time to evaluate it properly (i.e., before the initial report
was due on 10/21/97) made it unsuitable for further evaluation.

It is MCI\'s opinion that elimination of this alternative before giving
full consideration of all benefits and impacts represents a significant
lack of critical evaluation in the current version of the INC report
that will ultimately reduce the effectiveness of the INC effort. MCI
would point out, as it did in its INC contribution, that continued
consideration of Alternative 4 as a viable TN-level pooling alternative
would not have committed any carrier to ultimately supporting it, or
deny any interested party the opportunity to comment on the merits or
deficiencies of the proposal. However, its exclusion so early in the
evaluation process artificially censored the debate on number pooling
before it even began.

2\) MCI sought, through several contributions (INC LNPA-51,53, 54, 55,
62, 63, 64) to have Customer Flexibility adopted as a pooling Principle,
and included as one of several criteria that should be used to evaluate
specific pooling proposals. The Customer Flexibility Principle supports
the ability of any customer requesting a specific, unassigned telephone
number to choose any service provider, regardless of the service
provider\'s current allocation of Central Office codes and/or individual
telephone numbers.

This principle is vital in evaluating any pooling alternative, because
it recognizes that customer needs must be balanced with carrier
convenience in determining the optimal pooling mechanism. Numbering
issues should not be a factor in a customer\'s choice of local service
provider. By failing to at least recognize the importance of enabling
customer choice, to the greatest extent practicable, the industry may
miss an opportunity to consider the needs of the very customers that
numbering administration is designed to serve.

3\) MCI agrees with the industry recommendation to use contaminated
1000s blocks in the industry number pool. However, MCI believes the 10%
contamination maximum is arbitrary and will limit the ability of 1000s
block pooling to maximize number utilization, customer flexibility, and
equal availability of numbers among competitors. MCI believes instead
that specific levels of contamination should be determined based on the
unique circumstances of each area in which pooling is implemented, and
not be constrained by an arbitrary limit.

MCI further objects to the failure of the recommendation to recognize
the jurisdiction of state regulators to consider additional criteria
(other than forecasted demand) in establishing contamination levels, and
the authority of those regulators to modify pooling administrator
determinations regarding the optimal contamination level for an area.

**GTE Comments regarding the INC Number Pooling Report**

The following are GTE\'s comments regarding the latest draft of the
pooling document that will be reviewed by the NANC on December 15th
1997. Significant work still is required to finish the report. The
present version was not intended to be the final draft. GTE submits
these comments as a minority opinion concerning the contents of the INC
draft report on pooling.

There are many elements of the document for which there is no agreement.
Although there was consensus to make recommendations to the NANC, no
evaluation of the three alternatives has been accomplished. The document
is not ready for publication because no analysis has been done to
validate the recommendation against the criteria developed within the
report. Neither is the document sufficiently complete to guide decisions
by NANC.

Many PUC/PSCs want number pooling to be their salvation for injudicious

decisions regarding NPA code relief activities. Two factors work against
the expectation that pooling will magically provide a solution to the
difficult trade‑offs of NPA relief. The first factor is that the number
pooling methodology under consideration in INC requires LRN. This
constrains the timing of pooling implementation to follow the LRN
deployment schedule. The second factor is that number pooling is
constrained by LRN to the wire center. This constrains the degree of
efficiency that can be gained from pooling.

GTE has participated actively in all the meetings held at the INC LNPA
Workshop. We have serious concerns that the report could be interpreted
as a blanket confirmation that pooling should be implemented regardless
of local circumstances and/or as a panacea for numbering availability
problems and NPA code relief situations.

GTE feels that it is extremely important that any recommendation that
comes out of the NANC be implementable. Therefore, GTE feels very
strongly that the section on Criteria for Pooling Implementation should
be strengthened in the report. To this end, we propose that the
following text should be considered by NANC and incorporated in any
final recommendation that NANC proposes with respect to pooling.

It is our opinion that pooling can potentially be very useful to the
industry in obtaining more efficient use of numbering resources. In
certain circumstances and pooling may potentially be used to prolong the
life of NPA codes. However, we feel that it is necessary that each
situation be evaluated on its own merit. The costs in money,
administrative complexity, network modifications and customer impacts
need to be studied in each case where pooling is being considered for
implementation.

**CONDITIONS FOR POOLING IMPLEMENTATION**

GTE hereby proposes considerations and criteria that should be evaluated
prior to the implementation of any proposed pooling arrangement that is
recommended by the industry. By assessing the selected pooling
arrangement with respect to these criteria it will then be possible to
determine the practicality of implementing a given pooling arrangement
in a particular location.

**IMPLEMENTATION CRITERIA LIST**

**1. Quantity of numbers available to be pooled**

An analysis should be conducted to quantitatively evaluate the benefit
of pooling to determine the potential quantity of numbers that will be
made available because of pooling. For example, if there are a potential
of 8 million numbers in a given area but only 10,000 additional numbers
will be made available as a result of the implementation of a pooling
arrangement then, pooling may not be a practical approach to solving a
numbering resource problem.

To justify the implementation of a pooling solution more numbers need to
be made available to all service providers participating in the pool. It
is also recommended that the Bellcore/Lockheed pooling evaluation tool
be used to help conduct this evaluation. The use of this tool requires
that all participating carriers provide code utilization data (both
estimates and actual values) to a neutral third party as input for the
tool. Conducting this evaluation will determine if the introduction of
pooling provides a significant quantity of numbers to be made available
for assignment to all participating carriers.

**2. Administrative procedures required.**

An assessment should be conducted to get a measure of the pooling
administrative procedures required to effectively manage the pooling
process. For example it must be determined that competitive service
providers are prepared to accept the responsibility of becoming the
carrier of record for pooled CO Codes. A service provider is required to
be designated as the LERG assignee for every CO code that is entered
into the pool so that vacant number treatment is provided when a code is
first opened. The LERG designee may potentially not use the majority of
the numbers in a given code. Another such administrative issue is the
need to provide the pooling administrator access to certain proprietary
business information. The pooling participants must be ready to accept
certain administrative responsibilities and obligations to participate
in a pool. Finally, these participants must be prepared to pay for the
pool administration and to be bound by the agreed to pooling procedures.

It is recommended that an evaluation be conducted to determine the cost
benefit of adopting a pooling approach.

**3. Time frame of implementation.**

An assessment is required to determine the time frame by when the
pooling arrangement can be implemented. This evaluation should take into
account the time frame necessary to transition to the pooling
environment and time required to coordinate all the steps to implement
the desired pooling arrangement. The assessment should be made relative
to the existence of Administrative procedures and the availability of
LNP in the coverage area where pooling is being considered. If LNP is
not available in the time frame that pooling is being recommended then
pooling may not be a viable alternative.

**4. Circumstances that justify the implementation of pooling.**

The implementation of pooling should be justified by ascertaining the
circumstances under which a particular number pool is beneficial to all
the participants in the pooling arrangement. There should be a
determination / assessment conducted in an unbiased fashion that shows
how all pooling participants benefit. If there are any negative impacts
to particular industry segments, these issues should be taken into
consideration before a pooling arrangement is implemented. For example,
if one or more industry segments are disadvantaged by the adoption of
pooling (i.e. inadequate or limited numbering resources are made
available), then the adoption of pooling should be questioned. Only, for
a set of circumstances where all pooling participants benefit and obtain
adequate numbering resources should pooling be implemented.

**5. Network Architectural impacts.**

An assessment of the network architectural impacts on the different
networks that participate in any pooling arrangement should be conducted
before pooling is adopted in a particular location. For example, the
adoption of pooling should not require excessive changes to existing
network architectures of potential pooling participants. These changes
could include, the addition of new data interfaces, additional security,
additional data bases, and changes to existing network architectural
elements. Conducting this type of assessment will provide a relative
technical impact analysis for the different networks that could
potentially participate in any pooling arrangement. It should also
include a detailed analysis of any architectural infrastructure changes
required for pooling relative to being able to support a regular
portability environment. Any impacts on network performance / quality
(i.e. additional time delays, additional database dips, storage
requirements, etc.). should be included in such an analysis.

**6. Verify that the pooling to be implemented is the standard method**

**that has been recommended through out the area served by the NANP.**

NANC has determined that a NANP wide uniform Number Pooling solution be

adopted by the industry. Therefore, it is required that the pooling
approach being implemented be compliant with the NANC recommended
method. The adoption of pooling should not require that unique
regulatory, business, or architectural arrangements be adopted for a
particular location.

The above set of criteria should be used in assessing the possibility
for pooling implementation. The results generated as a result of such an
evaluation are necessary to justify the benefits of pooling. Before
pooling is implemented its benefits should be clearly understood, and
justified. for a given location.

[^1]: A rate center, as used here, denotes the smallest geographic area
    used to distinguish rate boundaries.

[^2]: Although switch based seven digit analysis and translation can
    conceivably be supported in many switches and could, therefore, be
    used to route calls in some pooled number environments, it is the
    consensus of the industry that this capability as administratively
    burdensome and inefficient in its use of switch memory. Therefore,
    seven digit analysis is not a practical routing alternative using
    the mechanisms of LNP.

[^3]: The assignment of numbers to subscribers who reside in the rate
    center to which a given NPA-NXX is assigned is a wireline service
    provider paradigm. It should be recognized that wireless service
    providers typically are not constrained to this assignment procedure
    and may assign numbers to their subscribers from a given NPA-NXX
    even if those subscribers reside outside the rate center with which
    the NPA-NXX is associated.

[^4]: Although it is likely that most service providers will maintain
    their own inventory of numbers, it is possible that a service
    provider may choose to employ the services of another service
    provider, or perhaps a third party database provider, for the
    maintenance of its inventory of numbers.

[^5]: As previously described, wireless providers may provide their
    subscribers number assignments associated with a given rate center
    even if those subscribers reside outside that rate center.

[^6]: NPA-NXX assignment information is also documented in NECA FCC
    Tariff No. 4.

[^7]: Modifications are currently being considered which would support
    the association within the LERG of less than a full NXX code (e.g.,
    a range of numbers such as a 1000s block) with a given service
    provider. Although the availability of this more detailed
    information is welcome, the need to accommodate default routing
    continues to demand the designation of a single (default) service
    provider for each NPA-NXX.

[^8]: This may require single or multiple orders dependent upon the
    methodology employed ( Pre-porting or Porting On Demand.)

[^9]: Proposals have been made to the industry that would reduce this
    interval.

[^10]: It must be recognized that only LNP capable networks should
    participate in number pooling. Non -LNP-capable networks,
    nonetheless, must have equivalent access to adequate numbering
    resources via current industry assignment guidelines.