This is a reminder that our next conference call will be August 12
(Tuesday) at 1:30 pm CDT. The call in number is 800-836-XXXX, passcode XXXXXX.
We will begin with further discussion on number pooling, based on the results of yesterdays (8/6) cross-subcommittee meeting.
I’ll try to summarize the ideas discussed at the meeting, and the information our subcommittee is being asked to provide.
The release of NPAC software planned for 2/20/98 could provide fixes to problems with the process flows. It could also add a "pooling" indicator to the protocol for the NPAC interface to the Local SMS systems. (The interface specification already supports ranges up to a full NXX, but it is not clear how well this is supported by all vendors.) The NPAC subcommittee refers to the six week period between 1/1/98 and 2/20/98 as the "interim" pooling period.
There was a discussion about how to "evolve" the NPAC interfaces without requiring coordinated "flash cuts" by all carriers. It is expected the 2/20/98 NPAC release will not present a problem, because it is expected the interface changes would be transparent to LSMS that remain on the previous version. That would allow LSMS vendors (and carriers) to upgrade their products independently following the availability of the new NPAC interface.
It seemed the concern about database capacity was common among all carriers and vendors. There seemed to be consensus that for long term deployment of pooling, it would be required to have an architecture and structure that allowed efficient network database implementations. There seemed to be agreement that pooling could not be supported long term if pooled numbers needed to be represented individually in network databases. There was also recognition that any Illinois solution had to be acceptable on a national basis. (There was some disagreement on whether we should wait for a national forum to address pooling policies and architectures.)
From our subcommittee discussions, it is clear that it is unlikely that the actual network databases residing in the SCPs and/or STPs can be revised during the first half of 1998. If the new "model" for data clarifies quickly, there still needs to be time for vendors to perform development, test changes to their products, and develop conversion processes. Carriers will also want time to test, integrate and deploy any revisions to network databases (SCPs or STPs). From the feedback I have received, that means best case to expect revised network databases is the second half of 1998 (probably later rather than sooner). It is expected the LSMS will be able to allow NPAC interfaces and network database structures to be revised independently (NPAC interface first, of course). This means a carrier could convert their network databases to more efficient structures any time after they have converted their NPAC interface.
We then turned to discussions of "pre-porting" versus "port on demand" for pooled numbers. For "pre-porting", the carrier submits all thousand numbers in the assigned range to the NPAC for pooling prior to placing any numbers in service. For "port on demand", the carrier submits records to the NPAC only as they are assigned to working customers. Prior to efficient network database implementations, "pre-porting" could have capacity implications. We then had disucssion about the magnitude of the capacity impact of pre-porting prior toe efficient network database implications. For "port on demand", there are operational impacts. (Different provisioning processes for pooled blocks versus owned NXXs; NXX holder performs LIDB validation for vacant pooled numbers; NXX holder provides vacant treatment for misdialed calls, etc.) Of participants present, general opinion was in support of "pre-porting", but this may not represent a national opinion. There was some opinion (which I share) that the "pre-port" versus "port on demand" debate becomes moot in the long run with efficient network database structures based on ranges.
There was also discussion about how to address "disconnects" for pooled numbers, or for numbers that have ported from the pooled carrier. The question was whether such numbers should "snapback" to the code holder (NXX level) or the block holder (thousands block level). Long term architectures will support snapback to block holder. Prior to that capability, question is how to address the issue. Snapback to NXX holder is easiest (delete DN record from NPAC). But this appraoch results in subsequent assignment challenges and operational issues. Prior to NPAC changes, to snapback to the block holder requires a new record be provided to the NPAC when the porting record is deleted. (Again, I think this question becomes moot following revised architectures.)
I don’t think we had enough discussion to know if we can truly move from the "interim" pooling (1/1/98) to NPAC revisions (2/20/98) to network database structure revisions (end of 1998) as simply as everyone expects. I also need to have some follow up with the NPAC subcommittee to understand how they are doing ranges begining 2/20/98. (We’ll have some discussion of different ways to handle ranges on our 8/12 conference call.)
The schedule to address the pooling issue is to have a multi-subcommittee call at the beginning of the ICC LNP Coordination Committee conference call (Thursday, 8/14, 9am CDT, call in number 312-814-8097. Please work with others in your company to share ports if you want to call in because this bridge only has 30 ports.) The Illinois Commission will be having NPA split hearing on 8/14 and 8/15. The full ICC LNP coordination committee meeting is Thursday 8/21, when pooling is again expected to be a topic. The goal is to wrap up "interim" issues, and any identified post 2/20/98 issues by 9/1.
As a result of yesterday’s meeting, there are some questions we need to address on our 8/12 call (if possible) so we can report to the other committees on the 8/14 call. They are:
Can the network databases be evolved independently once the NPAC interface and processes are revised?
Is it a good estimate to expect that carriers might have to use current network database implementations for all of 1998?
If carriers use current implementations, does the addition of 10M records in network databases to support pooling for all of 1998 have any significant impact, assuming revised database implementations around the end of 1998 allow recovery of most of that capacity for portability growth? (Assumption was 40 NPAs nationally might adopt pooling during 1998, and for each NPA there might be 240 blocks of a thousand numbers assigned.)
If the deisred implementation is "pre-porting" and "snapback to the block holder", and that is how the long term implementation is performed, how much impact is there for your (company, product, operations) if the interim alternative is "port on demand" and "snapback to NXX holder"?