Team, the attached are minutes from the last Operations Ad-Hoc 911 team

meeting. There was a request for volunteers to co-chair this team, and

we had 1 volunteer. Ms Nancy DeRoo (Ameritech) volunteered as a

co-chair of this team. There were no additional volunteers. If you would

like to volunteer as a co-chair, please contact Nancy on 708-229-0461.

The following minutes have been provided by Nancy. If their are any

major errors or omissions, please contact Nancy and she will be glad to

amend the minutes.

Barry

---------------------------------- Forwarded ----------------------------------

From: Nancy_J._DeRoo



Special 911 Sub-Committee Meeting Minutes

Feb. 10, 1997

We finished answering the list of questions that was presented at the

last sub-committee meeting

#10 There was concern regarding soft dial tone. GTE has this capability

in (some states I heard mentioned-California, Vermont, New York,

Florida) A poll was taken in the room of which service providers would

be offering soft dial tone. It was determined that only GTE was going

to be providing this service.

#12 E911 is not a translated number that would launch or trigger any

query. Not effecting 911 call set-up, delay, or routing.

#18 Test calls from mixed carriers in same PSAP area will be done if

applicable.

#19 ANI failure test calls were added to the test call scenarios

previously sent to Barry Bishop to load to the web site.

#20 The reliability of the NPAC database and it's restoration time was

discussed at the previous meeting. It was described as a fault tolerant

and redundant database and not an issue that would directly effect the

receipt of 911 calls.


Judy Cortiana - Pac Bell, offered a new function code of "M" as a

solution to identifying orders that were being processed due to number

portability. She is also on the NENA committee to identify database

standards and will take this to the TELCO/VENDOR conference in March for

discussion with other vendors.

It was agreed that if we have a unique function code for portability, if

necessary, we could check the error files in the 911 database and query

just for that function code in case of problems.

There was agreement that there should be a unique identifier on every

ported order that would be able to be read by each service provider's

911 extract process in determining the application of the new function

code "M".

In order to keep the 911 database integrity, any disconnects due to

number portability will not be applied to the 911 database. This will

keep any number that is just changing service providers and not moving,

in the 911 database. This change will take place at the extract process

that the service provider sends to the 911 database. But, service

providers will still send the adds and any TNS that are porting and

moving.

There was discussion on using C orders versus the "M" function code.

But Consensus was that the "M" function was the way to go.

The "M" function issue was to be taken back to each company's SOA group

and discussed for problems.

Also, if that company has the 911 database, the changes necessary to

accommodate the new "M" functionality there.

We discussed the need to add the 3-5 digit alpha-numeric company ID for

each service provider. NENA will charge a fee and keep track of which

company has used which combination of alpha-numerics. Each company will

take this upon themselves to get this information to NENA, then to their

appropriate 911 database provider/s.


Issues that need to be completed:


1. Establish a unique identifier on both adds and disconnect orders

2. Extract process search for identifier on orders

3. For add: generate unique function possibly an M function (Judy

Cortiana Pac Bell to take back to

NENA)

4. Disconnect order: extract process looks for portability unique

identifier and if found does not create an

update record

5. Update record (complete new record)flows into the E911 database

including service provider

Validation for TN is on address also (in case of typos)

6. Update record flows to switch (if switch type requires a recent

change message creation)








I received an email from one of my contacts at Ameritech and here are

several of the FIDS that will signify porting:

INVU=Inventory Updates Required for TC TNS that are ported in to

non-original serving switches

LLNF=Local Loop Not Furnished

LRN=Location Routing Number

NEWP=New Service Provider ID

OLDP=Old Service Provider ID

POUT=Ported Out Telephone Number

RTN=Return Ameritech TN to Original Serving Switch

RTNN=Return Ameritech TN to other than the Original Ameritech Serving

Switch


Each 911 database company must add the alpha-numeric ID to each record

that exists in their database prior to the 10/1 timeframe. This will be

taken back to be addressed by the appropriate people in those companies.

(This can't be accomplished until the alpha-numerics are known) The

field must be added to the existing records in each 911 database and

formats changed to be able to send that information out to be displayed

at the individual PSAPs. Their equipment must be able to accommodate

this new field also. Judy will bring this up at the TELCO/VENDOR

conference in March along with the other issue.

The issue of updating the 911 databases based on hours, not days, is an

objective that Judy will also take back to the NENA standards group. 24

hours is the timeframe today to get the updates to the 911 database. The

need to be quicker on updates is definitely agreed to, but there was

discussion on cost of being able to do so. (additional circuits ,etc)

Also, Centel brought up the down loading process that they must use in

the Park Ridge/DesPlaines area for PSAPs that have on-site databases.

There may be an issue with getting software adjusted to automatically

download more often or have the PSAPS that pull the files over

themselves to be aware of the need to do so more often.


The next meeting will be held March 18th 08:30 (Central) at 350 Orleans,

room 463. This is the Ameritech Training Center on the 4th floor of the

Holiday Inn building, downtown Chicago. The conference bridge number

will be 312-814-8097.