Date: Fri, 8 Aug 1997 21:56:12 -0500
Subject: RE: Midwest LNP SCP Call Reminder & Pooling Info
To: "'WAYNE HEINMILLER'" <>
I'd like to provide some additional information on the status of range
downloads from the NPAC. The range download operation the NPAC SMS
supports today is part of the mandatory functionality that all LSMSs and
SOAs must demonstrate in order to obtain their IIS interoperability
certification with the NPAC. So, all of the LSMSs must provide this
functionality today. Their ability to forward range-operations downstream
to the SCPs is the obvious next question.
If not, the problem may be that most of the LSMS vendors developed their
local database around TN-level records, and so currently have no way to
maintain range-level semantics downstream. Once the download is received
at the LSMS, if it populates individual TN records and queues them up for
download, then they'll appear to the SCPs as individual records.
In any case, the NPAC/SMS subcommittee is not planning on changing the
range download operation in release 2, other than to add a new code point
for the LNP-type indicator which is currently in the downloaded record.
There are currently two values, LSSP (normal service provider port), and
LISP (intra-provider port, AKA location port). For pooling, we'll add a
third value, POOL to indicate the port is for a pooled number.
Consequently, LSMS/SCP vendors could start today developing the necessary
enhancements to support a two-level record scheme, which could be
introduced with or without pooling independent of the release 2 cycle. It
is my understanding that the LSMS/SCP currently ignores the LNP-type field,
since the record contents and processing for both types are otherwise
identical. Other than capacity concerns, I'm under the impression that no
additional LSMS/SCP functionality is absolutely required to commence
pooling. Consequently, there should be minimal problems with the
previously scheduled NANC release 2 deployment activities on 2/20/98.
It would be useful if you could socialize this with the SCP subcommittee.
It would also be worthwhile understanding when this capability could start
to be introduced by the vendors. At that time, it would seem that
pre-porting would be essential in order to obtain range-records from the
NPAC for use in the LSMS/SCPs using the two-table lookup scheme. The
compatibility of pre-porting vs. on-demand with the long-term SCP capacity
strategy should be injected into the policy debate.
Mark D. Foster | email@example.com
MDF Associates | Tel: +1(703) 404-2258
Telecoms Consulting | Fax: +1(703) 404-2591