TO: MIDWEST LNP SCP REQUIREMENTS SUBCOMMITTEE
SUBJECT: CONFERENCE CALL NOTES FROM TUESDAY AUGUST 26
FROM: WAYNE HEINMILLER (847-248-5415 email@example.com)
On our 8/26 conference call we continued our discussions on number
pooling. We concluded the following:
- For planning purposes for number pooling in 1998, vendors and
carriers should anticipate no capabilities beyond those defined for
Release 2 for the NPAC interface. Changes to the NPAC interface do
not come quickly, and potential changes may need to be coordinated
between both NPAC vendors.
- There are a variety of ways to implement databases in an SCP (or
similar platform) to minimize the capacity impact of number pooling.
Some schemes may be more efficient than others.
- The current NPAC interface (or Release 2) does not strictly limit
vendor implementations to address the impacts of number pooling. It
may place some practical limitations on what some vendors can
accomplish, absent further changes to the NPAC interface.
- One approach to supporting more efficient network database
implementations substitutes processing in the local SMS (or other
intermediate system) to construct ranges from the Release 1/2
downloads. However, this could have impacts on the goal of having
data available in the network database within 15 minutes of
receiving the download from the NPAC. (Too much pre-processing
could interfere with meeting the 15 minute goal.) Carriers and
vendors need to remember the 15 minute goal as they consider the use
of pre-processing to build capacity efficient network databases.
- Each carrier, because of their chosen architecture, may have
different capacity needs. Carriers need to have discussions with
their vendor(s) to determine whether their vendor(s) can meet their
capacity needs based on no more than Release 2 of the NPAC
- To make efficient implementations for pooling easier, capabilities
not supported by the current NPAC interface would be desireable.
These include (1) pooling indicator (to be part of Release 2), (2)
explicit range representation, indicated by a start and end
telephone number (instead of the current enumerated list), and (3)
pooled data reasserts itself when ported data is deleted (instead of
requiring an additional download to re-establish pooled data for a
ported number that is disconnected). The NPAC subcommittee needs to
determine specifics to support these changes.
- Changes to the NPAC interface do not require vendors to change
their network database implementations. A vendor could continue to
support an existing implementation of their network database, even
though a new NPAC interface might make a more efficient
- There are many ways to support implicit indications of a range
(such as NPA-000-NXXX, as suggested by Siemens), but implicit
indications are not recommended.
- It is likely the suggested NPAC interface changes will not be
backward compatible. These changes might require the NPAC
subcommittee to discuss how to support interface changes when the
changes are not backwards compatible. There are general issues of
how to handle non-compatible NPAC interface evolution that would
need to be addressed.
- While the interface protocol might change, it will probably be
necessary to support pooling over Release 1/2 interfaces at the same
time it would be supported over the new interface (Release 3?). It
should be possible for the NPAC to download in different
representations based on the version supported by the specific
- There may be aspects of pooling and its effects on the LNP GTT
function that remain to be discussed.
Based on this discussion we determined the following direction would
1) Communicate desired changes in the NPAC interface to the NPAC
sub-committee, and encourage them to begin work even if a time frame
for availability cannot yet be estimated.
2) Carriers to discuss their needs with their vendors, to determine
if their vendor can provide necessary database efficiencies based on
no more than Release 2 of the NPAC interface, and to provide
feedback to this subcommittee of the full Steering Committee as soon