TO: MIDWEST LNP SCP REQUIREMENTS SUBCOMMITTEE

SUBJECT: NEXT CONFERENCE CALL TUESDAY 7/29 AT 10 AM CDT

FROM: WAYNE HEINMILLER (847-248-5415 wayne.heinmiller@ameritech.com)

Our next conference call will be Tuesday, July 29 at 10 AM CDT.

The call in number is 800-708-XXXX, and the passcode is XXXXXX.

Attached are the minutes from the 7/15 call.

Expect to receive additional materials for the call over the next

several days. In addition to following up on the items from the

last call, I have also received some comments on our GTT Looping

Annex from Arthur Doskow (Nynex) which I will distributing.

Content-Type: message/rfc822

Date: Thu, 24 Jul 1997 22:50:12 -0500

From: "WAYNE HEINMILLER " <>

Subject: minutes from 7/15

Message-Id: <"50642242707991/27843 IN-DECTSAP"@MHS>

Midwest LNP SCP Requirements Subcommittee

Conference Call Notes for July 15, 1997

Author: Wayne Heinmiller

General

Start of trial pushed back to August 11. NPAC, SPOC, and Testing

subcommittees revising schedules based on changes in dates. Impacts

on trial end date not yet determined.

GTT Looping Test Scenarios

The looping scenario tests were submitted to the Testing

Subcommittee, and they will be incorporating them into their test

plan document. The looping tests may not be part of the trial

period. Test and SPOC subcommittees re-evaluating which testing

must be performed during a potentially shorter trial period. There

is also another industry test activity (lab to lab) scheduled for

October/November under IITP sponsorship, that is expecting to

address portions of LNP testing (including tests considered too

risky for live networks). There is concern about the test scenario

that disconnects or blocks NPAC links for a carrier. Because of the

interference with normal NPAC activity, it may prove too disruptive

to the test schedule during the trial period. The manually

initiated looping conditions, on the other hand, can be performed by

bilateral agreement, without necessarily impacting other testing

activities.

FCC Request to Test Overload Conditions

This is no longer an issue for Illinois. We had been asked by the

Steering Committee to assist in formulating a response to the FCC's

trial "clarification" request. The FCC had requested that we

consider including various tests during the trial period, including

overloading the LNP databases of all carrier simultaneously. It has

been decided by other groups that this overload test would be better

addressed by the IITP lab-lab testing for October/November.

Number Pooling

We continued our discussion on number pooling, and possible impacts

on the requirements document or network elements and architecture.

We received a note from Brian Baldwin (co-chair of Number Pooling

subcommittee) requesting we provide feedback in a common structure

to be used by all subcommittees. (Wayne will draft our feedback

note for review at the 7/29 call.)

There has been no need identified to revise our requirements

document in order to support number pooling. (As other

subcommittees deliberate, it is possible they may identify changes

in their areas that could drive changes into our area.) There have

been two general approaches identified for handling pooled numbers.

In one approach, the thousands block would be assigned to one

carrier, but database entries would not occur until a specific

number was actually assigned to a customer. In the other approach,

database entries are made for all thousand numbers assigned to a

carrier at the time of assignment, whether or not there are

customers associated with a number.

There are, however, potential impacts of number pooling. It is

possible that pooling might increase the size of the LRN database.

This can affect costs as well as performance, including possible

increased delays for handling queries and messages, with possible

impacts on other network elements as a result. Depending on the

amount to which database size is increased, it can cause changes to

network architectures, including partitioning LRN databases among

additional network elements (SCPs).

There were concerns about the effect that number pooling could have

on NPAC interface capacities. Adding "pooled number" downloads,

potentially a thousand at a time, could have a significant impact on

the ability to process "ported" number (representing current live

customers) within the 15 minute window. It would be desirable if

the NPAC subcommittee could establish that downloads for blocks of

numbers would occur only "off-hours".

We assumed that switches would continue to operate on a six digit

basis (NPA-NXX) for generating queries and routing.

It may be a question for the Operations or NPAC subcommittee whether

the download needs to identify downloads for pooled numbers

differently than for ported numbers. For real-time operation for

routing calls this knowledge does not appear to be necessary, but it

may be helpful for maintenance activities.

Clarification of "Unexpected Message" Treatment

There were no further comments on the proposed changes to REQ-540 to

clarify that unexpected TCAP messages should be treated in the same

manner as unexpected AIN messages by the LRN application.

Failure of Replicated GTT Systems

Discussion around the notes of the previous discussion. The notes

accurately identify three alternative way to ensure that messages

are not transmitted to systems which cannot perform GTTs due to a

temporary condition. Wayne will draft proposed text for the

requirements document. It will be mostly explanatory text,

describing the problem of failed GTT functions in a replicated

environment. One new high-level requirement will be developed.

Requirement will state that if LNP GTT functions are deployed in

replicated architecture (to meet reliability requirements), then it

is required that messages for the GTT function are not routed to a

failed LNP GTT function.

IC Denial Message (from John Kaczala - Ericsson)

Discussion determined it would be acceptable to treat "IC Denial"

for LIDB messages as non-mandatory. Indication is that this is

never transmitted by itself, but only as the second component in a

TCAP message.

Trigger Criteria Type (from John Kaczala - Ericsson)

Bellcore has defined new trigger criteria type for LNP. Vendors

currently using 3/6/10 PODP trigger criteria type. Need to develop

some additional explanatory text for the requirements document to

explain. It needs to include explanation of the routing impacts of

using the same trigger criteria type as an existing AIN trigger.