Table of Contents






1. Executive Overview

2. Background

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 the situation. The initial focus of attention had been towards implementing either an NPA split or an NPA overlay. An NPA split would reduce the area of coverage for the 847 area code, and introduces a new NPA code to serve the vacated portion. The latter would introduce a second area code within the 847 NPA boundaries, to serve all new customers of telecommunications services once 847 was at total exhaust.


It is acknowledged that in a multiple NPA environment, each subsequent split diminishes the actual area of relief, and leaves unaddressed similar conditions in adjacent areas. NPA overlays offer the potential for wider areas of relief, but 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. Initially, the designated geographic area is limited to an existing rate center (area) within a geographic NPA. The numbering resource in the shared reservoir would be available, potentially, in blocks of numbers or on an individual number basis for assignment to competing service providers participating in local number portability for the purpose of providing services to customers in that area.

Based upon an AT&T proposal under study within several industry forums, this alternative would allow individual carriers serving the same rate center area to be allocated blocks of 1000 numbers from the 10000 available 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 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 The Workshop subcommittees on this issue.

3. 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 within the public switched telephone network to line numbers on a specific switch.


The NPA-NXX also performs a second function. 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. People can distinguish between local calls and toll calls they originate by looking in the front of their telephone books for the list of NXXs that defines 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 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. This dependence removes the routing complications that were inherent in the original switch-based NXX-X proposal (without LRN). 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).

4. Scope


This report provides a recommendation on 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 telecom industry participants and stakeholders who are participating in LNP implementation in the Chicago area.


Number conservation is a national issue which is being addressed by the North American Numbering Council (NANC) and other telecom industry policy and technical forums on a national basis. 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 exchange/rate center.


The 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 should be viewed as an near term step. It has been suggested, however, that this near term solution may be applied to other NPAs, in the Chicago area or elsewhere, where LNP is being deployed and the existing area code is approaching, but not yet at, total exhaust. This solution may also provide a framework for developing standards and requirements for long term, nationally consistent number pooling solutions, as well as a migration path to reach that objective.

5. Operational Assumptions


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


  1. Numbering Constraints
  1. Network Impacts
      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 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 will 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: preporting and porting-on-demand. In preporting, 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. Both of these snap back options leave the number within the assignment authority of the block holder, regardless of where vacant number treatment is provided. 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 preporting, these notification messages (per number) can become burdensome to both the NPAC/SMS and the SOAs. The NPAC/SMS Subcommittee has developed streamlined process flows for the porting of pooled numbers to minimize this overhead. These flows are a variation of the existing process flows for an intra-provider port (LISP).

        The SCP subcommittee has identified concerns regarding SCP capacity resulting from the increased size of the LNP data base attributable to pooling. 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.

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

      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., preported), or transmitted a single number at a time, as they are actually assigned to customers (i.e., activate on demand).

        Under preporting, 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 activate-on-demand is employed. Within the Subcommittee, opinions differed as to how burdensome this requirement would be. At least one switch vendor has suggested the need for additional software enhancements to perform such vacant number treatment in a mechanized manner.

      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 the first issue, they expressed serious concern that if each pooled number was to be represented by an individual entry in the data base(s), the record storage capacity of many provider’s networks would soon 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 queries and Global Title Translations (GTTs).

        To alleviate this concern, the Subcommittee has suggested that pooled numbers 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, and 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 at the 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 within a given NXX changed.

        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.

        It is recognized that storing pooled numbers in ranges will require additional 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 before they can be implemented. Changes within the data bases themselves may take additional time. Until all such changes are completed, record capacity will remain a critical issue, especially if preporting 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 in sufficient lead time to implement such changes.

        Increased volumes of downloaded records due to pooling was also identified as a concern. If such downloads 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 preporting might help alleviate this concern, because large blocks of numbers could be downloaded off-hours.

        In summary, the SCP Subcommittee identified the need to separately identify pooled versus SPNP-ported numbers, load the associated data base records in ranges rather than individual numbers, download such information in non-busy hour periods, and maintain accurate forecasts of demand as critical path items to the deployment of number pooling. It was acknowledged, however, that all of these needs cannot be met by January, 1998 and as such, some work-arounds will need to be supported.

      7. 911 Systems
  1. Operational Impacts
      1. Rating and Billing
      1. Alternate Billing
      2. (To be supplied by Herb Manger)
      3. Operator Assistance/Directory Assistance
      4. (To be supplied by Herb Manger)
      5. Process Flows
      6. (To be supplied by Brent Struthers)
      7. Provisioning and Support Systems
      8. Individual LSPs participating in number pooling need to identify and assess the actual impact of the NXX-X/LRN proposal on their legacy provisioning and support systems. Incumbent 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 tracking and snap-back), 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 individual number porting methodology is employed. The need to separately identify and import any number assigned from an allocated thousands-block is considered by many to be extremely burdensome.

        In addition, changes to the Bellcore Local Exchange Routing Guide (LERG), to reflect ownership at the thousands-block level, is considered by many to be essential or highly desirable. New requirements for the LERG must be submitted in September, in order to meet a first or second quarter ’98 deployment window.

      9. Limited Liability Corporation
  1. Number Administration
  2. In today’s environment, the dominant LEC, Ameritech, provides the NXX code administration for the entire state. In a new pooled environment, careful administration and assignment of pooled numbers is absolutely essential to ensure maximum utilization of the resource. Within Illinois, several carriers have expressed their opposition to allowing the current Code Administrator may need to be identified. Therefore, in a pooled environment, an interim thousands-block administrator may be identified to serve in this capacity until the North American Numbering Council (NANC) can decide who has permanent jurisdiction. The entity which assumes this responsibility would need to establish a tracking and reporting process, and be provided with a new set of guidelines to administer this resource. The Number Pooling Subcommittee will work towards the establishment of such guidelines, using the Industry Numbering Committee Code Assignment Guidelines as a source document. In addition, the Subcommittee will explore the feasibility of appointing Lockheed-Martin as the interim pooling administrator.

    In addition, there is a short-term need to monitor the status of those thousands-blocks within assigned NXXs that are considered pooling candidates, as well as to ensure restricted assignment within any new NXXs allocated between now and the actual start of number pooling. ICC Staff forwarded a second data request on July 10th, which asked all carriers to identify and restrict assignment within thousands-blocks currently containing 50 or less working numbers. LSPs will be asked to report such availability on a monthly basis, between now and January 1. It is recommended that this monitoring mechanism be applied to all users of NPA 847 numbering resources.

  3. Cost Allocation and Recovery
  4. Allocation and recovery mechanisms need to be established for costs associated with this form of number pooling. Such costs include shared costs, such as NPAC modifications, record processing, and number administration, as well as any carrier-specific costs that are incurred, such as OSS modifications. A fundamental question that has been raised regarding shared costs is whether they should be allocated among only those carriers participating in the deployment of number portability, or borne by all carriers using numbering resources from the 847 NPA. Given the current lack of consensus on a methodology for allocating LNP costs, it is doubtful that participants will agree on an equitable and fair means of distributing pooling costs. As such, the Illinois Commerce Commission must provide direction in this matter.
  5. Conclusions and Recommendation