SUBJECT: DRAFT OF POOLING IMPACTS NOTE
FROM: WAYNE HEINMILLER 847-248-5415 wayne.heinmiller@ameritech.com
Attached is a draft of the number pooling impact note I propose to provide to the Pooling Subcommittee. In addition to the items we discussed over the past couple of calls (no changes necessary to requirements, possible impacts of increased database size, possible impacts of increased download rates), it occurred to me we should raise the issue of whether the existing number assignment procedures (NXX) allow enough lead time for engineering or reconfiguring to handle more database entries. So I've also included that as an issue for your review in the draft note. We'll discuss this note at our conference call on Tuesday morning (7/29).
Also, Walt Subora has just distributed to the testing subcommittee a set of SCP test descriptions that were used in Ameritech's lab to test our platform. It is many pages, and I will distribute it over the weekend. You may find it of interest.
Content-Type: message/rfc822
Date: Fri, 25 Jul 1997 11:15:05 -0500
From: "WAYNE HEINMILLER " <>
Subject: Pooling Note
Date: (7/24/97 - DRAFT)
To: Brian Baldwin, Co-Chair, Midwest Number Pooling Subcommittee
From: Wayne Heinmiller, Chair, Midwest LNP SCP Requirements
Subcommittee
Subject: Number Pooling Impacts
Per your subcommittee's request, the LNP SCP Requirements Subcommittee has considered the impact of "number pooling" on our areas of responsibility. We are responding using your suggested format.
We discussed the possible impacts on our requirements document, which specifies the requirements for both the LRN Query Application and the LNP GTT Function. We also considered generally any impacts number pooling might have on SCP, STP, or the SS7 signaling network.
2) What assumptions were made?
- We assumed pooling would be employed in geographic areas where LNP has already been deployed.
- We assumed LRN queries would already be performed for LNP purposes. (No significant number of additional queries would be needed only for number pooling purposes.)
- We assumed no changes to the switch or NPAC functionality. (Changes in either of these areas might generate changes in the SCP/STP/SS7 areas.)
- We assumed triggers would be assigned in the switch on a 6 digit basis (NPA-NXX) as for LNP.
- We assumed pooled numbers would enter the database in one of two ways. In the first way, all the numbers in the thousands block would be entered into the NPAC database for download when the block is assigned to a carrier. In the second way, individual numbers within a thousands block are entered into the NPAC database only when a number is placed in use for an end user.
- We assumed pooling would occur in blocks of one thousand numbers.
3) What concerns were identified?
4) What alternatives were looked at?
5) What were the advantages/disadvantages of those alternatives?
6) What conclusions/recommendations were made?
Each of these is addressed individually within each of the four concerns identified by the subcommittee.
Concern #1: Are any changes to our requirements document necessary to support pooling?
Discussion: Assuming the NPAC interface and functionality, the switch functionality, and operations needs remain as defined for LNP, we could identify no changes to our requirements document to support number pooling.
Conclusion: No action is required at this time to support pooling with respect to the SCP/GTT requirements document.
Concern #2: What impacts might occur as a result of larger database sizes to support pooled numbers
Discussion: Increased number of DN entries can exhaust LRN and GTT database capacity. Increased sizes of LRN and GTT databases can result in throughput reductions or additional delay in processing LRN queries and performing LNP GTTs. If this is not addressed, calls will be routed inefficiently, or will fail.
Alternatives: One alternative is to add hardware for greater storage, and add processing capacity (or upgrade processing capacity) to allow larger databases without decreases in performance. Another alternative is to install additional databases, and partition data among them such that database size on each platform remains small enough so that performance is not affected. A third alternative would be to change the database implementation (add a thousands block LRN query default table, and change the GTT Function default table from NPA-NXX to NPA-NXX-X) so that pooled numbers do not require an entry for each pooled DN.
Advantages/Disadvantages: The pros and cons of each alternative is closely tied to each provider's architecture and each vendor's implementation. The alternative of changing the database structure could be tied to whether the NPAC interface is modified to download pooled numbers as a range, and whether the interface is modified to indicate whether a record represent portability or pooling.
Recommendation: This may not be an immediate concern for the first pooling deployment. As additional pooling areas (NPAs) are established, it could quickly become a concern. The NPAC Subcommittee should consider modifying the interface specification to support download of pooled number blocks as a single record, and including an explicit indication of whether the record represents pooling or portability. This allows a more efficient implementation of the SCP/GTT database, and may also resolve the interface download issue. (A conversion process should also be considered.) Other alternatives (platform growth, deployment of additional platforms) are implementation choices which should be left to vendors and providers to evaluate.
Concern #3: What are the impacts of greater volumes of NPAC downloads?
Discussion: Interfaces were designed to handle download volume to support portability. Increased download volumes could create delays in making portability effective for a given customer.
Alternatives: Alternatives in this case assume that records for pooling may not represent live end users, and may therefore not need to be handled with the same priority as ported records. One alternative would be to queue pooling records at a lower priority at the NPAC. (Portability records would always be downloaded before pooling records.) Another alternative would limit pooling downloads to "off-hour" periods. Yet another alternative might modify the NPAC interface to allow an entire thousands block to be transmitted in a single record. A final alternative would be to use a method other than the NPAC interface (tape, disk, etc. ) to distribute records for pooled numbers.
Advantages/Disadvantages: The pros and cons are generally beyond the ability of this subcommittee to evaluate. We would like to point out that a modification that supported downloading a thousand number block range as a single record might allow more efficient database implementations for SCP/GTT databases.
Recommendation: The NPAC Subcommittee should investigate ways to address increased volumes of downloads across the NPAC interface.
Concern #4: How do we obtain forecasts for pooled number blocks?
Discussion: LNP platforms will need to be engineered to support pooling (increased database size, increased download volume, etc.).
Engineering for pooling will driven by the volume of number block requests made by carriers. In order to obtain and install necessary capacity, these forecasts may be needed 6 - 12 months before the blocks are assigned. (Assignment of numbers by NXX does not have the capacity impact created by pooling, so forecasts were not previously a serious issue.) Without accurate forecasts sufficiently in advance, some networks may not be ready to support additional porting/pooling.
Alternatives: One alternative is to not forecast number assignments (i.e., begin engineering when a number block is assigned). Another is for each provider to announce forecasts in advance. A third is for providers to give forecasts to a third party (local number administrator), who provides an aggregate forecast back to the industry.
Advantages/Disadvantages: If there are no forecasts, then possibility that database size could exceed carrier capacity during rapid number block assignment increases. If one carrier's capacity is exceeded, that might result in a temporary hold in the ability to port customers or place newly assigned number blocks into service. The disadvantage of a forecasting method is that over forecasting causes carriers to purchase/reconfigure hardware that would not yet be necessary. The disadvantage of under forecasting is that the effects might be the same as no forecasting. Recommendation: The numbering administrator should review numbering assignment procedures to determine whether the current process (designed for NXX assignments) provides sufficient engineering lead time when numbering resources are assigned by thousands block.
Summary
We did not identify any action required by the subcommittee to change our requirements at this time. Number pooling can have impacts as a result of larger databases and more downloaded records from the NPAC. Some of these impacts might be addressed by changes to the NPAC interface. There is also an issue about engineering lead time to accommodate pooled number blocks. The number administrator show review whether current numbering block assignment processes provide adequate lead time for database capacity engineering.