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
3. Description of NXX-X/LRN
5. Operational Assumptions
6. Numbering Constraints
7. Network Impacts
7.1. Regional NPAC/SMS
7.2. End Offices
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
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:
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.
The following operational assumptions need to be in place prior to the implementation of the NXX-X/LRN solution.
To determine number utilization within 847, the Illinois Commerce Commission Staff forwarded a data request to all LSPs on May 8, 1997, requesting them to report the amount of spare capacity on their 847 NXXs by May 30, 1997. The results of that survey indicated that there were 671 thousands-blocks that were totally spare, and an additional 185 thousands-blocks with 10 or less working numbers. These blocks resided within 38 of the 42 wireline rate centers served by the 847 NPA. The above results were only for codes assigned to wireline carriers.
Absent an existing requirement to limit number assignments within working NXXs, a voluntary effort was needed to begin conserving numbers. The 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. As of the date of this report, commitments were made to restrict assignment within 543 currently vacant blocks, and to offer up 348 as pooling candidates. In addition, LSPs will restrict assignment within 330 blocks that have some working numbers, and to offer 182 of those blocks as pooling candidates. LSPs will be asked to report such availability on a monthly basis, until number pooling is implemented, at which time those blocks will be returned to the pooling administrator. It is recommended that this monitoring mechanism be applied to all users of NPA 847 numbering resources. It is anticipated that those blocks which are entirely vacant will be the first to be allocated by the pooling administrator.
To compare this spare capacity with the anticipated future demand for new thousands-blocks, a request for new forecasts was forwarded by Wallace Data Comp to all 847 NXX code holders on July 11th. LSPs were requested to report the number of additional thousands-blocks, by rate center, they would require to service new customers over the next two years. A compilation of the results of this forecast request provided new demand data in the level of specificity needed to complete the comparison.
The unavailability of the supporting number portability technology in certain networks and switches has been factored into this comparison. In the FCC order on number portability (CC Docket 95-116), Cellular and PCS carriers were not required to deploy LNP until June 30, 1999. Additionally, paging companies were excluded entirely from the requirement to deploy LNP. As such, wireless carriers will not be able to participate in thousands-block sharing until they are LNP-capable. Similarly, the FCC Reconsideration Order on Docket 95-116 limited wireline service providers obligation to deploy LNP to only those exchanges where there was an expressed interest from competing carriers. Within the 847 boundary, a few exchanges were not included on the switch selection lists submitted by all service providers requesting number portability. These exchanges cannot be allocated blocks of numbers from other NXXs.
The final thousands-block comparison of forecasted demand, with availability, suggests that number pooling at this level may extend the exhaust date of NPA 847 by 6 to 12 months. This estimate is based upon the assumption that approximately 100 spare NXXs will still be available to serve the needs of non-LNP capable networks and exchanges. The projection for exhaust hinges heavily upon the accuracy of the LSP forecasts. Unanticipated demand from existing or new LSPs could significantly impact this estimate. Number pooling does not eliminate the need for continued code relief planning.
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 holders network; and does a disconnected number snap back (port back into) the block holders network if that number had ported away into another providers 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 holders 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 holders 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 LSPs 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 holders network where vacant treatment is provided until they re-assign the number. In snap back to the code holders network, upon a disconnect processed at the NPAC by the last serving provider, the number is un-ported to the code holders 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 providers 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 providers 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.
The requirements for administration of numbers allocated to the block holders 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 holders 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 holders 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 holders 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.
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 providers 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..
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.
The Subcommittee members have determined that the NXX-X/LRN number pooling proposal should have no new technical impacts on deploying LNP in Illinois. In addition, there do not appear to be any additional rating or billing costs to implement number pooling, except for back-office system modifications as discussed above.
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.
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.
The minimum set of process flows required to support pre-porting include the following:
In summary, consensus on the manner in which number pooling will be implemented within Illinois is needed to identify and execute the required changes to current operational flows and processes. Parties agreed that pre-porting with snap-back to the block holder is a workable solution, if the SCP capacity concerns could be addressed. As of this writing it is uncertain whether a resolution will be available in sufficient time to implement number pooling in order to extend the life of the 847 NPA.
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.
Allocation of the costs for number pooling will be addressed in a separate section of this report. LLC membership identified a need to separately track such costs, so that alternative allocation and recovery methods could be explored.
In addition, there is a short-term need to monitor the status of those thousands-blocks within assigned NXXs that are considered pooling candidates. Also, there is a need to ensure restricted assignment within any new NXXs allocated between now and the actual start of number pooling. It is recommended that a monitoring mechanism be put in place to accommodate these needs.
Therefore, the Subcommittee recommends that the actual implementation of number pooling in Illinois be deferred until resolutions to the above-mentioned concerns, especially the capacity concern, are identified and available. The Subcommittee believes that number pooling can and will be implemented in Illinois sometime in 1998. Although the analysis of the forecast suggests that number pooling will not extend the exhaust date of the 847 area code beyond 2Q99, the Subcommittee will continue its efforts towards implementing number pooling in the 847 area code. Specific work efforts will include defining responsibilities for, and identifying an interim Pooling Administrator, defining NPAC requirements, addressing the capacity issue, developing a new set of administrative guidelines, and defining methods and procedures for activating pooled numbers.