Illinois Number Portability Workshop

Number Pooling Subcommittee






Report on Number Pooling

A report on the feasibility of implementing number pooling to relieve the pending exhaust of the 847 area code





September 2, 1997









Table of Contents


  1. 1. Executive Overview
  2. 2. Background

    3. Description of NXX-X/LRN

    4. Scope

    5. Operational Assumptions

    6. Numbering Constraints

    7. Network Impacts

    7.1. Regional NPAC/SMS

    7.2. End Offices

    7.3. SCPs

    7.4. 911 Systems

    8. Operational Impacts

    8.1. Rating and Billing

    8.2. Alternate Billing

    8.3. Operator Assistance/Directory Assistance

    8.4. Process Flows

    8.5. Provisioning and Support Systems

    8.6. Limited Liability Corporation

    9. Number Administration

    10. Cost Allocation and Recovery

  3. Conclusions and Recommendation


  1. Executive Overview

The Illinois Number Portability Workshop established a Number Pooling Subcommittee (the Subcommittee) to assess the feasibility and practicality of implementing number pooling at the thousands-block level, using the AT&T NXX-X/LRN plan, to relieve the 847 NPA. The Subcommittee focused its efforts on potential impacts to the network, operations and current number administration. It acknowledged certain constraints to the application of number pooling, most notably that it would be limited to only wireline service providers whose networks were LNP-capable. As such, there may still be a significant, ongoing demand for full NXXs to accommodate the needs of wireless and other non-LNP capable service providers.

The Subcommittee's analysis revealed that the incremental impact of number pooling (over and above number portability) varied depending upon the component under study. The impact on end offices, Operator Services/Directory Assistance, 911, LIDB and rating and billing appear to be minimal. Its impact on other systems, such as NPAC interfaces, legacy provisioning and support systems (OSS) and LNP data bases is somewhat more significant. Most crucial was the potential impact on SCP record storage capacity. Since pooling relies upon the storage of number routing information within LNP data bases, it competes with service provider number portability-ported numbers for the same limited record capacity resource available in current SCPs. One of two methodologies for implementing number pooling could limit this capacity concern in the near term. However, this would require significant enhancements to several legacy OSS, which would then be abandoned or modified if and when the preferred long term methodology was employed.

Coincident with the impact assessment, the Subcommittee helped define and pursue a comparison of the forecasted demand with availability of numbers in a pooling environment. The results of that comparison revealed that number pooling, if implemented by 1/1/98, may extend the exhaust date of the 847 area code by six to twelve months.

Due to the significance of the record capacity and OSS concerns, the Subcommittee recommends that implementation of number pooling be delayed beyond 1/1/98, until solutions are identified and available. If current projections on the exhaust date of NPA 847 remain unchanged and or those solutions are not found, this may require the industry to pursue other measures of relief.


The Illinois NANP Code Administrator has projected the exhaust of assignable Central Office codes (NXXs) within the 847 area code (NPA) to occur on or around the end of the second quarter of 1998. In anticipation of this exhaust, several meetings and conference calls have been conducted among Telecommunications Industry Representatives and stakeholders to identify feasible alternatives to address this exhaust situation. The initial focus of these meetings was to analyze either an NPA split or an NPA overlay. An NPA split would reduce the area of coverage for the 847 area code, and introduce a new NPA code to serve the vacated portion. The latter would introduce a second area code within the same 847 NPA boundary, to serve all new customers of telecommunications services once the 847 area code was at total exhaust.

It is acknowledged that in a multiple NPA environment, each subsequent split diminishes the actual area of relief, and leaves other surrounding area codes with similar exhaust potential. NPA overlays offer the potential for wider areas of relief, since overlays can be used for more than one area code. However, overlays require mandatory 10-digit dialing within the affected area, even for calls within the same NPA.

In May, 1997, the Citizens Utility Board (CUB) proposed a third alternative, which utilized the soon-to-be-deployed local number portability (LNP) technology to offer a form of number pooling. The ATIS-sponsored Industry Numbering Committee (INC) describes Number Pooling as:

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

Based upon an AT&T proposal under study within several industry forums (i.e., NXX-X/LRN), this alternative would allow individual carriers serving the same rate center area to be allocated blocks of 1,000 numbers from the 10,000 available within the same NXX to serve new customers.

The Illinois Number Portability Workshop (The Workshop) has assigned responsibility for assessing the feasibility and practicality of implementing this form of number pooling as an appropriate relief alternative for the 847 NPA to the newly-formed Number Pooling Subcommittee. Specifically, they have been directed to determine whether the CUB/AT&T proposal can be implemented on or around 1/1/98 to relieve the 847 NPA. This report summarizes the research and discussions held over the past several months within this and other Workshop subcommittees on this issue.

Description of NXX-X/LRN

Role of the NXX in the North American Numbering Plan

The telephone numbering system used in North American countries is defined by the North American Numbering Plan (NANP). This Plan defines a 10-digit telephone number format of NPA-NXX-XXXX. The NPA (Numbering Plan Area) is more commonly known as the area code. The NXX identifies the central office (CO) switch or CO code to which the XXXX or line number is assigned. In the NXX and XXXX, N can be any digit from 2 through 9, and X any digit from 0 through 9. Taken together, the NPA-NXX code combination is used to route calls within the public switched telephone network to line numbers on specific switches.

The NPA-NXX also performs a second function, which is call rating. Each NPA-NXX is associated with a specific geographic area within an NPA to which are assigned horizontal and vertical coordinates. These coordinates are used to determine the distance of a call between geographic areas of the originating and terminating numbers. A group of NXXs that have the same coordinates form a rate center. Historically, the distance, length of call, and time of day have been used to determine the price of the call. Such rating is done in real-time on operator-assisted calls.

The NPA-NXX performs yet a third function. Historically, people could distinguish between local calls and toll calls they originate by looking in the front of their telephone books for the list of NXXs that defined their local calling area. When a call is originated by a subscriber who has presubscribed to an interexchange carrier for intraLATA toll calls, the originating switch uses the NPA-NXXs of the originating and terminating numbers to determine, in real-time, whether the call is to be routed by the local service provider (LSP) to the presubscribed interexchange carrier. This is commonly referred to as toll discrimination.


NXX-X/LRN relies on the Location Routing Number (LRN) used for LNP. The NXX-X/LRN proposal conserves NXX codes by sharing them across several LSPs serving the same rate center(s). All ten thousand numbers within each NXX continue to be assigned to one rate center, but are shared among multiple LSPs at the thousands-block (NXX-X) level. An example of this arrangement is shown below:

847-999-1XXX LSP-1

847-999-2XXX LSP-2

847-999-3XXX LSP-3


Therefore, LSP-1, LSP-2, LSP-3, etc., can each assign numbers from their designated thousands-block within the 847-999 NPA-NXX, but only to customers residing within the designated rate center.

Significantly, the 847-999 NXX shown in the example might still be assigned in its entirety to one switch entity/one LSP within the Bellcore Local Exchange Routing Guide (LERG). The assigned LSP would be referred to as the code holder. The code holder, however, would only be permitted to assign numbers within the particular thousands-block or blocks that have been allocated to it. Other LSPs (blockholders) can assign numbers in their designated thousands-blocks, but must treat the assigned numbers as ported, and must populate them in the NPAC Service Management System (SMS).


This report provides a recommendation on the feasibility of implementing a near-term number pooling solution based on the NXX-X/LRN proposal to relieve the 847 NPA exhaust within the Chicago metropolitan area, starting in January, 1998. The recommendation is based on information from telecommunications industry participants and stakeholders who are participating in LNP implementation in the Chicago area.

Number conservation is both a state and national issue which is being addressed by the North American Numbering Council (NANC) and other telecommunications industry policy and technical forums across the country. These forums are reviewing several long term number conservation methods, including number pooling. Their review includes pooling at the thousands-block and individual number levels, as well as expanding the scope of pooling to beyond the same exchange/rate center.

Their review may not be finalized in sufficient time to provide relief for either the 847 or other NPAs requiring near-term relief. Therefore, the number pooling solution referenced in this report (i.e., specifically for the 847 NPA) should be viewed as a near term step. It has been suggested, however, that this near term solution may be applied to other NPAs, in the Chicago area or other areas of the country, that are LNP-capable. It should be noted that this solution only provides potential relief for situations where the existing area code is approaching, but not yet at, total exhaust. It may also provide a framework for developing standards and requirements for longer term, nationally consistent number pooling solutions, as well as a migration path to reach that objective.

Operational Assumptions

The following operational assumptions need to be in place prior to the implementation of the NXX-X/LRN solution.

    1. Numbering Constraints
    1. Network Impacts
    2. The Illinois Number Pooling Subcommittee enlisted the help of several standing subcommittees of the Illinois Number Portability Workshop to assess the impact of this form of number pooling on various network components. Attention focused primarily on end offices, the regional SMS (NPAC), individual carrier SCPs, and 911 systems. The following are the results of those assessments.
      1. Regional NPAC/SMS
      2. The Workshop’s NPAC/SMS Subcommittee assessed the impacts of thousands-block pooling on the NPAC/SMS and associated administrative processes. Pooling itself is a numbering resource administration process that does not specifically involve the NPAC/SMS in performing number resource administration. In thousands-block pooling, a service provider may be assigned a thousands-block in an NXX for which they are not the LERG assignee. The NPAC/SMS would be used to port the numbers in that block into the block holder’s network to enable them to provide service to those numbers. Thousands-block pooling does not involve significantly new NPAC/SMS capabilities, since pooling utilizes existing LNP capabilities. The NPAC/SMS is used to port numbers assigned as a result of pooling, and not the administration of the number pooling resource itself.

        The NPAC/SMS Subcommittee identified a number of refinements to, and requirements for, the existing LNP process flows that would optimize the porting of pooled numbers and implement policy decisions related to the porting behavior of pooled numbers. The two policy issues are: at what point is a pooled number ported into the block holder’s network; and does a disconnected number snap back (port back into) the block holder’s network if that number had ported away into another provider’s network prior to being disconnected?

        To implement the refined process flows and pooling policy decisions requires enhancements to the NPAC/SMS software, which are currently slated for NANC release 2 development cycle. This release is scheduled for deployment on 2/21/98. To support pooling on 1/1/98 prior to this release, operations work-arounds would need to be implemented through methods and procedures to utilize existing NPAC/SMS functionality.

        Regarding the question of when a pooled number is to be ported, two options have been identified: pre-porting and porting-on-demand. In pre-porting, the entire thousands-block of numbers is ported into the block holder’s network subsequent to the block having been assigned, but prior to assigning or activating any of the numbers within that block. In porting-on-demand, the assigned block is left default-routed to the code holder’s network (i.e., not ported) until the block holder assigns and activates numbers within that block. As numbers are assigned to end users, the block holder ports those numbers into their network at that time.

        Regarding the question of disconnect treatment of a pooled number, the issue arises in the case of an active pooled number which subsequently ports away into another LSP’s network. If the number then subsequently disconnects, the question arises as to what happens to the number. Three options have been identified: 1) snap back to the block holder; 2) snap back to the code holder; and 3) no snap back. In snap back to the block holder, upon a disconnect processed at the NPAC by the last serving provider, the number is re-ported back into the block holder’s network where vacant treatment is provided until they re-assign the number. In snap back to the code holder’s network, upon a disconnect processed at the NPAC by the last serving provider, the number is un-ported to the code holder’s network, returning the number to default routing. The first of these snap back options leave the number within the assignment authority of the block holder regardless of where vacant number treatment is provided. The second option could leave assignment authority with either the code holder or the block holder.. In the no-snap back option, no disconnect is sent to the NPAC, causing the number to remain in the last serving provider’s network, where they provide vacant treatment and consider the number added to their inventory. This effectively transfers assignment authority of that number to the last serving provider’s network.

        Current NPAC/SMS functionality supports the porting of both individual numbers, as well as large blocks of numbers. Consequently, the baseline functionality exists to support either pre-porting or porting on demand. However, the current NANC process flows for porting numbers involve both old and new service providers due to the mutual coordination and provisioning activities that must occur between providers. These processes, for example, cause notifications to be sent to both old (code holder) and new (block holder) carriers’ SOAs for each number ported. Since numbers ported due to pooling will be unassigned or vacant when ported, these notifications are less relevant or unnecessary in this case. When porting blocks of pooled numbers, as in pre-porting, these notification messages (per number) can become burdensome to both the NPAC/SMS and SOAs. The NPAC/SMS Subcommittee has developed streamlined process flows and procedures for the porting of pooled numbers to minimize this overhead. These flows are a variation of the existing process flows and procedures for an intra-provider port (LISP), and therefore require NPAC development.

        The SCP subcommittee has identified concerns regarding SCP capacity resulting from the increased size of the LNP data base attributable to pooling (SCP capacity issues are addressed in Section 7.3). One SCP capacity management solution identified involves the use of bulk downloads from the NPAC/SMS to consolidate record storage by not populating individual TN records where the same routing information applies to a whole block or range of numbers. The porting of blocks of numbers at the NPAC is performed as an operation directed at a range of numbers. Upon activation of a block port, a bulk download operation is broadcasted to each subtending LSMS. The bulk download operation specifies a list of numbers included in the operation along with a single copy of the routing attributes to be used for the entire list of numbers. While the current bulk download operation in the NPAC/SMS interface, defined per the NANC IIS, is suitable to support this strategy, certain work-arounds must be implemented in the LSMS. To implement range/block records in the SCP currently requires the supporting LSMS to detect that a bulk download operation refers to a contiguous range of TNs as specified in the TN list. The LSMS would then forward the download to the SCP as a TN range instead of a TN list as is received from the NPAC/SMS. While the LNP data model in the NPAC/SMS and the SOA/LSMS requires that TN-related semantics are supported, the NPAC interfaces could be enhanced in the future to streamline the process of detecting and initiating range downloads to the SCPs, i.e., by supplementing the TN list with a TN range attribute if the TN list is a contiguous range.

        In addition, to identify TNs ported due to pooling activity, a new LNP-type indicator value will be supported. This LNP-type value (POOL) will be used to indicate that the pooling process flows will be utilized in lieu of the existing inter-provider porting flows (LSPP) or intra-provider flows (LISP). Also, this indicator could be used at the LSMS/SCP level to initiate block/range record consolidation for bulk downloads of pooled number blocks. The POOL LNP-type value will also be used to segregate NPAC/SMS activity for reporting purposes and to optionally allow the application of a different cost allocator model for the apportionment of NPAC costs resulting from pooling. It has been suggested that the incremental NPAC costs for porting pooled numbers may not be cost apportioned using the same allocator or apportionment basis as are used for service provider portability.

        Finally, changes to NPAC-LSMS interface to support either the pre-porting or port-on-demand methodology are also required. Since this interface has been developed to comply with national (NANC) guidelines, it is questionable whether modifications to accommodate a state-specific implementation would be prudent or acceptable. It is also uncertain whether all service providers' LSMSs could accommodate such interface changes by early or mid 1998.

      3. End Offices
      4. The impacts of number pooling at the thousands-block level on end office requirements and administration were assessed by the Workshop’s Switch Requirements Subcommittee. The Subcommittee concluded that pooling imposed no additional development on end office switches beyond those required for the implementation of LNP. They also concluded that pooling did not generally impose significant memory or processing capacity demands on those switches.

        The requirements for administration of numbers allocated to the block holder’s switch were also discussed. Treatment of numbers was found to vary, depending upon whether numbers in blocks allocated to LSPs other than the NXX assignee are immediately placed in the NPAC and downloaded to LSP databases (i.e., pre-ported), or transmitted a single number at a time, as they are actually assigned to customers (i.e., port-on-demand).

        Under pre-porting, numbers are routed to the block holder’s switch as soon as the thousands-block is allocated. The block holder must ensure that LRN-routed calls to numbers within that thousands-block that are not yet assigned are provided vacant-number treatment (as opposed to unallocated number treatment), to prevent an error notification message (i.e., release cause code 26) being returned to the originating or intermediate network. Similarly, if a number within that allocated thousands-block is subsequently ported away from the block holder’s switch, the LSP must ensure that the error notification message is returned to the originating or intermediate network on LRN-routed calls. If that number is subsequently returned to the block holder (e.g., disconnect with snap-back to the block holder), the LSP must again provide vacant number treatment. All three scenarios require specific translations activity within the block holder’s switch, which would not be required if port-on-demand is employed. Within the Subcommittee, opinions differed as to how burdensome this requirement would be. Additional software enhancements to perform such vacant number treatment in a mechanized manner may be desirable.

      5. SCPs
      6. The Workshop SCP Requirements Subcommittee studied the NXX-X/LRN proposal from the perspective of record capacity, downloads and potential changes to the Requirements document. Regarding record storage capacity, they expressed serious concern that if each pooled number was to be represented by an individual entry in the data base(s), then the record storage capacity of many provider’s networks may quickly be exceeded . If this solution were applied to multiple NPAs within the state, region or nation-wide, the required capacity would eventually exceed tens of millions of records. This would apply to records for both LNP records and Global Title Translations (GTTs).

        To alleviate this concern, the Subcommittee has suggested that enhancements be developed, so that pooled numbers could be populated within the appropriate data bases in ranges, rather than individual numbers. This would most easily be accomplished if the NPAC download was also transmitted in ranges, which included a unique identifier for those that contained "pooled" numbers. Other methods of aggregating the data were discussed, but most required additional (and perhaps costly) functionality in each service provider’s LSMS.

        The group also discussed alternate methodologies for representing those pooled ranges within the data base(s). The first followed a structure similar to that employed for individual number records - i.e., one table containing sequential entries, with some entries covering a range of numbers. It was noted that a capability to disaggregate and reaggregate those ranges would be required as the pooling and porting characteristics changed within a given NXX.

        The second method was to establish a two-table, two-step approach. A look-up would first be performed within the individual (ported) number table. If no entry was found within, a search of a (pooled) range table would then be performed. It is believed that this approach would avoid the need for continuous disaggregation and reaggregation as numbers changed.

        Storing pooled numbers in ranges will require enhancements to the data bases and their interfaces. Proposed changes to the common NPAC interface must be approved and accommodated by each interconnecting service provider within its network. Changes within the data bases themselves may take additional time. Until all such changes are completed, record storage capacity will remain a critical issue, especially if pre-porting is employed to implement number pooling at the thousands-block level. Furthermore, accurate forecasts of the amount of pooled thousands-blocks required by each LSP is needed to properly size data base capacities. Increasing such capacities may require the deployment of additional hardware and software, which reinforces the need to have accurate and timely forecasts with sufficient lead time to implement such changes.

        Increased volumes of record transactions due to pooling was also identified as a concern. If such transactions are transmitted via individual number records, delays and congestion may occur during busy periods. The Subcommittee felt that such records should either be transmitted in ranges, off-hours, or somehow afforded a lower priority in transmission scheduling. It was suggested that pre-porting might help alleviate this concern, because large blocks of numbers could be downloaded off-hours.

        In summary, the SCP Subcommittee identified the need to: 1) separately identify pooled versus Service Provider Number Portability (SPNP)-ported numbers; 2) load the associated data base records in ranges rather than individual numbers; 3) download such information in non-busy hour periods; and 4) maintain accurate forecasts of demand as critical path items to the deployment of number pooling. It was acknowledged that all of these needs cannot be met by January, 1998 and as such, there is serious concern whether pooling should proceed as planned, beginning on 1/1/98..

      7. 911 Systems

      The impact of number pooling at the thousands-block level was assessed by the 911 Subcommittee of the Workshop. They identified no substantial impacts beyond those already planned to implement LNP as defined in the National Emergency Number Association (NENA). They instead focused on the desire to identify the thousands-block assignee within the MS and Selective Router/Address Location Identifier (SR/ALI) data bases, to ensure prompt resolution of trouble reports suspected to be caused by incomplete or inaccurate routing information. Subcommittee members felt that this capability was not an absolute necessity and could be added at a later time.

    3. Operational Impacts
    4. The Number Pooling Subcommittee also requested several Illinois Number Portability Workshop subcommittees to assess the impact of number pooling on the operating systems and processes that were established or modified to support number portability. The following is a summary of those assessments.
      1. Rating and Billing
      1. Alternate Billing
      2. Bell Communications Research (Bellcore) was asked to perform a cursory analysis of the potential impacts of number pooling on the LIDBs (Line Information DataBases), which are used to perform various alternate billing services, such as credit card and bill-to-third-number authorization. The results of that analysis follows.

        The LIDB currently contains data stored at the NPA-NNX level (i.e., on a 6-digit basis) that is used in processing Alternate Billing Service (ABS) calls, including both Calling Card service and Billed Number Screening (BNS) services. The administrative support systems (AS/LIDB) that administer and update the LIDB data also store and update data based on NPA-NXX. This data includes, but is not limited to, information such as processing indicators that describe processing capabilities of the entire 10,000 number range, a mapped NPA-NXX table, and data such as Revenue Accounting Office (RAO) and account owner that are provided as default values for the entire NPA-NXX. Although LNP will require that LIDB be able to maintain data for individual line numbers, there are no plans to eliminate the NPA-NXX level information. Changes may be needed to both LIDB and the various administrative supports systems to allow for data to be stored at a 7-digit level (i.e., NPA-NXX-X) rather than at the current NPA-NXX. These changes are not anticipated to adversely impact the implementation of number pooling.

        LIDB validation of unassigned numbers may become an issue if the port-on-demand methodology is employed for number pooling. Since validation attempts on unassigned numbers will be default-routed to the code holder's LIDB (or LIDB services provider), rather than the block holder's, a concern has been expressed regarding liability for uncollectable billing.

      3. Operator Assistance/Directory Assistance
      4. Bellcore was also asked to perform a cursory analysis of the impacts of number pooling on Operator Services (OS) and Directory Assistance (DA). The results of this analysis follows.

        Since the NXX-X/LRN makes use of the Operator Services System (OS) LNP implementation, the additional impacts on the OS to support number pooling for operator assistance and directory assistance are expected to be minimal. Because of the use of the LRN, the OS core system (i.e., the system which routes the calls), in particular, need not be upgraded to support 7 digit rating or routing. Instead, similar to LNP, the rating is expected to be based on the NPA-NXX of the dialed digits and the routing is expected to be based on the NPA-NXX of the LRN.

        It is possible, however, that external databases used for operator assistance and directory assistance, such as the listing services databases, may require NPA-NXX-X processing rather than NPA-NXX processing. For example, it may be appropriate to define default localities based on 7 digits rather than 6 digits. Further study is needed to identify all the specific aspects of the external databases that would likely be impacted.

      5. Process Flows
      1. Provisioning and Support Systems
      2. Individual LSPs participating in number pooling need to identify and assess the actual impact of the NXX-X/LRN proposal on their provisioning and support systems. LEC systems potentially affected include those used for numbering resource management, number assignment, service order provisioning, switch attributes/features management, and translations activity management. Modifications already underway to support LNP may require further augmentation to uniquely identify "pooled" numbers (e.g., for snap-back, tracking and accounting), to block out re-allocated thousands-blocks, and to import partial NXXs. Several LSPs expressed concerns with assigning numbers from allocated thousands-blocks, if the port-on-demand methodology is employed. The need to separately identify and import any number assigned from an allocated thousands-block is considered by a number of LSPs to be extremely burdensome, and a detriment to moving forward with number pooling, if this methodology is chosen.

        In addition, changes to the Bellcore Local Exchange Routing Guide (LERG), to reflect ownership at the thousands-block level, is considered by many LSPs to be essential or highly desirable. New requirements for the LERG are being considered by the National Rating and Routing Industry Committee (NRRIC) for submission by September, in order to meet a first or second quarter ’98 deployment window.

      3. Limited Liability Corporation
    1. Number Administration
    1. Cost Allocation and Recovery
    2. Allocation and recovery mechanisms need to be established for costs associated with this form of number pooling. Such costs may include shared costs, such as NPAC modifications, record processing, and number administration, as well as other service provider-specific costs, such as OSS modifications. A fundamental question that has been raised regarding shared costs is whether they should be allocated among only those LSPs participating in the deployment of number portability, or borne by all LSPs using numbering resources from the 847 NPA. Given the current lack of consensus on a methodology for allocating LNP costs, it is doubtful that LSPs in Illinois will agree on an equitable and fair means of distributing pooling costs. Therefore, for number pooling cost allocation and recovery, the Illinois Commerce Commission must provide direction.
    3. Conclusions and Recommendation