TO: MIDWEST LNP SCP REQUIREMENTS SUBCOMMITTEE

SUBJECT: CONFERENCE CALL NOTES FROM TUESDAY AUGUST 26

FROM: WAYNE HEINMILLER (847-248-5415 wayne.heinmiller@ameritech.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

interface.

- 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

implementation possible.

- 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

interface.

- 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

be pursued:

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

as possible.