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.