Team, the following minutes have been provided by Lorin Pollock ((Sprint) Thanks Lorin) and are from the 10/16-18/96 Operations meeting. Items in bold Italics are items that I have added to Lorins minutes from my notes (Barry).

In Attendance:

Alex Bojanic Nortel

Amador Lucero US West

Barry Bishop Ameritech

Brent Struthers ICC

Dave Garner Sprint

Ed Elkin AT&T

Fay Seymour Lucent Technologies

Jim Joerger MCI Metro

Lorin Pollock Sprint

Phil Presworsky TCG

Rebekah Keating Illuminet

Robin Meier Ameritech

Sue Seitz Ameritech

Mack Dobkins US West

Bill Belshaw MCI Metro

Joan Ahern Bell Atlantic

Walter Subora Ameritech

\ MEETING ---- OCTOBER 16,1996

MEETING STARTED AT 8:55 AM

UPDATE ON ACTIVITIES BY BARRY.

OHIO MEETING FROM TWO WEEKS AGO-- OHIO WILL PARTICIPATE WITH THE ILL COMMITTEE. THE ACTIVITIES OF OUR COMMITTEE ARE BECOMING REGIONAL WITH A FOCUS ON MSA1. OHIO AND MICHIGAN WILL NOT BE DEVELOPING THEIR OWN RFP FOR NPAC. (LOCKHEED). OHIO MEETING PARTICIPATES WERE INVITED TO THE ILL OPERATIONS MEETING WITH NONE PRESENT TODAY.

BARRY OFFERED TO DISCUSS A REGIONAL DEVELOPMENT TEAM AT THE STEERING COMMITTEE MEETING AT THE SUGGESTION OF J.J. OF MCI WHO SUGGESTED THAT INDIVIDUAL STATE TEAMS AND REGIONAL TEAMS. STATES HANDLE INDIVIDUAL IMPLEMENTATION SCHEDULES AND REGIONAL TEAMS HANDLE COMMON ISSUES. STEERING COM MTG IS SCHEDULED FOR MONDAY. Note: Letter to the ICC Steering committee was presented and accepted as written. The letter has also been presented to the Michigan Steering Committee and accepted. The letter will also be presented to the Ohio and Indianna Steering committees at their next meeting. BB

DISCUSSION ABOUT RATE CENTER LIST PROVIDED BY AMERITECH -- NO ONE HAD A PROBLEM WITH LIST.

COPIES OF THE G-FRS DISKS WERE DISTRIBUTED BY BARRY. THIS IS THE FINAL DOCUMENT. FUNCTIONAL REQUIREMENTS SPECIFICATION. For those not in attendance and needing a copy of the document, please leave me a voice mail (312-220-8000) with your postal address, or send me an e-mail (barry.bishop@ameritech.com) with your e-mail address and I will forward a copy to you electronically. If you will be attending the Ohio Steering committee meeting, I will have copies on Floppy (MSWORD IBM format) available. BB

JERRY HAMPTON (Ameritech OBF Representative) WILL BE HERE AT 10AM WHEN WE WILL DISCUSS THE PROVISIONING DOCUMENT/FORM.

REQUEST FOR MULTIPLE LRNS STATUS. AT&T DID NOT SUBMIT A REQUEST FOR MULTIPLE LRNS WITH A MINIMUM OF 2. NO ONE KNOWS WHY OR WHO MADE THE REQUEST. Note: this refers to an item that was requested of the DIG committee.

DEVELOP NEW ISSUE ; #0050 LRN NUMBER ADMINISTRATION.

WHO WILL ADMINISTER LRN ADDS, MOVES AND CHANGES HOW WILL LRNS BE DETERMINED. WHAT IS THE LAST 4 DIGITS OF THE LRN TO BE USED FOR --- PHASE 2.

LOCATION PORTABILITY. THIS ISSUE WILL BE GENERATED ONLY AS A PLACE HOLDER

FOR FUTURE REFERENCE. ISSUE ORIGINATOR LORIN POLLOCK OF SPRINT. DATE 10/16/96.

ISSUE PRIORITY IS 10 OF 10. THE ISSUE SHOULD DESCRIBE LRN FORMAT --- HNPA/NXX PRIME OF SERVING OFFICE. Issue was previously sent to you. BB

THE RATING AND BILLING TEAM WERE DISCUSSING THE UTILIZATION OF THE LAST 4 DIGIT OF THE LRN--BARRY WILL CHECK WITH THE STEERING COMMITTEE ON THEIR PROGRESS. LRNS SHOULD BE UNIQUE AND NOT DUPLICATED. HLR (HOME LOCATION REGISTER) FOR CELLULAR.. DISCUSSED. SHARED NXX MAY POSE A PROBLEM OF DUPLICATE LRNS. STATEMENT MADE ABOUT THE BILLING ASPECT OF THE LRN ASSIGNMENT. SHOULD BE AN NPA/NXX ASSIGNED TO THE SWITCH WITH THE EXCEPTION OF SHARED NXX AMONG PROVIDERS. TANDEMS WILL(/may) NEED LRN ASSIGNMENTS STATEMENT ---- SHARED NPA/NXX SHOULD NOT BE ASSIGNED AS A LRN (RECOMMENDATION) ISSUE WILL BE DISCUSSED AT THE NEXT MEETING.

INTERNET LOCATION HTTP://WWW. PORTED.COM (THIS IS NOT AN AMERITECH SITE)

OP MEETING MINUTES TEST TEAM MEETING AND MISC INFO SUCH AS ISSUES WILL BE ADDED. Note: Site has hot links to all other sites that have pertinent documents(Switch GR, SCP GR, Operator Services GR, Test Plan, etc). BB

JERRY HAMPTON WILL DISCUSS WHAT IS GOING ON AT THE OBF MEETING (AMERITECH REPRESENTATIVE CLEC BUSINESS UNIT OF AMERITECH)

STATUS REPORT

50 OBF ISSUES ARE OUTSTANDING ADDRESSING CLEC ISSUES/ 10 ISSUES IMPACT LONG TERM LNP AND 10 IMPACT INTERIM NUMBER PORTABILITY.

CARE TRANSACTION ISSUE IS ONE

THE ORDERING VEHICLE FOR LONG TERM LNP. ISSUE 1122 SUBMITTED BY MFS.

CREATE A NEW ORDERING VEHICLE SIMILAR TO THE ASR PROCESS. THREE FORMS WILL BE INVOLVED FOR LNP (LSAG) LOCAL SERVICE REQUEST (LSR)

THE OBF DECIDED THAT MECHANIZATION WILL BE VIA THE EDI FORMAT (ELECTRONIC DATA INTERFACE). EDI HAS ALL DATA ELEMENTS DEVELOPED AND MAPPED. SHOULD BE COMPLETE BY THE END OF THIS YEAR. THE FOC (FIRM ORDER CONFIRMATION) FORM IS STANDARD FOR ALL SERVICE REQUEST I.E. LOOP REQUEST, LNP REQUESTS,ETC.

THE FORM DEVELOPED BY THE OPERATIONS COMMITTEE WAS COMPARED TO THE OBF FORM FOR INTERIM NUMBER PORTABILITY. DO WE NEED A SERVICE PROVIDER IDENTIFICATION FIELD? WHERE IS THE CO-ORDINATION FIELD(MCI--JJ) ALSO, IS THERE A FIELD FOR "CONDITIONAL TRIGGER" PROVISIONING. IT WAS NOTED TO JJ THAT THIS ISSUE HAS NOT BEEN RESOLVED AND IS CURRENTLY NOT ON THE FORM-- DISCUSSION OCCURRED ABOUT NUMBER ADMINISTRATION AND THE AGING PROCESS--THIS IS NOT AN OBF ISSUE SINCE AGING IS AN INTERNAL PROCEDURE. NPAC WILL NOTIFY THE DONOR SITE AS TO WHEN THE NUMBER IS BEING RETURNED AND WHEN THE NUMBER WAS PLACED ON INTERCEPT(REFERRAL).

LUNCH

12:30 PM RESTART

E911 CONCERNS BY THE ICC DISCUSSION BARRY TO ATTEND A NENA MEETING OF PSAT PROVIDERS NEXT WEDNESDAY. HOPEFULLY, ANY CONCERNS BY PSATS CAN BE DOCUMENTED.NONE OF THE ICC CONCERNS WERE RELATED TO LNP AT THIS TIME.

THERE MAY BE INTER-CONNECTION ISSUES WHICH ARE NOT FOR THE LNP COMMITTEE.

S911 DISCUSSION BY JOHN TERISI TO BE AT 1:00PM Note: Meeting was attended and no specific LNP 911 issues were identified. Issues which were identified (Interim Number Portability and Interconnection issues) will be made available shortly under separate cover. The INENA organization will participate in our meetings (probably on an irregular basis) and will assist with developing test scenarios for the test team. BB

SET THE MEETING DATES FOR NOVEMBER AND DECEMBER.

NOVEMBER 19 AND 20 LOCATION TO BE DETERMINED. TEST TEAM ON FRIDAY NOV 21

DECEMBER 12TH AND 13TH

JANUARY (1997) 6TH AND 7TH

FEBRUARY (1997) 11TH AND 12TH

JOHN TERESSEY S911 SME FOR CHICAGO HIGH LEVEL OVERVIEW OF HOW IT WORKS

Note: no additional issues were noted that would affect this system.

10-DIGIT CONDITIONAL TRIGGERS DISCUSSION ISSUE #0046

BARRY SENT (FAXED) INFORMATION ABOUT 10-DIGIT TRIGGER PROVISIONING FROM .

NORTEL WILL PROVIDE 10-DIGIT TRIGGER VIA LINE ATTRIBUTE INDEX VIA LAST SWITCH REQUIREMENTS IN JULY DOCUMENT. AVAILABLE WITH NA007 SOFTWARE LOAD.

LUCENT WILL PROVIDE 7/18/97 FOR 1ESS AND 5ESS ON 9/30/97. SOFTWARE 5E11

SEIMANS WILL NOT BUILD IN THE TIME FRAMES REQUIRED. NO ONE KNEW FOR SURE WHEN/IF SEIMANS WILL PROVIDE. JJ OF MCI STATED THAT SEIMANS WILL PROVIDE VIA LINE ATTRIBUTE. JJ WILL VERIFY WITH SEIMANS. BELLSOUTH AGREED WITH 10-DIGIT TRIGGER IF PROVIDED AS A LINE ATTRIBUTE VERSUS SWITCH BASED. Note: Due to much discussion as to how the 10 digit trigger could/should be implemented in a "ported to" service providers office, Fay Seymour (Lucent) contacted Joe Lichter (Lucent (Switch Req Team)) for Clarification. Joe and Fay have provided a memo and matrix (previously sent) which should clarify the uses of the 10 digit trigger. BB

PHIL PROPOSED CHANGE TO PROCESS FLOW (PROVISIONING) SHOWING 10-DIGIT TRIGGER AS AN OPTIONAL DECISION BOX. THREE CHANGES ARE PROPOSED TO PROCESS FLOW.

10-DIGIT TRIGGER SHOULD BE ADDED TO THE PROVISIONING FORM AS AN OPTION.

SHOULD WE ESTABLISH A TIME, PRIOR TO CUT-OVER, THAT THE TRIGGER IS SET. ISSUE OF TIMING IS OPEN. IN EITHER CASE, A WILL DEFAULT TO 10-DIGIT TRIGGER--IF 10-DIGIT FIELD IS LEFT BLANK ON THE PROVISIONING REQUEST. BARRY RAISED THE ISSUE OF CONGESTION OF RECENT CHANGE PORTS AND HAVING TO PERFORM CHANGES THAT ARE MADE BECAUSE SOMEONE FORGOT TO DATA FILL THE DEFAULT BOX ON THE PROVISIONING REQUEST. BARRY PROPOSED THE OPPOSITE APPROACH OF MAKING THE DEFAULT AT "NO" 10-DIGIT TRIGGER. PROPOSED THAT THE FIELD BE MARKED AS EITHER YES OR NO BUT NOT A DEFAULT VALUE OF APPLY 10-DIGIT TRIGGER. TCG STATED THAT THEY COULD AGREE WITH THIS PROPOSAL. IF COORDINATED BOX IS CHECKED AS YES, THE 10-DIGIT TRIGGER WOULD NOT APPLY. THE DEFAULT WOULD APPLY. IF COORDINATION IS REQUESTED , THE 10-DIGIT TRIGGER BOX MUST BE COMPLETED ON THE FORM. PROVISIONING FLOW CHART WILL BE CHANGED TO REFLECT THE CHANGES. THE ISSUE RESOLVES AROUND THE CONVERSION OF LARGE CENTREX WHO HAS FACILITIES TO THE NEW SERVICE PROVIDER. COMBINE AS ONE NOTE ON THE PROVISIONING FLOW DOCUMENT. THE 10-DIGIT TRIGGER CHOICE/PREFERENCE MUST BE INDICATED IF COORDINATION IS INDICATED. ALL AGREED ON THIS OPTION.

OCTOBER 17,1996 LNP OPERATIONS MEETING ROOM 1602 @ 225 RANDOLPH ST. @ AMERITECH. 8:30AM

DISCUSSION: SHOULD THE NPAC IVR ACCESS 800 NUMBER BE GIVEN TO EMERGENCY SERVICE AGENCIES (POLICE, 911, ETC.)? SUGGESTED AN ALTERNATIVE THAT THE SMS COULD BE ACCESSED TO PERFORM A QUERY BY THE INCUMBENT VIA A GUI INTERFACE TO CROSS REFERENCE THE LRN TO DETERMINE THE SERVICE PROVIDER. ENFORCEMENT AGENCIES, IN REALITY, WILL CONTINUE TO CALL THE INCUMBENT. RELATED TO ISSUE #0005. ADD DISCUSSION TO ISSUE DISCUSSION.

ISSUE #0042 IVR UTILIZATION DISCUSSION. BETTY MICKEL TO IDENTIFY WHAT THE 800 IVR .

ISSUE #0051

NEW ISSUE: WHAT IS A SOLUTION FOR .. HOW DOES AN EMERGENCY SERVICE DETERMINE THE SERVICE PROVIDER FOR A SPECIFIC TELEPHONE NUMBER (PORTED)

ISSUE # 0042 ADD 7X24 CONTACT TELEPHONE #

REMINDER--------WHERE ON THE LNP NUMBER PORTABILITY REQUEST FORM DO WE ADD THE 10-DIGIT TRIGGER FIELD?

PHIL WENT THRU THE PROPOSED CHANGES ON THE GENERIC LNP PROVISIONING PROCESS FLOW FORM---CHANGES WERE MADE TO THE VERBIAGE OF NOTE 1 PAGE ONE.

IF COORDINATION IS REQUESTED ON THE LSR, AN INDICATION OF YES OR NO IS REQUIRED FOR THE APPLICATION OF A 10-DIGIT TRIGGER. IF NO COORDINATION INDICATION IS GIVEN, THEN BY DEFAULT THE 10-DIGIT TRIGGER IS APPLIED.

PAGE 2 MOVED "OLD SERVICE PROVIDER DISCONNECTS TRANSLATIONS IN CENTRAL OFFICE" TO THE RIGHT TO INDICATE THAT THIS OCCURS AFTER THE SMS DOWNLOAD TO THE SCPs. BARRY INDICATED THAT THIS ACTIVITY COULD OCCUR AT THE SAME TIME AS THE DOWNLOAD. BARRY STATED THAT ALL ACTIVITIES COULD/SHOULD OCCUR SIMULTANEOUSLY. PHIL AGREED TO MOVE THE BOX BACK.

A' PAGE 3 PROPOSED CHANGES DISCUSSION: CHANGE QUESTION MARK TO 4 HOURS.TO READ: "OLD SERVICE PROVIDER ACTIVATES 10-DIGIT TRIGGER TRANSLATIONS IN CENTRAL OFFICE AT A MINIMUM OF 4 (?) HOURS PRIOR TO ORDER DUE DATE/TIME."

REMOVED "NEW SERVICE PROVIDER REMOVES 10-DIGIT TRIGGER PORTION IN THE BOX WHERE IT BEGINS "OLD SERVICE PROVIDER REMOVES ALL TRANSLATIONS". IF DESIRED??? PHIL ADDED THE CIRCLE A BOX TO START OVER IF CONFLICT IS RESOLVED ON THE LAST PAGE.

PHIL HANDED OUT CHANGES TO THE DISCONNECT PROCESS CHART. DISCUSSION ABOUT WHO DETERMINES AGING--THE DONOR MAY WANT TO DETERMINE AGING. REMOVE "AND DETERMINES AGING." ADD "INTERCEPT" TO READ "CURRENT SERVICE PROVIDER ESTABLISHES INTERCEPT TREATMENT." ON THE SECOND ACTION BOX. DISCUSSION ABOUT WHO WILL PROVIDE TREATMENT. BOX BEFORE THE END BOX---CHANGE TO "NPAC/SMS NOTIFIES THE LSMS/SCP TO RETURN TO DEFAULT ROUTING".

REPAIR PROCESS REVIEW. CHANGES WHERE IS THE AUDIT BOX AFTER "IS TROUBLE BEING CAUSED BY ANOTHER SERVICE PROVIDER?" DISCUSSION. QUESTION AS TO WHY WE HAVE TWO REPAIR FLOW CHARTS---TCGs AND THE ILLINOIS. DOTTED LINE AND NOTE ONE ARE THE ONLY PROPOSED CHANGES. CONFUSION BETWEEN PHIL'S CHART AND THE ILLINOIS CHART. SUGGESTED THAT THE DECISION CHART BOX "IS THIS THE SECOND TIME THROUGH THE FLOW?" TO "IS THE TROUBLE RESOLVED?" IF YES -GO TO "END" IF NO---GO TO "SEEK TECHNICAL ASSISTANCE".AGREED TO ADD DOTTED LINE AND NOTE 1 WITH THEIR VERSUS THERE. CHANGE "OTHER LOCAL SMS/SCP WRONG?' TO "IS OTHER PROVIDERS' LSMS/SCP/STP WRONG?" CHANGE ** TO NOTE 1 IN THE "PRE-SCREENING" BOX AND THE PROPOSED NOTE 1 TO NOTE 2.

CHANGE BOX "DOES NUMBER BELONG TO ANOTHER SERVICE PROVIDER? TO "IS TROUBLE BEING CAUSED BY ANOTHER SERVICE PROVIDER?"

REMOVE BOX ON RIGHT ENTITLED "OTHER LOCAL SMS/SCP/STP WRONG" AND INCLUDE WITHIN DOTTED BOX "IS TROUBLE CAUSED BY ANOTHER SERVICE PROVIDER?" AND NOTE 2. ADD BOX DESCRIBING AUDIT FUNCTION---"DOES SERVICE PROVIDER AUDIT FUNCTION INDICATE AND RESOLVE PROBLEM --- YES =GO TO END NO = GO TO "IS PROBLEM RESOLVED?"

NOTE: WE STILL NEED TO ADD 10-DIGIT TRIGGER DECISION BOX TO REQUEST FORM.

JUST ADD UNDER THE DESIRED COORDINATION MAKE A #25 "APPLY 10-DIGIT TRIGGER YES OR NO" MANDATORY IF COORDINATION IS YES. WILL DEFAULT TO 10-DIGIT TRIGGER APPLY.

IF COORDINATION IS NO OR NOT SPECIFIED.

DEFINING THE WORK DAYS AND WORK HOURS. NPAC WANTS US TO DEFINE WORK DAYS AND/OR WORK HOURS. SUGGESTION MADE THAT 8 TO 6 MONDAY THROUGH FRIDAY IS THE BUSINESS DAYS UNTIL PHASE 2 OF NPAC. WHAT IS THE TUNABLE DEFAULT VALUE AT NPAC FOR CONFLICT/CANCEL/ETC. PARAMETERS. WHAT IS URL OF NPAC --- TO BE DISPERSED ON 10/25/96 BY DONNA/NPAC FOR FRS DISBURSEMENT.

PROPOSAL TO NPAC--- IF THE NEW SERVICE PROVIDER DID NOT ISSUE THE ORDER ON TIME. STOP ALL AUTOMATIC CANCELLATIONS ON SATURDAYS AND SUNDAYS PLUS HOLIDAYS IF WE CAN AGREE ON WHAT ARE HOLIDAYS. DECIDED TO REVISIT ON10/18/96. A PROPOSAL WILL BE MADE TO NPAC TO ESTABLISH A MATRIX FOR BUSINESS DAYS/HOURS AGREEMENTS BETWEEN SERVICE PROVIDERS.

QUESTIONS ABOUT RATE CENTERS WILL NEED A NPA/NXX PER DISTRICT AS DEFINED ON DISTRICTS WITHIN MSA1: REFERENCE FAX DATED SEPT 30, 1996 "ORIGINAL SHEET NO. 78". NUMBERS CAN BE PORTED WITHIN A DISTRICT BUT NOT BETWEEN DISTRICTS. DISTRICT DEFINED RATE CENTERS. 32 DISTRICTS WITH 2 LRNS PER RATE CENTER---RESULTS IN A REQUIREMENT OF 64 LRNs/NPA-NXXs PER CLEC TO COMPETE IN THE ENTIRE MSA 1. QUESTION: WHY CAN'T A CLEC ESTABLISH THEIR OWN GROUPING OF RATE CENTER TO ESTABLISH NEW BULK TYPE RATES? BARRY STATED THAT THIS IS A MAJOR ISSUE CONCERNING LOCATION PORTABILITY.

INITIAL OPENING OF NPA/NXX FLOW CHART..........BY TCG................

QUESTION ABOUT BOX "OWNER OF NPPA/NXX NOTIFIES NPAC OF NPA/NXXx TO BE OPENED FOR PORTING." IS THERE A LIMITATION WITHIN NPAC FOR OWNER INPUT ONLY.

NPAC WILL NOTIFY VIA A WEB PAGE.....STEVE ADDICTS STATED THAT 2 NOTIFICATIONS WILL BE PROVIDED BY NPAC VIA THE FRS DOCUMENT..........IF BOTH NOTIFICATIONS MATCH THE FIRST BONI-FIDE LNP REQUEST WILL PASS. THIS NEEDS TO BE VERIFIED BY DONNA TO NPAC. TWO SEPARATE DOWNLOADS ARE REQUIRED. WEB SITE TO BE ESTABLISHED BY 3/17/97. QUESTION IS "HOW IS NOTIFICATION PROVIDED AND TO WHO IT IS PROVIDED. THE LERG WILL BE USED BY INCUMBENTS TO ACTIVATE GLOBAL TITLE TRANSLATIONS.

ISSUE #0001 NETWORK MANAGEMENT CLOSED PENDING BASES ON REVIEW OF JOE LICHTER LETTER DATED OCTOBER 2, 196 DESCRIBING <REQ-IL-GR-1060V1>. AND INCORPORATION WITHIN THE REQUIREMENTS DOCUMENTS. UPDATE THE ISSUE STATUS.

10/18/96 LNP OPERATIONS COMMITTE MEETING 8:30AM

DISCUSSION OF US WEST NOF ISSUE OF LNP TEST PLAN DATED 10/30/96. GENERAL FEELING WAS THAT WE MUST CONTINUE AND CAN NOT BE SLOWED DOWN BY NOF ACTIVITIES BUT AGREED THAT EVENTUALLY THERE MUST BE NOF INVOLVEMENT.

BARRY REVISED THE PROVISION SERVICE PROCESS FLOW THAT WAS DISCUSSED ON 10/17/96.. CHANGE TO 3 BUSINESS DAY VERSUS JUST 3 DAY OVERALL TIME FRAME.

SUGGESTED BY ED OF AT&T WITH CONCURRENCE PAGE 1.

PAGE 2. CHANGE.......OLD SERVICE PROVIDER "REMOVES" TRANSLATIONS INSTEAD OF ACTIVATES. ADD AT TOP "WITHOUT 10-DIGIT TRIGGER" & CHANGE DATE.

PAGE 3 CONCERN ABOUT DISCONNECT TIME FOR "OLD SERVICE PROVIDER MAY REMOVE ALL TRANSLATIONS." SERVICE ORDER SYSTEMS ARE AUTOMATED AND WILL REMOVE WHEN SPECIFIED ON THE REQUEST FORM. CURRENTLY, AUTOMATED OSS REQUIRE 2 ORDERS TO ACTIVATE AND THEN REMOVE. WE HAVE AN ISSUE TO IDENTIFY SERVICE ORDER SYSTEM ABILITY TO BECOME FLEXIBLE ENOUGH TO PERFORM TWO STEPS ON A SINGLE ORDER. NEED SYSTEM TO ACTIVATE 10-DIGIT TRIGGER FOUR HOURS PRIOR TO DUE DATE/TIME AND TRANSLATIONS (LINE) REMOVED AFTER THE CUSTOMER CONVERSION AT A LATER TIME. THE SYSTEM CURRENTLY KEYS ON A DUE DATE/TIME AND WOULD AUTOMATICALLY REMOVE TRANSLATIONS AT THE SPECIFIED TIME, FOUR HOURS LATER. BILLING TIME IS CURRENTLY AT THE TIME OF REMOVAL. CAN OUR SYSTEMS AUTOMATICALLY ESTABLISH A PSUEDO DISCONNECT TIME I.E. REMOVE TRANSLATIONS. A CONFERENCE CALL IS ESTABLISHED ON OCT.31 AT 1:00CST WITH A CALL IN NUMBER OF (312) 814-8097. TO DISCUSS THIS ISSUE.

One additional item: Prior to the close of the meeting, several participants volunteered to put together a "strawman" document which will explain each of the process flows in greater detail. The documents need to be sent to me no later than Nov 8^th so they can be distributed to the team prior to our next meeting. These items will be discussed the first day of our next meeting. The following are the sections and person(s) who volunteered to do the write up for the section.

Provisioning Process: Robin Meier & Sue Seitz (Ameritech)

Cancellation Process: Ed Elkin (AT&T)

Disconnect Process: Rebekah Keating (Illuminet)

Repair Process: Jim Joerger (MCI Metro)

Conflict Resolution: Dave Garner (Sprint)

Code Opening: Phil Presworsky (TCG)

Our thanks to the volunteers!

Attached you will find two of the items I have already received from Jim and Rebekah (thanks for the prompt response).

Please Note, updated process flows and forms have been previously sent. If there are any errors or omissions to these minutes, please feel free to contact me on

312-220-8000.

Barry Bishop

The following was received via E-mail Friday Nov 1^st, 1996 from Jim Joerger (MCI-Metro). Thanks Jim.

ILLINOIS LOCAL NUMBER PORTABILITY

OPERATIONS TEAM

REPAIR FLOW TEXT NARRATIVE

OCTOBER 28, 1996 REVISION

(IVR & AUDIT ADDED)

4.7.2 End-User

The process begins with the end-user customer making a call to a

repair bureau to request service or to report a problem.

4.7.3 End-User Calls Service Provider and Indicates a Problem

The end-user is instructed by their service provider, whomever is

providing service, in the manner in which to report problems. Still,

for a variety of reasons, end-users may not always reach the correct

service provider.

4.7.4 Prescreening to Determine Reported Telephone Number and Associated Service Provider

Prescreening is a common activity in customer care organizations apart

form portability scenarios. These activities are designed to identify

problems to aid in sectionalization and referral efforts, resolve

end-user operational problems, and inform the user of outages that may

be the reason for the trouble call. In short, the prescreening process

is designed to learn as much as possible from the end-user about the

problem, resolve issues immediately if possible, and use the

information gained in the prescreen to assist in any necessary trouble

sectionalization.

4.7.5 Does Called Service Provider Serve The Reported Telephone Number?

This decision step is performed to determine if the end-user making

the call, is the customer of the service provider that has been

contacted. It is recognized that in a portability environment, that

the end-user making the call, may not be reporting trouble on his or

her telephone number, but possible that they cannot reach another

number. In addition, the telephone line used to reach the service

provider may not be the number being reported. Thus, the service

provider needs to determine if this end-user is reporting a telephone

number that is a customer of theirs.

An Interactive Voice Response (IVR) device capability may be useful to

a service provider in making this determination of who the service

provider is. Connection of an IVR device to the NPAC can provide a

capability for the aggregate of service providers in an area of

portability. In addition, the IVR device can be used to support

emergency services authorized personnel in obtaining trap and trace

information. A typical IVR device would have the following attributes:

- Engineered # of Ports for anticipated load

- Reliable to 99.9% availability

- Service provider name and telephone number information provided

- Security access (Pin per service provider)

- System hold time maximum

- Support multiple requests on a single access

- Traffic measurement ability

- Disaster recovery and backup

- Toll-free number access

- Per access billing process

In order to be available for telecommunications repair personnel, the

IVR would, by necessity, need to be isolated from use by the general

public.

4.7.5.1 Refer End-User to Correct Service Provider Repair

If the contacted service provider is not serving the reported

telephone number, then the service provider shall refer the end-user

to their correct service provider. This does not imply that the

service provider needs to determine who the service provider is, but

to instruct the end-user that they are not the correct service

provider and that the end-user should contact their service provider

for assistance.

4.7.5.1.1 Note

In the case where a number has ported and the ported to service

provider provides service via an unbundled loop from the donor or a

third party provider, and the end-user has contacted the donor or

third party provider, this situation should not be considered as a

scenario where the contacted service provider is serving the reported

telephone number. Instead, the end-user should report the problem to

the service provider that they have a billing relationship with for

repair service. If the problem is sectionalized to the unbundled loop,

then the service provider will refer the problem to the donor or third

party provider and cared for pursuant to whatever contractual or

business relationship has been negotiated.

4.7.5.2 Open Trouble Ticket

If the contacted service provider is serving the reported telephone

number, then the service provider shall create a trouble ticket and

handle via internal processes.

4.7.6 Analyze Trouble

This text is not intended to dictate procedures for a service provider

to analyze reported troubles from their customer. Instead, this

section is intended to indicate that a service provide must perform

some sort of analysis process to sectionalize the problem, and that

the reported trouble may be caused by LNP network uniquenesses. For

example, a check should be made of the NPAC to determine if the

telephone number is in the "Pending" state. If it is, this would

signal that the number is in transition and being ported and thus,

maybe the reason that the end-user is experiencing difficulty. In

addition, a check of the NPAC may reveal that the number is in the

"Active" state but has recently ported and possibly indicative of the

NPAC broadcast routing database update process in all service

providers' networks. Moreover, the active state may be indicative of a

routing database problem if the customer is unable to receive calls

from certain other end-users. In short, there may be problems

associated with the common provision of local telecommunications

service, or there may be a an anomaly related to the network and

service provider changes that occur when Local Number Portability is

implemented.

4.7.7 Is Problem Determined to be Caused by LNP?

This question is asked to direct the further efforts of the service

provider. Call processing network elements, translations, and call

routing databases in the service providers' or another service

provider's network may be the source of the problem. In addition,

there could be a problem with the NPAC SMS. The analysis and

sectionalization steps determine the steps that follow.

4.7.7.1 "No," Problem Not Determined to be Caused by LNP Response

The service provider utilizes internal trouble resolution procedures

to fix the problem (business as usual).

4.7.7.2 "Yes," Problem Is Determined to be Caused by LNP Response

When the problem is determined to be caused by an anomaly related to

the network and service provider changes that occur when Local Number

Portability is implemented, the steps that follow are checks aimed at

sectionalizing and isolating the problem and resolving it:

- Are Line Translations Correct?

- Is NPAC/SMS Wrong?

- Is Local STP/SCP Wrong?

- Does Service Provider Audit Function Indicate and Resolve Problem?

The above verifications steps are used for two purposes. First, these

checks can sectionalize where the problems exists. In addition, these

checks can determine if the problem resides in another network. Thus,

these actions and their sequence are internal service provider

specific in the manner in which they are performed, and may be

performed at various stages of the repair process.

The "service provider audit" function has been developed in response

to the possibility that data mismatches may occur between the NPAC and

local SMS/SCP databases. The service provider audit function is

designed to have the NPAC perform a data discrepancy comparison

between the NPAC data, assumed to be always correct, and the Local SMS

database in a network(s). The audit function follows these basic steps:

1. Service provider requests the NPAC do perform an audit of another

service provider over the SOA interface, specifying the directory

number(s) and service provider. Note: NPAC may have a screening

mechanism to determine whether audit requests towards this service

provider are accepted.

2. NPAC send a request for data to the service provider being checked

via the local SMS interface. This interaction does not require any new

command structure; this is accomplished with the existing "M-get"

command.

3. In response to the query result, the NPAC performs a data

comparison between the data it has stored for the subscription version

data and the query response.

4. If a discrepancy exists, the NPAC will add/modify/delete data by

sending a broadcast to the local service provider SMS.

5. The NPAC records results of audit requests in a log and makes

periodic reports available.

4.7.8 Is Trouble being Caused By Another Service Provider?

It is understood that if the problem appears to be the cause of

another service provider's network, that the verification steps above

will have preceded referral to the other service provider.

4.7.9 Indicate Trouble to Involved Service Provider

4.7.9.1 Associated service providers involved in the provision of LNP

service will work cooperatively with other service providers to

sectionalize troubles.

4.7.9.2 The following information should be exchanged when handing off

or referring the trouble:

- Trouble report number or equivalent

- Contact telephone number

- Contact ID (i.e., name or initials)

- Time and date report was received from referring service provider

- Telephone number or circuit ID

- Trouble reported

- Other information that may be of assistance (e.g., history, subsequent reports)

4.7.9.3

Upon receipt of a trouble report from the referring service provider,

the service provider will conduct, independently or cooperatively with

the referring service provider, tests required to determine if the

trouble is in its own equipment and facilities or the point of

interface of an adjacent service provider(s).

4.7.9.4

If the trouble is found to be in the service provider's equipment or

facilities, the trouble report will be closed out with the referring

service provider and the following information will be provided:

- Trouble report number or equivalent

- Date & Time Cleared

- Status of problem (i.e., temporary or permanent repair)-- If

temporary, estimated time of restoral

- Contact name or initials and telephone number of the person

closing out the report

- Type & Nature of trouble found and action taken

- Service provider Testing Information (if requested by referring

service provider)

- Circuit ID if appropriate

4.7.9.5

If there is no trouble found in the service provider's own network,

they shall refer/hand-off the trouble to the referring service

provider and provide the following information:

- Trouble report number or equivalent (referring service provider)

- Contact telephone number (referring service provider)

- Contact ID (referring service provider) (i.e., name or initials)

- Time and date report was received from referring service provider

- Service provider testing information (If requested)

- Circuit ID for circuit specific problems

- Trouble reported

- Other information that may be of assistance (e.g., history, subsequent

reports, referring service provider testing information, if available)

4.7.9.6 In the event a premature or improper hand-off has occurred,

the service provider will resume cooperative testing with the

referring service provider in order to sectionalize the trouble.

4.7.9.7 Trouble Ticket Exceptions

The following information is provided in an effort to assist service

providers and in the resolution of troubles that fall outside of the

normal ticket resolution flow once the original ticket has been closed

out with the referring service provider.

4.7.9.7.1 Request For Test Assistance

When a request for a test assist is made to an service provider, the

service provider shall provide the necessary assistance to facilitate

the request.

4.7.9.7.2 Request For Escalation Assistance From Referring Service Provider

It is the responsibility of all service providers to work

cooperatively to resolve all trouble reports as expeditiously as

possible.

The referring service provider is responsible for escalations to a

service provider associated with trouble tickets when the trouble has

been isolated by an service provider to another service provider. When

a request for escalation assistance is made by the referring service

provider to an service provider, the service provider will provide any

information concerning escalation numbers or names that they may have

to the requesting referring service provider. At the referring service

provider managers request, the service provider manager may

participate on a phone call in an attempt to assist the referring

service provider in escalating to the other service provider.

If the referring service provider refers the problem back to the

service provider, it should be understood that the process will

reinitiate at the escalation level when the problem was initially

referred into the service provider.

4.7.9.7.3

In the event the trouble can not be sectionalized (e.g., no trouble

found, intermittent type of problems), then the referring service

provider and all service providers will cooperatively work together

(e.g., cooperative testing) to locate and/or isolate the problem. Once

the problem has been sectionalized then previously developed process

shall be followed as outlined above.

*******************************************************************************

Fax Cover Sheet

Date: October 30. 1996 :

To:

Barry Bishop

Company: Ameritech

Phone: 312­220­8000

Fax: 847­698 6187

From: Rebekah Keating

Company: ILLUMINET (Formerly ITN and US Intelco)

Phone: 913­344 6259

Fax: 913469­0606

Message: Barry unless I missed something, this one was tremendously easy. If you think something needs to be added, please let me know. Rebekah

Disconnect Service for Potted Numbers

1. End User decided to disconnect service

2. End User notifies current service provider of desire to disconnect. The end user must provide disconnect date and negotiate intercept treatment with current Service Provider.

3. Current Service Provider establishes intercept treatment

4. Current Service Provider follows existing internal process flows to ensure the disconnect within their own systems and notifies NPAC/SMS of pending release date.

5. NPAC/SMS removes number from their database on the effective release date.

6. By way of the regularly scheduled data feeds, NPAC/SMS notifies the LSMS/SCP to return to default routing on the effective release date.

7. Ported number is returned to the original donor carrier from the NPAC.