Test Planning Team Meeting - 11/21/96

Chicago, 350 N. Orleans St.

Attendees:

Bill Belshaw, MCI

Ralph J. Brown, AT&T

Victoria, Cernich, CPD, INENA

Andy Chalk, Sprint

Joe Clark, Bellcore

Carmen Colella, Ameritech

Nancy DeRoo, Ameritech

Don Dabney, SWBT

Mack Dobkins, US West

Mitch Fuchs, AT&T

John R. Good, Ameritech

Ed Hendrix, BellSouth

Gene Johnston, GTE

Rick Jones, INENA

Larry Lovett, Sprint

Jim McCausland, SWBT

Walt Subora, Ameritech

Allena Wheatley, BellSouth

AM:

I. 911:

A. General Discussion:

Victoria Cerinich for Chicago P.D. interested in 911 service

Rick Jones - ETSB member, N.E. suburbs.

Victoria: How will LNP affect the police databases? How will the volume look?

Concerned about speed of update of databases (1 day turn-around)

Concerned about being able to contact the correct LEC on the first try to do

wiretaps or records searches.

12 total 5ESS or DMS E911 tandems in Illinois,

2 in Chicago,

4 in suburban Chicago

Some E911 service near O'hare served by Centel

E911 service providers want a dial-tone service-provider code on the 911

records. There are existing fields by NPA-NXX in database that designate

service provider; needs to be an OCN value by DN.

Note: restrictions on ESN number spectrum. Could be expanded to 4 or more

digits from current 3 digits.

** Refer the general issue of how calls from police agencies are referred to the

correct telco to the operations team.

IVR is a front-end for NPAC, in some places, to allow authorized users to get

LRN data.

** Perhaps that will be a source for police agencies. Issue for Operations and

NPAC committees.

911 calls don't make portability dips: no effect on call-handling delay.

B. Test plan comments and questions:

Pg 113 - direct trunks to PSAP; none in Illinois, implies basic 911

TOPS question: (use a call box in Illinois, 911 calls goes to a local police

dept call box.) other places, TOPS operators get call on E911 failure. In

those places, the impact may be in the form of an operator-extended call to 911

(either repeating ANI or using the caller's DN as ONI).

4.5.6.2 "Access Tandem" should be "911 tandem" or "911 router".

** Have to have callbacks from 911 bureaus in the test plan. Need to add a

return call to each test case. (May already be in test plan.)

Ported PSAPs will not be in test plan, as of now.

Need to cover scenario: customer changes provider and changes address; how

does that flow into system?

Receiving company must pass in a 911 order to the 911 provider, time frames are

specified.

** Tough scenario: 911 arrangement with Ameritech, but ported number is in a

Centel serving area. Will have to do router-to-router (tandem-to-tandem)

routing of traffic. Nancy DeRoo to work with Andy Chalk, Sprint-Centel.

There is a test PSAP in an Ameritech location that can be used for testing.

Question about whether this is OK for production testing. Will real tests have

to be on real PSAPs.

Rick: in the event of failures, what happens? testing must prove the emergency

back capabilities.

- LRN SCP failure doesn't affect 911 calling, only callbacks.

- default on 911 trunk group failure will be per end-office. For ALECs, will

most often be trunked to ILEC end-office in same rate center.

** Nancy asked for an ANI failure case. Tandem will look up default ESN per

incoming trunk group. Nancy to write up for test plan.

LRN LNP data is in multiple SCP pairs, all driven by same NPAC. For a

particular PSAP, only one pair will be used to do dips for callbacks. LNP

database does not affect call to 911. Need to have a way of tracking

responsibility for the number in case of failures.

((Is it worthwhile to introduce a deliberate assignment error by assigning a DN

in the wrong switch to see if the 911 routing is affected?)) To be addressed by

test plan group on 12/11/96.

Interim portability to real LNP conversion is NOT planned as part of the test

suite.

Wireless LNP not supported until 1999. Not part of this test effort.

****

II. Operator services:

Cases described in handout from Ameritech, Carmen Colella, Ameritech

Three Porting types

- Billing number ported/non-ported

- Calling number ported/non-ported

- Called number ported/non-ported

six orig types

- 0- (or 00- ??) two kinds, with and without handoff to AABS for

collect calls

- 0+ same two kinds

- 0+ full automation

- AABS cut to operator for acceptance at terminating end.

Not covering DA call completion yet. That will get more study.

four billing types

- calling card

- collect

- bill to 3rd (accept or no-accept)

- sent paid

Busy verification

- DN ported or not

- billing number ported or not

- number not verifiable, operator display

Also direct Operator-originated LRN queries

What about 0- call handoffs? to be discussed.

Aside: Busy-line verify and interrupt. If number is ported, need to get to the

right provider and follow the service-provider's rules. Have to do LRN look-up

at operator switch, route call to correct switch ON THE VERIFICATION NETWORK, or

may have to route to the other service provider's operator.

Expect to get LNP load in Chicago for V.O. 7/19/97. Will be able to test all

but cases where LRN should be displayed, including manual query cases. Will

need IWS positions first; IWS delivery schedule might not match up.

** Carmen to provide schedule for V.O. software and IWS positions to test team

when firm.

Concern on the part of SWBT that the TOPS rollout won't allow them to meet the

10/1/97 service date.

Ralph will send 38-page test plan to Walt. Walt will send to Carmen and load to

Barry's (www.ported.com) web site and/or MCI's (www.cameos.com) web site for

whole team.

Busy line verify probably won't work except on new IWS positions, makes for some

operational problems. Would only work for cases where the serving end-office

can be reached on the verification network. If served by another OS provider,

will cause a problem if the LRN isn't available to look up an inward operator

code.

Billing number porting will be handled