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 in a signaling database to do 10-digit
global titles, like AC/AR. Interaction with TCAP and SCCP layers when the
sending switch is not LNP capable.
4-digit OCN of the billing number in LIDB needs to come back in the query to get
the AMA record right. That won't work in DMS until 2Q98, NA009. Instead will
use LRN in AMA record, obtained by a second query. (Aside: Ameritech uses MF to
its own end-offices, but SS7 to other carriers. Implies signal-ported-number
for calls completing to Ameritech destinations.)
Carmen is concerned about the effect of multiple database dips on call-setup
delay. Carmen wants call-setup delay tests for various dip scenarios.
Call-setup delay tests: will need to test lots of scenarios for delay.
Operator service is the most affected.
Aside: Issue on possible looping of SS7 TCAP messages if different databases
haven't been synchronized. Do we need a hop-counter in SCCp or TCAP to prevent
this looping from continuing indefinitely?
********
P.M.
Current service data 7/1/97; one objective for today is to test the
reasonableness of that date, and work out arrangements for friendly testing.
III. Timeline Discussion
A. Current Timeline (general):
o Late 96 to mid March 97 - NPAC Protocol Stack-to-Stack tests.
o mid-feb to mid-March - NPAC functionality tests
o NPAC live on 3/17
o mid-March to mid-June (6/13/) - NPAC turn up tests (6 test slots)
o 4/1 to 8/31 - EDI tests
B. Standard intervals (defined by Ops team):
NXX request in LERG to complete - 45 days
Then can start placing orders for ported numbers
First ported number in newly requested NXX - 5 days
subsequent ported numbers - 3 days (after the first 5 days have passed)
aside: LERG - Local Exchange Routing Guide
LARG - LIDB Access Routing Guide
C. Discussion:
Question: should we start live testing, between providers that are ready, prior
to end of all NPAC turn up tests?
Ralph believes that the mass downloading of test numbers has a high probability
of messing up the live tests. Could only reasonably go ahead by manually
entering the live LRN data into each SMS, not NPAC. Could potentially start
around June 1 that way.
Not clear that we could even count those tests as part of official intercompany
tests.
Basic plan is to wipe out the SMS, SCP databases on 6/13 and do a fresh download
from NPAC for the total setup.
NPAC might or might not be physically in Illinois.
** What is the availability requirement on backup NPAC?? How soon would it have
to come on-line after a primary NPAC failure.
Dick Dowd has volunteered to be the NPAC testing overseer. Operations committee
wants a job description for that work.
Suppose shooting to start testing on 6/16, will have to put in LERG/LARG
updates much earlier. Downloads would occur on 6/15. Would want to put in some
orders either right before 6/15 or on that day.
Is there any result on choosing the number of test numbers/lines? AT&T
suggested 8 to 10 per company. After some discussion, this number didn't
change. The point was made that numbers would not only be ported from
Ameritech. Many of the numbers would ported between other service providers.
Turn up operator services systems a bit later; that will have to be planned
when the OSS deliveries firm up.
Emphasis again: not everybody has to run every test case. Some planning is
required to determine the set that applies to everybody. Also have to make some
agreements on what validation of AMA results means, although actual AMA output
details won't be exchanged.
Bill has begun a format for an Executive Summary results statement.
We expect to put all the plans under change control before January meeting;
Then we can use January and February meetings to nail down more detail on how to
set up implementation plans.
The FCC indicated that official testing must start by 7/1; this plan meets
that. In fact, it may be a couple of weeks before the setup details are
hammered out well enough to really start production testing.
Question: since each company will do dips and hand off LRN, will SS7 network
have to be changed?
Screening of global titles will have to be expanded to accommodate all the
portable codes that must be reachable from an STP. If function is not
supported, then the 10-digit GTT entry would be "null". Does that mean you use
the 6-digit GTT as default.
Considerable confusion about true switch availability dates: It appears that
the first real intercompany Operator service testing involving Ameritech's TOPS
would be mid-July at the earliest. Perhaps AT&T testing using OSPS could be
earlier, except for OS-to-OS handoffs for Busy-Verify.
Concern that the TOPS systems in Ameritech are pure MF, no SS7, for end-office
signaling to the OS.
Suggestion to put voice mail on every test line that will be terminating calls.
The answering phrase would give the DN, the company, the identify of the switch,
and perhaps other information. This allows a lot of testing to be done
single-handed strictly from the originating end.
Tests should be included showing that repair service calls to the wrong repair
bureau are properly referred to the correct bureau.
** There is presently no agreement on how to deal with 10-digit triggers in the
process flows. 5ESS can't handle it until after the test interval is over.
Once settled in operations committee could consider it for testing.
Need to decide when to do 911 testing. Do it early to allow extra time for
clearing problems. Complete at least by 8/1. Since the test numbers are not a
natural part of the MSAG and the 911 databases, it will be necessary to simulate
the entry of 911 orders for the test number. Nancy DeRoo asks that these orders
go to her. The first tests would go to test PSAPs, but very soon the calls
would have to go to real PSAPs. It would be preferable if the PSAP knew that
test calls were coming within a given period, but not exactly when the calls
would come. The test should include screen captures at the PSAP to verify that
everything looks as expected.
Question: can the testing be completed between 6/15 and 9/1 for all players?
Since dedicated staff is likely to necessary, can everybody step up to
completion and it done in ten weeks?
Ralph suggests targeting 8/15 completion to do report by 9/1.
Official report-due is 10/1. No need to complete report by 9/1, might even do
straggler tests after 9/1.
Walt also suggests targeting 8/15 as first-pass complete, in the knowledge that
retesting of fixes will be needed and a few stragglers will occur.
Major concern was expressed that the delivery schedule for TOPS after the VO is
too late to meet the 10/1 date. In Illinois, the steering committee indicated
that a fully capable OSS is not a pre-condition going into LNP service. If the
TOPS is not ready, the steering committee has judged that not to be a stopper.
Meeting participants from other parts of the country indicate that this might
not be considered to be true in their service areas.
D. Consensus:
o Early May, input portable NPA/NXXs using normal processes as defined by Ops
Committee, DIG, etc.
o Week of June 15, do first porting of numbers between providers using 5 day
process. If possible, provide error scenarios for process. Also, include some
unbundled loops in the orders.
o Week of June 23, perform extensive call through scenarios.
o Week June 29 through end of week of August 11, do other scenarios (repair,
conflict, 3 day porting, cancel port, Operator services calls, etc.) as defined
by implementation plan.
NEXT MEETING: December 11, Room 437, 350 N. Orleans.
Conference call: Friday 12/6, 8:30 CST, 312-814-8097
JANUARY MEETING: Jan 8 and 9, after opns meeting - two days to get started on
implementation plans, 350 N. Orleans, Room 437.
January Conference call: Tuesday 1/28, 9:00 CST, 312-814-8097
FEBRUARY MEETING: Feb 13, after opns meeting, 350 N. Orleans, Room 437.