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
11. Conclusions and Recommendation
1. Executive Overview
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:
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 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.
To determine number utilization within 847, the Illinois Commerce Commission Staff forwarded a data request to all carriers 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 within. These blocks resided within 43 of the 46 rate centers served by the 847 NPA. The above results were only for codes assigned to wireline carriers.
To compare this spare capacity with the anticipated future demand for new by thousands-blocks, a request for new forecasts was requested 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 by next January 1, 1998. 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 total of 10 exchanges were excluded from 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 ??(years/months). This estimate is based upon the assumption that ???% of the current spare capacity (e.g., thousands-blocks) will still be available for sharing among LNP-equipped exchanges on 1/1/98, and that approximately 98 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. Therefore, it is recommended that code relief planning continue.
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 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 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 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. 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 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 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.
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., 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 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 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.
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.
The Subcommittee members have determined that the NXX-X/LRN number pooling proposal should have no new technical impacts on deploying LNP in Illinois, based upon the above assumptions. In addition, there does not appear to be any additional costs to implement number pooling except for back-office system modifications as discussed above.
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.
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, 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.