AFFIDAVIT OF CHRISTOPHER J. VIVEROS

ON BEHALF OF PACIFIC BELL

TABLE OF CONTENTSPACIFIC OPERATIONS SUPPORT SYSTEMS AFFIDAVIT

SUBJECT PARAGRAPHCHRISTOPHER VIVEROS EDUCATION / PROFESSIONALEXPERIENCE

2

PURPOSE OF AFFIDAVIT 3ACT AND FCC REQUIREMENTS 4EXECUTIVE SUMMARY 5

OSS DEVELOPMENT, SUPPORT AND TRAINING6

· DEVELOPMENT AND TECHNICAL SUPPORT 6

· CUSTOMER SUPPORT AND TRAINING 18

· CHANGE MANAGEMENT 36

· FIREWALL 49

OSS FUNCTIONS56

· JOINT TESTING 61PRE-ORDERING 66

· STARWRITER 74

· SORD 75

· CESAR 76

· VERIGATE 77

· DATAGATE 80

· EDI/CORBA 84 ORDERING/PROVISIONING 87

· STARWRITER 89

· SORD 91

· EDI GATEWAY 93

· EDI DEVELOPMENT 103

· LEX 120

· LISTINGS AND E911 126

· EDI/LEX FLOW THROUGH AND FALL OUT 158

· NOTIFICATIONS 176

· RMI GATEWAY 190

· PBSM 195

· CESAR 197

· ORDER STATUS 200

· ORDER PROVISIONING CONCLUSION 203

ii

SUBJECT PARAGRAPH MAINTENANCE/REPAIR 205

· PBSM 206

· ELECTRONIC BONDING INTERFACE (“EBI”) 212 BILLING 223

· CUSTOM BILLING DISK / CD BILL 224

· MAG TAPE 226

· EDI 811 227

· BDT 229

· USAGE EXTRACT 230

· CRIS BILLING 236

· CABS BILLING 238

· BILLING RATE CHANGES 239

· BILLING DATES 240

· BILLING CYCLE 242

· BILLING TIMELINESS 245

· PACIFIC PARRTICIPATION IN OBF 246

· BILLING CONCLUSION 247

OSS TESTING261

CONCLUSION286

CHRIS VIVEROS AFFIDAVITTABLE of ATTACHMENTS

ATTACHMENTPacific Bell/Nevada Bell OSS Requirements Matrix -Summary of Electronic Interfaces Available via RAF

A

CLEC IDs Established by Month by Application BPacific’s ISCC CLEC Call Activity CPacific Bell Electronic Interfaces Demonstrations (Log) D“Access to OSS 90-Day Periods: 90-Day Evaluation and 90-Day Billing Waiver” - November 13, 1998 - CLECCS98-070

E

“Access to OSS 90-Day Periods: 90-Day Initial Start-Upand 90-Day Billing Waiver” - January 4, 1999 - CLECCS99-001

F

“Announcement Of General Availability Of ProvisioningOrder Status – California” - July 24, 1998 - CLECCS98-026

G

Pre-OSS Class Registration on a Stand-By Basis (Memo ofAgreement)

H

SBC Center for Learning Customer Satisfaction Survey(Level I Evaluation)

I

“Notification of Meeting Regarding CLEC Education –California” - October 22, 1998 – CLECC 98-112

J

Joint Settlement Agreement, January 19, 1999 K

Pacific Bell Competitive Local Exchange Carrier (CLEC)Interface Change Management Process, 12/08/98 Version

L

“Confirmation of 2Q99 Quarterly Change Management ProcessMeeting – California” - April 7, 1999 – CLECC 99-123

M

“Final Agenda and Working Documents 2Q99 Quarterly ChangeManagement Process Meeting – California” – April 21, 1999- CLECC 99-129 including Pacific Bell/Nevada Bell 12-Month Development View and Pacific/Nevada Flow-throughPlan – LEX/EDI

N

PACIFIC BELL - “Final Minutes From April 28, 1999, ChangeManagement Process Meeting” - May 25, 1999, includingthe Pacific/Nevada Bell Flow Through Plans – LEX/EDICLECC99-191

O

“Final Minutes From March 24, 1999, Follow Up ChangeManagement Process Meeting – California” – April 29, 1999- CLECC 99-142

P

PACIFIC BELL - “3rd Quarter 1999 Initial Requirements” -April 27, 1999 - CLECCS99-054

Q

“Final Minutes From January 27, 1999, Change ManagementProcess Meeting – California” - February 18, 1999 – CLECC99-051

R

INTENTIONALLY LEFT BLANK S

ii

Description of Data Security Between Authorized RetailCLEC and Wholesale Channels

T

Pacific Bell, Nevada Bell, Southwestern Bell LocalService Request (LSR) Electronic Data Interchange (EDI)Joint Test Plan, Version 6.0, Created 4/2/98

U

Flow Diagrams: Pacific Electronic Interfaces Availableto CLECs

V

Location of Documentation and When to Provide CLECs WCLEC Access Developer Reference Guide (DataGate) – West X“New Process for Assigning Due Dates on 2-Wire AnalogLoops – California” – CLECC 99-157, May 7, 1999

Y

Ancillary Services – CLEC Handbook, Section 1.0 - E9-1-1 ZLoop Quality Information Report including· Pacific ell DSL Qualification· March 9, 1999 E-Mail Correspondence· SBC Loop Qualification and Spectrum Management

Proposal· xDSL Pre-Order Qualification

AA

Pacific Bell Wire Centers Deploying ADSL – October 1,1998 - CLECC 98-093

BB

UPDATE: DATAGATE DOCUMENTATION - September 24, 1998 -CLECCS98-048

CC

UPDATE: SPECIAL VERIGATE RELEASE—Version 5.1.0 -September 21, 1998 - CLECCS98-047

DD

List of Offices with Loop Length Indicator Loaded onPREMIS

EE

Pacific Bell EDI 9 Pre-Order Meeting, September 23, 1998· OBF Issue 1278 Development Plans· Industry Committee Standards EDI Pre-Ordering Agenda· Order/Pre-Order Process Flows

FF

PACIFIC BELL – “Notice of Pending CESAR ISR Retirement” -May 4, 1999 - CLECCS99-057

GG

Pacific Bell - Verigate Competitive Local ExchangeCarrier (CLEC) Transaction Activity

HH

PACIFIC BELL –“ Pre-Ordering Source for Filling Out theLocal Service Request (LSR”) - March 5, 1999 – CLECCS99-029

II

Local Service Ordering Requirements (“LSOR”) Document JJPACIFIC BELL - “EDI Testing Key Learnings QuarterlyLetter” - February 19, 1999 - CLECCS99-021

KK

iii

PACIFIC BELL – “Final Requirements for June 26, 1999Release” - March 31, 1999, CLECCS99-046 and PACIFIC BELL- “Correction to Final Requirements for the June 26thRelease” - April 2, 1999, CLECCS99-047

LL

PACIFIC BELL - “1999 2nd Quarter Release Announcement” -December 11, 1998 - CLECCS98-084, Pacific Bell - “2Q99Release Comments” - January 11, 1999 – CLECCS99-003,PACIFIC BELL - “Initial Requirements for 2nd QuarterRelease” - February 17, 1999 - CLECCS99-018, PACIFIC BELL- “Final Requirements for June 26, 1999 Release” - March31, 1999 - CLECCS99-046

MM

PACIFIC BELL - “Digital Subscriber Line Ordering - LSR,LEX, EDI” - October 22, 1998 - CLECCS98-061

NN

“Digital Subscriber Line Ordering – LSR – California” -May 7, 1999 - CLECC 99-159

OO

ELI Meeting Announcement, CLECC 98-038 PPPACIFIC BELL - “1999 2nd Quarter Release Announcement” -December 11, 1998 - CLECCS98-084

QQ

“E911 Database: Changes in Process and Support –California” - April 1, 1999, including California “709Error” Job Aid - CLECC 99-111

RR

PACIFIC BELL - “Announcement of E911/Directory ListingFix-It Team Meeting” - October 9, 1998 - CLECCS98-054

SS

911 and Directory Listings Fix-It Team Meeting Minutes(10/15/98 – 10/16/98)with Appendix F, Non Disclosure Agreement

TT

9-1-1 Database CLEC Contact List UUCLEC E9-1-1 Database Forum Invite - February 16, 1999(Original Dated: January 22, 1999)

VV

Pacific Bell’s Database CLEC Users Forum(1st Quarterly E911 DB Forum Sign In Sheet)

WW

CLEC/Pacific Bell Forum, February 16, 1999(1st Quarterly E911 DB Forum Agenda)

XX

“E911 Database Services and Support – California” - March15, 1999 - CLECC 99-075

YY

E911 MCI Records, Correspondence, Dated April 09, 1999Subject: Migration of UNE (E911)

ZZ

PACIFIC BELL - “WEB BASED LISTINGS LOOK-UP” - August 28,1998 - CLECCS98-036

AAA

Update to the Web-based Listings Look-up ApplicationAnnouncement” - September 11, 1998 - CLECCS98-040

BBB

“E911 Enhanced File Transfer Specifications – California- May 17, 1999 - CLECC 99-173

CCC

PACIFIC BELL - “Announcement of June 26th Release Delay” - DDD

iv

May 28, 1999 - CLECCS99-068“Final Minutes From February 11, 1999, Special ChangeManagement Process Meeting – California” - March 16, 1999- CLECC 99-082

EEE

“Final Minutes From March 3, 1999 Change ManagementProcess Meeting on xDSL – California” - April 2, 1999 -CLECC 99-116

FFF

“Final Minutes form March 24, 1999, Follow Up ChangeManagement Process Meeting – California” – April 29, 1999- CLECC 99-142

GGG

Flow Through Principles xDSL, April 22, 1999 (Audit) HHHFLOW THROUGH EXCEPTION:SUPPS, Project Quantities, PartialAccount Conversions

III

LASR Real-Time Processing Comparison, Revision 1.0JJJ

LASR Real-Time Processing Portfolio Attachments· Business Requirements (Project Charter)· LASR Real-Time Processing Project, 10/16/98· Including: Diagram of the LASR Real-Time Release

12/19/98 and Four LASR Phases, Last Updated 6/08/98

KKK

LEX Specifications-LSR Exchange System, December 19, 1998Release

LLL

“Pacific Bell Quarterly Release Initial Notification” -July 28, 1998 - CLECCS98-028

MMM

PACIFIC BELL - “Revised Agenda For Quarterly ChangeManagement Meeting” - September 28, 1998, including the12 Month Development View - CLECCS98-051

NNN

PACIFIC BELL - “ENHANCEMENTS TO LEX - DECEMBER 19THRELEASE” - November 19, 1998 - CLECCS98-076

OOO

“Final Requirements for May 1st 1999 Release – California“- February 17, 1999 – CLECCS99-017

PPP

PACIFIC BELL - “Initial Requirements for 2nd QuarterRelease”- February 17, 1999 - CLECCS99-018

QQQ

Pacific Bell – PBSM Competitive Local Exchange Carrier(CLEC) Transaction Activity

RRR

Trouble Reports Received: May 1998 through April 1999 SSSPacific Bell Usage Extract Competitive Local ExchangeCarrier (CLEC) Message Activity, as of June 24, 1999

TTT

“Consolidated Bill Rounds”- CLECC 99-206 UUUPacific Bell OSS Test Plan, Version 1.0 VVVPacific Bell OSS Test Plan, Version 2.0 WWWPacific Bell OSS Test Plan, Version 3.0 XXX“E911 Database Forum – California” – May 27, 1999 – CLECC99-195

YYY

- 1 -

1. My name is CHRISTOPHER J. VIVEROS. My business address is

370 Third St., Room 514D, San Francisco, CA 94107. I am

Director-OSS Planning and Regulatory Support for Pacific

Bell (“Pacific”), a wholly owned subsidiary of SBC

Communications Inc. (“SBC”). In this position, I am

responsible for the planning and implementation

coordination of Operations Support Systems (“OSS”)

supporting Competitive Local Exchange Carriers (“CLECs”)

and for assisting Pacific’s Industry Markets organization

in implementing CLEC OSS functionality in a manner

consistent with Pacific’s arbitrated and negotiated

agreements, and the rules and regulations of the California

Public Utilities Commission (“CPUC”) and Federal

Communications Commission (“FCC”).

EDUCATION AND PROFESSIONAL EXPERIENCE

2. I attended California State University at Los Angeles,

majoring in Computer Science. I have 18 years experience

with Pacific. I have held numerous jobs in our Business

Marketing, Industry Marketing and Network Services

organizations.

PURPOSE OF AFFIDAVIT

3. The purpose of my affidavit is to describe how Pacific

complies with the OSS obligations contained in the

Telecommunications Act of 1996 (“the Act”), the FCC’s

requirements for providing CLECs with nondiscriminatory

- 2 -

access to OSS functions, and the CPUC rules for Local

Competition. I will also discuss recent OSS enhancements,

particularly in connection with Pacific's satisfaction of

all the OSS requirements identified by the CPUC in its 271

Collaborative Workshops and in Decision 98-12-069, dated

December 17, 1998 (“Final Decision”), Appendix B. I will

discuss the OSS functions that Pacific makes available to

its own retail service representatives and to the CLECs for

pre-ordering, ordering, provisioning, maintenance and

repair, and billing. I will demonstrate that Pacific has

met its obligation to provide CLECs with access to its OSS

functions equivalent to that which Pacific provides to

itself. Further, I will demonstrate that Pacific is

willing to and has, in fact, negotiated in good faith to

provide CLECs with other forms of access to its OSS

functions that are not available today (nor required) and

to implement them where technically feasible. Pacific has

exceeded its obligations by making available to CLECs

multiple interface choices within each OSS function, thus

enabling CLECs to choose the interfaces that best meet

their business needs. Moreover, Pacific, with the full

involvement of the CLEC community, has developed a

consolidated change management plan that covers both

application-to-application and graphic user interfaces.

This process ensures CLECs have a voice in the on-going

management of OSS functions and capability.

- 3 -

ACT AND FCC REQUIREMENTS

4. Both the Act and the FCC’s rules require ILECs to provide

CLECs with nondiscriminatory access to unbundled network

elements.1 The FCC has concluded that operation support

systems (“OSS”) are encompassed within the definition of

unbundled network elements.2 The FCC has also found that,

“in order to meet the nondiscriminatory standard for OSS,

an incumbent LEC must provide competing carriers access to

OSS functions for pre-ordering, ordering and provisioning,

maintenance and repair, and billing that is equivalent to

what it provides itself, its customers or other carriers.”3

As demonstrated herein, Pacific has met these requirements.

EXECUTIVE SUMMARY

5. Many of the following bullet items are covered in greater

detail later in my affidavit. However, it may be useful to

give a broader perspective on Pacific’s accomplishments in

facilitating CLECs’ access to our OSS functions. Pacific

is providing and making available multiple electronic

interfaces to CLECs. These interfaces provide CLECs a

meaningful opportunity to compete in the local exchange

market. Below is a brief summary of the major

accomplishments Pacific has made since the passage of the

Act:

1 See, e.g., 47 U.S.C. 251(c)(3); 47 C.F.R. § 51.311.2 Application of Ameritech Michigan to Provide In-Region, InterLATA Services,

CC Docket 97-137, Memorandum and Opinion, FCC 97-298, released August 19,1997, para. 130.

3 Id.

- 4 -

· Pacific provided six “real-time” access interfaces forpre-ordering functions, ahead of industry guidelines.Two interfaces (SORD and Starwriter) are the same systemsused by Pacific's own retail service representatives.The third application (CESAR) was developed from anexisting system used by Interexchange Carriers. Thefourth interface (Verigate) is a WindowsÔ based GraphicalUser Interface (“GUI”). The fifth (DataGate) is anapplication–to-application interface for those CLECs withtheir own presentation system or GUI. In addition,Pacific provides an industry standard Electronic DataInterchange (EDI) supporting two protocols (SSL3 andCORBA). Each of these interfaces supports both resaleservices and unbundled network elements, exceptStarWriter which supports residential resale servicesonly.

· Pacific has provided four primary interfaces forordering/provisioning functions. Two of theseapplications (SORD and Starwriter) are the same systemsused by our own retail service representatives andinclude integrated pre-order functions. Two otherinterfaces (LEX and EDI) conform to current industryguidelines and were developed specifically for the CLECs.Of the two industry conforming interfaces, one is aWindowsÔ based GUI (LEX), while the other is anapplication-to-application gateway (EDI). Both supportresale services and unbundled network elements. SomeCLECs are still using a pre-industry guideline gateway,Resale Mechanized Interface (“RMI”).

· RMI and CESAR have processed significant volumes to dateproving their viability. The RMI gateway has processed451,952 requests for resale services between April 1997and May 1999, and the CESAR system has handled 221,422unbundled network element, number portability, and localinterconnection trunk requests/supplements from over 46

- 5 -

CLECs between July 1997 and May 1999.

· Pacific’s two additional proprietary interfaces, SORD andStarwriter, are well-established and tested. Pacific’sown retail service representatives have used SORD andStarwriter for many years. On average per day, SORDprocesses 125,000 orders and Starwriter processes 50,000orders.

· Pacific’s industry standard interfaces, LEX and EDI, wereimplemented in March 1998 for UNE, and May 1998 forResale. Together, they have processed nearly 100,000requests/supplements since implementation.

· Pacific has also provided a GUI application calledProvisioning Order Status (“POS”) that provides CLECswith the status of their dispatched service orders.Between July 1998 and May 1999, 573 transactions havebeen processed.

· Pacific has provided two “real-time” interfaces formaintenance/repair functions. One (PBSM) is an on-lineinterface used by both retail and wholesale customers.The other (EBI) is an application-to-applicationelectronic interface conforming to industry standards.Both interfaces support resale services and unbundlednetwork elements.

· Pacific has provided five electronic interfaces foraccess to billing information for resale services andunbundled network elements. These options range fromviewing and obtaining bills electronically tomechanically receiving daily usage data feeds.

· Pacific has established a dedicated secure accessfacility with a fault tolerant firewall for CLEC entryinto Pacific’s OSS.

· Pacific has developed flow through (automatic ordergeneration without manual intervention) for Local ServiceRequests (“LSRs”) for those products where CLECs have

- 6 -

either demonstrated or forecasted significant volumes.

· Pacific provides for joint testing with CLECs during theCLECs’ development of application-to-applicationinterfaces and/or when Pacific’s systems enhancements arebeing implemented.

· Pacific has established a number of support organizationsspecifically designed to serve the CLECs. These supportorganizations include the Local Service Center (“LSC”),Local Operations Center (“LOC”), Information Systems(“IS”) Call Center, and the OSS Wholesale CustomerSupport Team. The LSC serves as the single point ofcontact for CLECs for questions relating to pre-ordering,ordering/provisioning, and billing and collection. TheLOC is responsible for provisioning CLEC orders as wellas the coordination of all maintenance/repair activities.The Tenerelli and Murray Affidavits describes thestructure and operation of the LSC and the LOC in moredetail. The IS Call Center provides CLECs assistance andproblem resolution for systems and applications madeavailable to CLECs. The OSS Wholesale Customer SupportTeam was established to assist CLECs with OSS selection,connectivity, development support, implementation andissues management.

· Pacific has provided “live” demonstrations to CLECs ofPacific’s OSS. To date 36 CLECs have participated in theOSS demonstrations. Demonstrations have also beenprovided to the Commissioners, Staff and Advisors of theCPUC, the FCC, the California Legislature, the Departmentof Justice, and the General Accounting Office.

· Pacific has developed formal classroom training for CLECsthat opt to utilize electronic interfaces. To date, 731CLEC employees representing 38 CLECs have been providedwith training on Pacific’s OSS.

· Pacific has provided CLECs detailed documentation,

- 7 -

specifications, and business rules applicable to thePacific electronic interfaces made available to them.Pacific assures CLECs receive the applicabledocumentation for interfaces, and all subsequentrevisions.

· Pacific has developed OSS performance measures todemonstrate whether it is providing nondiscriminatoryaccess between retail operations and the interfaces madeavailable for CLEC use. Details of our performancemeasures are discussed in the Johnson Affidavit.

· As of May 31, 1999, Pacific has 78 interconnectionagreements with CLECs, 68 of which have been approved bythe Commission.

· Pacific has spent over $88 million since the passage ofthe Act in support of CLEC access to Pacific’s OSSfunctions in Pacific’s Information Services organizationalone.

· An OSS Interface Test will be performed under thedirection and guidance of the CPUC. The OSS Master TestPlan (“MTP”) has been developed via an exhaustiveiterative process culminating in the CPUC OSScollaborative workshops and issuance of the ACR and DraftOSS MTP Version 3.0 June 29, 1999.

· Pacific has accommodated the needs of CLECs bynegotiating the implementation of interim orderingarrangements for a variety of electronic interfaces, suchas RMI and CESAR, prior to the establishment of nationalguidelines. Ahead of industry guidelines, Pacific andCLECs have jointly developed a Change Management Process(“CMP”) for the communication and management of OSSfunctionality enhancements.

- 8 -

OSS DEVELOPMENT, SUPPORT AND TRAINING

Development and Technical Support

6. The California Public Utilities Commission (“CPUC”) was

aggressively promoting local competition well before the

passage of the Act. By the end of 1995, the Commission had

already established interim local competition rules,

including interconnection rules for facilities-based

providers, bill and keep rules as an interim approach to

reciprocal compensation, and number portability rules. By

the time the Act was signed into law on February 8, 1996,

much of the groundwork for local competition had already

been laid in California. As a result, Pacific had already

entered into negotiations and reached interconnection

agreements with several CLECs before the issuance of the

FCC’s First Report and Order on August 8, 1996.4 Throughout

that process, Pacific shared its plans and received

feedback from the CLECs on their needs for electronic

interfaces. The development of processes and systems to

support the provisioning of resale services and unbundled

network elements was a monumental task that was further

complicated by having to begin this work in 1995, long

before the complete requirements had been defined by the

FCC, and while interconnection agreements were still being

negotiated.

4 In The Matter of Implementation of the Local Competition Provisions in theTelecommunications Act of 1996, CC Docket 96-98 and 95-185, First Reportand Order, FCC 96-325, released August 8, 1996.

- 9 -

7. Because Pacific’s OSS would need to be used in a manner for

which they were not originally designed, many changes

(i.e., edits, data stores, etc.) also were required for

several “back-office” systems so that orders for resold

services and unbundled network elements by CLECs would be

fully processed and provisioned. Enhancements were also

made to the front-end systems with which the CLECs would

directly interface. By the time the FCC's First Report and

Order was issued, Pacific had already started developing

those electronic interfaces. Pacific has continually

expanded access to its OSS functions.

8. To provide CLECs with a secure, single point of entry for

gaining access to Pacific’s OSS functions, Pacific has

developed a Remote Access Facility (“RAF”). Internal

testing of the RAF began in July 1997 and went into

production in January 1998. Once connected to the RAF,

CLECs pass through a security “firewall” that prevents

unauthorized access to and from Pacific’s internal

communications network. The additional time attributable

to use of the RAF and this firewall by CLECs as compared to

Pacific’s own internal access is measured in milliseconds.

Some OSS functions do not require access through the RAF

due to the nature of the interface or function. For

example, the RMI Gateway already has existing facilities in

place for its CLEC users. A complete list of the OSS that

are accessible via the RAF is included in the “Summary of

Pacific Electronic Interfaces.” Viveros Attachment A.

- 10 -

9. There are basically two ways to access Pacific’s OSS

applications via the RAF: dial-up connection and direct

connection. The dial-up connection is initiated in the

same manner as someone dialing into an Internet Service

Provider (e.g., Pacific Bell Internet, America On-Line,

Microsoft Network) to access the Internet or to get

personal email. While most dial-up connections are analog

across the switched network, a few CLECs access the RAF

using an ISDN connection. To initiate the direct

connection, a CLEC provisions a private circuit between its

location and Pacific’s RAF in Fairfield. This circuit can

range from a 56 kb digital circuit, up to a full T1,

including frame relay. The direct connection method

provides much greater bandwidth and allows one connection

to support multiple users.

10. Utilization of the two connection types is measured and

monitored by the Network Operations group in Fairfield to

ensure that capacity is increased to meet CLECs’ needs.

For the “modem pools” in Fairfield, the network routers

behind the modems are polled every 5 minutes for

utilization. This data is analyzed monthly for trends and

capacity concerns. There are currently 92 analog/ISDN

ports available. Although the remote access facility is

not close to reaching capacity utilization, the network

operations group is in the process of switching the

hardware equipment to increase the capacity for dial-up

connections almost 300%. Pacific is confident of its

- 11 -

monitoring ability and that more than sufficient capacity

is available to serve the CLECs.

11. For the direct and private circuit connections, all traffic

currently runs through 2 routers. Traffic and capacity

utilization is monitored via a network tool called

Enterprise PRO (“EPRO”). EPRO provides reports that show

utilization, peak times, and other usage information.

Currently, CLECs have established 18 private line or direct

connections to the RAF and 5,060 user identifications have

been issued to CLECs. Pacific is also in discussions with

other CLECs that have expressed interest in learning how to

access our OSS. Viveros Attachment B provides empirical

data by month and year of the number of user

identifications issued to CLECs beginning in April 1998 for

use in “live” and evaluation modes.

12. Initially Pacific provided support to CLECs through the

CESAR Customer Support Group (“CCS”). (CESAR is a pre-

ordering and ordering system described later in this

affidavit.) The CCS provided individual user IDs and

written logon instructions for CESAR, as well as password

resets and logon assistance for CESAR, PBSM, and the

Listings Gateway. The CCS also provided assistance with

connectivity, as well as assistance on establishing profile

information for the CLEC Handbook and the CESAR pre-

ordering system. The CCS fielded many questions on

additional topics and functioned as a bridge between CLEC

- 12 -

employees and Pacific’s LSC, account teams, and other

technical support groups as needed.

13. On March 9, 1998, the IS Call Center (“ISCC”) assumed

CLEC-support responsibilities from the CCS5. The goal of

the ISCC is to provide a single point of contact to the

CLECs accessing Pacific’s OSS via the RAF for resolution of

OSS interface questions and issues. The ISCC provides

these services Monday through Friday from 5 a.m. to 7 p.m.,

and Saturday 6 a.m. to 3 p.m. All other hours are covered

via pagers that are activated by voice mail ensuring

assistance twenty-four hours a day, seven days a week.

14. The ISCC uses a problem and change management tool called

Vantive to record and categorize the types of OSS trouble

calls received by the ISCC from CLECs. Viveros

Attachment C provides empirical data by month and year of

the types of calls, segregated by specific categories, and

recorded by the Vantive tool for the ISCC. The data begins

in March 1998 when Pacific implemented its first phase of

additional OSS offerings. The data reveals that Pacific’s

applications are not the source of the vast majority of

CLECs calls. In fact, most of the calls relate to CLEC

user problems associated with easily correctable

situations, such as the resetting of user identifications

and passwords or reminders regarding proper use of

Pacific’s systems.

5 CCS continues to support CLECs currently accessing OSS via connectionsoutside of the RAF.

- 13 -

15. To further support CLECs, the ISCC has developed a secure,

password-protected web page CLECs can view while

simultaneously accessing Pacific OSS through the RAF. The

web page provides an online method for getting information

from and communicating information to Pacific. The web

page was Beta tested with a CLEC and was subsequently made

generally available to the CLEC community on January 1,

1999.

16. The ISCC Web site consists of seven individual sites

relating to Pacific’s OSS. The ISCC Web site was designed

with one purpose in mind, to provide the CLECs with an

additional resource that will assist in troubleshooting the

most common problems quickly and easily. This web site,

when used to its full potential by a CLEC, can be a

powerful tool in eliminating problems that may arise while

accessing Pacific’s OSS.

17. The ISCC site provides access to:

1) PB/NB OSS containing Pacific Bell / Nevada Bell

OSS Requirements Matrix – a guide to hardware and

software requirements for connectivity, and available

hours of operation.

2) OSS Letters which contains all OSS Accessible

Letters sent to CLECs, sorted by month and then posted

numerically by Accessible Letter Number, also includes

most recent letters posted.

3) PB/NB User ID containing CLEC Security Policies

And Guidelines for PB/NB.

- 14 -

4) System Status providing status messages that will

reflect: 1) whether an application is down or

restored, 2) the geographical region that is affected

and 3) the approximate time the status message will be

updated. This screen is refreshed at 60-second

intervals.

5) Feedback which provides an e-mail format for CLEC

feedback.

6) RAF containing information on logging into the RAF

for each PC operating system supported.

7) Job Aids containing OSS interface documentation,

e.g., GUI User Guide.

Customer Support and Training

18. In an effort to stimulate CLEC interest in and use of

Pacific’s electronic interfaces, Pacific has provided

“live” demonstrations of its electronic interfaces to

regulators, legislators, and all interested CLECs,

including AT&T, MCI WorldCom, and Sprint. Pacific’s

preparation for the OSS demonstrations involves securing

communications connectivity, facility set-ups, and personal

computer and software arrangements. Presentations have

been performed in several cities, requiring the

coordination and the technical expertise of the ISCC, and

of connectivity and interface specialists. These are the

same experienced individuals that assist CLECs to establish

and deploy connectivity to Pacific’s OSS. At considerable

- 15 -

expense, Pacific has offered and provided demonstrations to

every CLEC that has shown an interest in learning about

Pacific’s electronic interfaces. A listing of CLECs who

have completed demonstrations is provided as Viveros

Attachment D.

19. After a CLEC makes a decision to utilize an OSS, Pacific

and the CLEC negotiate an OSS Appendix to their

interconnection agreement, since OSS has been determined to

be a UNE. In some cases the OSS Appendix is a standalone

document (e.g., a Reseller purchasing from the tariff).

The OSS Appendix captures the appropriate terms,

conditions, and pricing for use of Pacific’s OSS. During

the 271 Workshops, Pacific and the CLECs negotiated a

template to be used as a starting point for OSS

negotiations. This template was approved with minor

modifications by the CPUC in its Final Decision. App. B,

pp. 5-6; FSR, App. D. Pacific put into practice and made

this template available to its Account Managers prior to

the Commission’s Final Decision. App. B, p. 5. Several

OSS appendices have been negotiated with this template.

These appendices include Optel, filed January 25, 1999,

Computer Business Sciences, filed May 7, 1999, Option One,

filed May 11, 1999, Prepaid Phones, filed May 11, 1999,

Cox, filed May 13, 1999, Ernest, filed May 20, 1999, and

Total Media filed May 21, 1999. Two other CLECs, GTE and

TCG, utilized portions of the template in their

negotiations.

- 16 -

20. Pacific offers, at no charge, two 90-day promotional

periods for access to Pacific’s OSS. These 90-day periods

are available to any CLEC that has opted to deploy any of

the electronic OSS interfaces offered by Pacific, following

CPUC approval of their interconnection agreement with terms

and conditions for access to OSS. These two 90-day periods

are defined as:

· 90-Day Initial Start-Up Period - A “practice period” atthe initial turn-up of each electronic OSS, preceding useof the OSS in a “live production” mode.

· 90-Day Billing Waiver - A temporary promotional offer towaive the first 90 days of billing applicable OSS rates.Once the CLEC implements the electronic OSS in a “liveproduction” mode, it is eligible for the OSS billingwaiver.

21. These evaluation periods are offered for CLECs to test

connectivity to the interfaces, evaluate system

functionality, and utilize training databases to determine

how they will integrate interface functionality to meet

their business needs.

22. During the 271 Workshops, Pacific agreed to notify CLECs of

its two 90-day promotional offerings for OSS access via an

accessible letter, and also agreed to provide 14-days

notice prior to withdrawing the offer. App. B, p. 6; OSS

WS Agreement 1.10.1. Pacific first notified the CLECs of

these two offerings in an Accessible Letter, CLECCS 98-070,

dated November 13, 1998. Viveros Attachment E. This

letter describes each offering: 90-Day Evaluation and 90-

- 17 -

Day Billing Waiver. A second Accessible Letter, CLECCS 99-

001, dated January 4, 1999 was sent to the CLECs renaming

the first offering 90 Day Initial Start-Up Period. Viveros

Attachment F. The revised document, CLECC 99-001, explains

that Pacific will not withdraw these promotional offers

without providing at least 14 days advance notice. As of

July 15, 1999 Pacific continues to make these promotional

offers available.

23. Pacific offers a series of workshops and OSS classes for

employees of CLECs to help CLECs learn how to pass accurate

orders for telecommunications services offered for resale,

unbundled network elements, interconnection, and number

portability. Information regarding customer education is

available on the “CLEC Online” website (https:/sbc.com/)

“Customer Education.” This site includes 1999 Class

Schedules, an Overview, How To Register, Memo of Agreement,

list of Workshops, Learning Center Locations, list of OSS

Classes, CLEC Education Rates, and Driving Instructions to

Learning Center Locations.

24. The workshops offered cover operational information that is

required for both manual and electronic ordering processes.

Workshops are free to six employees per CLEC, and certain

workshops are prerequisites to OSS classes. OSS classes

are available at a nominal charge to CLECs for pre-

ordering, ordering, provisioning, repair/maintenance, and

billing information functions. OSS classes focus on how to

use specific systems.

- 18 -

25. Before each new OSS application is deployed, or when

enhancements are made to existing interfaces and made

available to CLECs, training is developed at the direction

of Pacific by the Center For Learning (“CFL”). Consistent

with the agreement made in the 271 Workshops, Pacific will

issue an accessible letter declaring a system to be

“generally available” only after training is available as

was the case with Pacific’s new Provisioning Order Status

(“POS”). OSS Agreement 1.10.3. See Accessible Letter

CLECCS 98-026, Viveros Attachment G. POS was a new

interface offering that, as a Windows-based GUI, could

provide OSS access for obtaining provisioning status on

basic exchange field work orders. “POS” training, while

not a requirement prior to its use, was developed in tandem

with the GUI development and incorporated into the Toolbar

training.

26. All workshops and classes are “train the trainer” format so

that the trained CLEC representatives can return to their

business with the information to, in turn, instruct other

CLEC employees as appropriate to their business needs.

Each attendee is provided with a student guide, job aids

and reference materials. An additional clean paper copy of

the instructor guide, the student guide, and any job aids

are provided to one representative from each attending

CLEC. In addition, many of the reference materials used in

training are available on the CLEC website.

- 19 -

27. In the 271 Workshops, Pacific reinforced its commitment to

CLECs and the Staff to offer hands-on training for any

Graphical User Interface (“GUI”) offered by Pacific. OSS

WS Agreement 1.10.4. All training classes are hands-on,

whereas most demonstrations are not suitable for hands-on

training.

28. Pacific currently offers 13 workshops, at no charge, in

addition to 17 classes on OSS with a nominal fee charged to

each participant attending the formal, instructor-led

class. OSS classes are required for any OSS that affects

the network, e.g., LEX. Certain classes have prerequisite

workshops. The fee varies based on the number of students

and the length of the training session. The fee covers

facilities, terminals, and instructional materials

including instructor guide and student guide.

29. All workshops and training classes are available to CLECs

that have signed and filed interconnection agreements or

resale-only agreements, or are certified to sell out of the

resale tariff in California. A training schedule is posted

in the CLEC website (https://clec.sbc.com at Training). As

a result of the 271 Workshops, Pacific agreed to offer a

Memorandum of Agreement covering training independent of

the full OSS Appendix for those CLECs not ready to sign a

full OSS Apendix. App. B, p. 5. The MOA can be used to

reserve seats for workshops and OSS classes. The completed

MOA is due 12 days prior to a scheduled workshop or class

and registration is due one week prior to the start date.

- 20 -

Viveros Attachment H details the terms and conditions of

training, including but not limited to available courses,

costs, and training materials provided. Between December

1, 1998 and May 31, 1999, ten CLECs have utilized the MOA,

training 23 of their employees in Pacific’s OSS interfaces.

OSS WS Agreement 1.9.1.

30. Enrollment priority is given to CLECs who have not yet

attended a class on a specific application. CLECs who have

already been trained can reserve remaining available seats.

Pacific has worked with CLECs to combine multiple CLECs in

one class to help defray costs. FSR, p. 52-53. If the

CLEC wishes to send less than the minimum class requirement

of five (5) students, it has the option to combine with

other CLECs as stated in the MOA. Viveros Attachment H.

Pacific’s Account Managers and the OSS Wholesale Customer

Support Team facilitate their customers in combining class

attendees. For example, the participants in the CESAR

Training of January 7-8, 1999 were Teligent, GTEC, ICG, and

Choctaw; in the CESAR Training on February 22, 1999 the

participating CLECs were First World and AT&T.

31. Pacific has a very effective training feedback process.

App. B, p. 6. As part of the workshops and classes,

Pacific trainers proactively solicit the comments and

suggestions of all CLEC participants. To continuously

improve the training offered to our customers, the trainers

also furnish an anonymous Customer Satisfaction Survey to

each attendee at the end of the course. The survey focuses

- 21 -

on the effectiveness and efficiency of each

course/workshop. Viveros Attachment I. The overall

satisfaction rating on the course work conducted since

January 1998 stands at 99 percent, with 85 percent at least

very satisfied or extremely satisfied. In addition,

Pacific’s Account Managers are always available for input

and comments from the CLECs attending training.

32. Pacific continues to expand the type and variety of class-

work offered to CLECs in support of OSS business needs. As

a result of the 271 Workshop, Pacific agreed to host a

meeting to discuss training issues with the CLECs. WS

Agreement 1.10.2. Meeting notification was made via

Accessible Letter CLECC 98-112, distributed October 22,

1998. Viveros Attachment J. The first formal customer

meeting to address CLEC education issues was held in San

Francisco on November 11, 1998. The goal of the meeting

was to identify improvement opportunities so that Pacific

might better understand CLECs' training needs. Topics

covered the current Pacific offerings of 13 workshops and

17 OSS classes available. All boarded expectations from

the customers in attendance were documented and met. The

attendees further agreed that half-day meetings every six

months would be adequate going forward. A second meeting

was held on May 13, 1999.

33. Once CLECs complete their OSS training and are ready to

deploy the Pacific electronic interfaces, Pacific makes its

Wholesale OSS Customer Support team of application and

- 22 -

information services experts available to CLECs for on-site

premises visits, at no charge to the CLECs. These visits

are designed to help the CLECs minimize start-up problems

that invariably occur when companies deploy new software

applications. These experts are there to bring about quick

resolutions to questions, problems, and operational

concerns as CLECs deploy these interfaces.

34. In addition to providing student and instructor guides for

“train the trainer” format instructor-led classes, a

variety of documentation is available via Pacific Account

Managers and electronically via the ISCC web site to

support documentation provided in classes. This

documentation includes hardware/software requirements,

unique product information and the Local Service Ordering

Requirements (“LSOR”), and Local Service Pre-ordering

Requirements (“LSPOR”).

Change Management

35. Pacific recognizes that OSS interface development is an

evolutionary process, and Pacific will continue to refine,

and improve its OSS capabilities and corresponding

documentation to meet the ever-changing needs of its CLEC

customers. Many of these changing needs are identified

through an industry base control process that is driven by

national guidelines at the direction of OBF. Pacific has

also developed a comprehensive Change Management Process in

- 23 -

advance of an industry standard and with full participation

and cooperation of the CLECs.

36. The CPUC Staff, through its participation in the Order

Instituting Investigation (“OSS OII,” R.97-10-016,

I.97-10-017) and the 271 Workshops, is familiar with

Pacific’s Change Management Process. The FSR noted that

the Change Management “agreement represent[s] a

comprehensive plan to cover almost all issues related to

change management.” FSR p. 42. At the conclusion of the

271 Workshops, participants continued to work to resolve

certain issues including: introduction of new interfaces,

retirement of “old” interfaces, enforcement of the Change

Management Process (OSS WS Agreement 1.6.1), and dispute

resolution. FSR p. 45, see also p. 6. Subsequently,

Pacific hosted a Settlement Meeting on October 29, 1998

that resulted in the drafting of a Joint Settlement

Agreement (“JSA”). Viveros Attachment K. The JSA,

submitted to the Commission on January 20, 1999, and

pending approval, contains the Change Management Process

Document. Viveros Attachment L. The JSA incorporates

language agreed to by the parties in prior meetings of

August 17, September 1, and September 24, 1998. OSS, WS

Agreement 1.6.1A. The JSA serves as the framework for

Pacific’s comprehensive Change Management Process.

37. Pacific’s Change Management Process covers both

application-to-application and GUI interfaces. Covering

both types of OSS interface streamlines the CLECs’

- 24 -

evaluation process by providing a single venue to address

the CLECs’ concerns and recommendations. This provides

consistency in communicating OSS interface changes to

Pacific’s CLEC customers.

38. The focal point of Pacific’s process is the Quarterly

Change Management Process (“QCMP”) meetings. OSS WS

Agreement 1.6.1B. Instituted during the 271 Workshops,

QCMP meetings serve as the vehicle for Pacific and the

CLECs to introduce and discuss changes to Pacific’s OSS

interfaces. Pacific hosted the inaugural meeting on

October 28, 1998, prior to the finalization of the JSA and

Change Management Process Document. Two subsequent

quarterly meetings have been hosted by Pacific on January

27, 1999 and April 28, 1999, with additional meetings

scheduled for July 28, 1999 and October 27, 1999.

39. Pacific invites all CLECs to attend and actively solicits

their input for QCMP meeting agenda items. Notification is

accomplished via Accessible Letter, such as CLECC 99-123,

dated April 7, 1999, which announced the 2nd Quarter 1999

QCMP meeting Viveros Attachment M. The letter confirms

date, time and location of the meeting, provides a draft

agenda, and requests input to the agenda. CLECs are

provided an opportunity to shape the agenda. The finalized

agenda, along with any necessary working documents are then

distributed in a subsequent Accessible Letter. See CLECC

99-129, Viveros Attachment N.

- 25 -

40. During QCMP meetings, CLECs have the opportunity to review

the scheduled improvements to Pacific’s OSS interfaces.

Aiding this process is a 12-Month Development View provided

by Pacific. This document provides a rolling calendar of

OSS modification or enhancement projects tentatively

scheduled in the next 12 months. The 12-Month Development

View is distributed as a working document via Accessible

Letter, such as CLECC 99-129, dated April 21, 1999. Viveros

Attachment N. This review encourages planning and promotes

meaningful discussion between Pacific and the CLECs.

Pacific also agreed in the 2nd Quarter CMP meeting to

provide the Pacific/Nevada Bell Flow Through Plans-LEX/EDI

document to facilitate discussion of Pacific’s future flow

through development. CLECC 99-191 Viveros Attachment O –

Final Second Quarter QCMP. In addition to the review of

scheduled OSS interface changes, opportunity is provided

for CLECs to submit their own agenda items for discussion.

41. When issues are raised during the QCMP meetings that

require more focused attention, sidebar meetings are

scheduled between Pacific and the interested CLECs.

Results of these meetings are distributed to all CLECs via

Accessible Letter and discussed in subsequent QCMP

Meetings. An example of this process would be the

discussion of flow-through issues scheduled for the January

27, 1999 QCMP meeting. The Final Minutes of that meeting

(CLECC 99-051, published on February 18th), approved by all

participants, state "AT&T indicated that it was impossible,

- 26 -

from its point-of-view, to do justice to a discussion of

[flow-through] at this Quarterly Change Management

[Process] meeting. AT&T also suggested that it was

necessary to establish a separate meeting for the sole

purpose of discussing flow-through. Such a sidebar meeting

was established before the January QCMP meeting adjourned,

for February 11, 1999 to be hosted by Pacific. Action

items for Pacific, for the CLECs, and for the two parties

jointly, were established at the February 11 meeting, and

follow-up meetings on a variety of flow-through issues were

established for February 26, March 3, and March 22, 1999.

"Final Minutes from February 11, 1999, Special Change

Management Process Meeting - California", CLECC 99-082,

published March 16, 1999. Moreover, the issue of flow-

through is discussed as part of the 12-Month Development

Plan reviewed by Pacific and the CLEC community at every

QCMP.

42. Draft QCMP meeting minutes are first circulated among

meeting participants to ensure an accurate and complete

representation of the meeting. Final minutes are

distributed to all CLECs via Accessible Letter. Accessible

Letter CLECC 99-191, dated May 25, 1999, provides an

example of a QCMP meeting’s final minutes. Viveros

Attachment O. This allows even non-attending CLECs the

opportunity to remain current on the issues being

discussed.

- 27 -

43. Pacific recognizes the value of the Change Management

Process in promoting meaningful interaction with the CLECs

regarding OSS issues. This interaction promotes increased

responsiveness to CLEC requests. An example of this would

be the planned implementation of flow through for xDSL

capable loop requests where the loop length is greater than

12,000 feet from the serving central office. Raised by MCI

WorldCom in a sidebar CMP meeting on February 11, 1999

Pacific agreed to research the feasibility of flow through

and discuss further in a follow-up sidebar meeting on March

24, 1999. This discussion centered on Pacific’s proposed

design that would make it possible for the CLEC to advise

Pacific when the loop pre-qualification had been performed

for xDSL-capable loops greater than 12,000 feet. CLECs

would provide the Transaction Identification (“TRANS ID”)

from the completed pre-qualification process allowing the

request to be eligible for flow through. CLECs concurred

with the proposed design and Pacific agreed to include this

additional functionality in a future release. The final

minutes of the March 24, 1999 meeting are contained in

Accessible Letter CLECC 99-142, dated April 29, 1999.

Viveros Attachment P. The inclusion of xDSL flow through

for loops less than 12,000 feet is published in the Initial

Requirements for the 3rd Quarter 1999 release, and is

included in Accessible Letter CLECCS 99-054, dated April

27, 1999. Viveros Attachment Q.

- 28 -

44. The facilitation of dialogue with CLECs through the Change

Management Process is further evidenced by discussions

about versioning. In its Final Decision, the Commission

directed Pacific and the CLECs to develop a process to

address versioning.6 FD, p. 105. Pacific continues to

actively participate in industry forums that seek to

establish national standards for versioning. Pacific and

other industry forum participants report the status of

these efforts at the QCMP meetings. During the January 27,

1999 QCMP meeting, Pacific reported the latest insights

into OBF discussions on versioning. Accessible Letter

CLECC 99-051, dated February 18, 1999 contains a summary of

Pacific’s report. Viveros Attachment R. Pacific committed

to recommend that the OBF establish a full committee to

work on versioning issues. The CLECs agreed with Pacific

that currently it was premature to hold sidebar meetings on

versioning.

45. Pacific is committed to the continued success of the Change

Management Process. This commitment is reflected by:

· Pacific’s hosting and participating in each regular QCMPmeeting conducted since the inauguration on October 28,1998.

· Pacific’s hosting and participation in many sidebarmeetings.

· Creation of the 12-month Development View.

· Accessible Letters announcing releases, supplying initialand confirmed/revised requirements beginning with the

6 “Versioning” refers to the rules or procedures for introducing new versionsand retiring previous versions of the same application.

- 29 -

December 19, 1998 release.

· Accessible Letters announcing the retirement of aninterface (RMI) and the availability of new interfaceprotocols (EDI SSL3 and CORBA).

· Pacific’s ongoing discussions to evolve to a 7-stateprocess in the year 2000.

46. Even invoking the Exception Process when notice or testing

timeframes were reduced, reflects Pacific’s commitment to

follow the process as defined. Both Pacific and the CLECs

have been extremely cooperative and collaborative while

dealing with the invocation of the exception process

necessary in the 1999 transition year. Pacific has adopted

the Change Management Process fully following all of its

terms and conditions even though approval of the JSA is

still pending. App. B, p. 5; WS Agreement 1.1.1.

Firewall

47. Pacific has implemented an effective firewall between

wholesale and retail information. App. B, p. 5. Pacific

provides a systems platform for retail and wholesale users

with user ID tracking mechanisms in place to track and

monitor access and activity in those applications with

customer account information, i.e., SORD and BOSS. Entry

into these systems is done through a sequence of security

and authorization steps.

48. Tracking has been established to identify each retail and

wholesale user and match them to a pre-established profile

which determines which applications and customer data the

user has permission to access.

- 30 -

49. Security agreements, which indicate the proper use of

customer data, must be signed by every retail and wholesale

user who has access to customer account information. CLECs

sign a Joint Interface Agreement (“JIA”) and Pacific Bell

service representatives sign a Code of Business Conduct

agreement. Violation of Pacific’s Code of Business Conduct

can result in termination of employment for Pacific Bell

users.

50. Once a user profile has been established and the security

agreement has been signed, a password is established for

the user. To gain systems access at specific points of

entry, both retail and wholesale users are prompted to

provide a user ID and password.

51. Finally an audit trail exists that monitors activities in

SORD for both retail and wholesale users that tracks

positive responses to the SORD user authorization screen by

User Group (CLEC or Pacific) and specific user ID.

52. In the SORD application, which is the primary repository of

customer account data, an audit trail is created when

employees view an account belonging to another company.

Each time an employee reviews another company’s customer

account information, the occurrence is recorded and stored

in a data base repository. This information can be

retrieved upon request. BOSS is Pacific’s billing system

and is therefore only available to retail representatives,

who can only view retail data. The PREMIS application

- 31 -

holds customer location information only and thus does not

have an audit trail.

53. In order to allow for a more accurate migration from one

service provider to another, retail and wholesale service

representatives have limited access to customer data from

other companies. In the course of conducting day-to-day

business activities between companies, the viewing of other

companies' data often makes the transition go more smoothly

for the customer. Authorization from the customer must

first be obtained prior to the viewing of customer account

information of another company. Attached is a description

of data security between authorized retail, CLEC and

wholesale ordering channels that provides a description of

what customer account information in SORD, BOSS, and PREMIS

can be viewed by Pacific representatives and CLECs. Viveros

Attachment T.

OSS FUNCTIONS

54. This section describes in detail the OSS options that

Pacific has made available to the CLECs. Pacific has

delivered on its obligation to provide OSS access to all

CLECs, not just the large CLECs. Across all functions,

Pacific provides a variety of electronic interface

solutions. There are both proprietary interfaces,

including GUIs developed by Pacific that CLECs may begin

using quickly, and application-to-application interfaces

based upon industry guidelines, where available, that allow

- 32 -

CLECs to build their own custom user software. Pacific’s

development of both types of interfaces is an important

accommodation for the various business plans of CLECs and

their needs to interface electronically.

55. Pacific provides CLECs with multiple options of electronic

interfaces for access to its OSS functions depending upon

their business needs, which may vary based upon transaction

volumes and the information services resources of their

company. Pacific may make additional interfaces available

as negotiated and provided for in interconnection

agreements with individual CLECs.

56. The process of making interfaces operationally ready,

depending on whether the interface exists or is new,

involves modifying front end and back office systems,

testing the modifications, developing new interfaces or

functionalities as required or requested by CLECs, testing

of the new interface internally and in conjunction with our

back office systems, and sizing the interface to ensure

forecasted volumes can be adequately and timely processed.

Pacific has performed all these functions.

57. With respect to the electronic interfaces Pacific is making

available to the CLECs, several were operational and used

for processing service orders for Pacific’s retail

residence, business, and interexchange carrier customers

prior to the passage of the Act. Therefore, Pacific has

actual experience with the capacity of these electronic

interfaces and systems. Others were developed specifically

- 33 -

for CLEC access and Pacific has performed tests to

determine the scalability of these electronic interfaces

and systems. In addition, the independent third party OSS

test, described later in the affidavit, will provide

additional evidence of Pacific’s commercial readiness.

58. Since Pacific is offering the CLECs some of the same front

office systems Pacific uses itself, and since back office

systems will be processing CLEC requests intermingled with

Pacific retail transactions, Pacific has just as much

interest in making sure that it is able to handle the extra

load from CLEC volumes. If Pacific does not have

sufficient capacity, the system response times for

Pacific's own representatives and customers will be

negatively impacted and the ability to run batch processes

(turn cycles) on Pacific back office systems will be

hampered. For this reason, the receipt of accurate

forecasts from all CLECs is critical to Pacific's capacity

planning process to ensure that Pacific has enough time to

purchase and install any necessary hardware to meet

combined needs. Although CLECs have not always provided

accurate forecasts, and in some cases have not provided any

forecasts at all, Pacific has provided enough capacity for

these systems by projecting future CLEC volumes based on

past and current trends. Described later in this affidavit

are the processes Pacific has in place by function, and

within each electronic interface, to ensure that CLEC

- 34 -

electronic volumes can be handled in substantially the same

time and manner with our retail operations.

JOINT TESTING

59. Pacific offers joint testing to all CLECs preparing to

implement an application-to-application interface. When a

Pacific Account Manager receives a CLEC request to run a

joint test of LSR-based EDI, for example, an initial

meeting is scheduled with the CLEC and points of contact

from Pacific’s OSS Wholesale Customer Support and EDI Test

Coordination teams are identified. In this initial

meeting, the team discusses any high level issues, sets up

the connectivity method for transmitting service requests

in the LSR-EDI format, and schedules testing. The Pacific

Test Coordinator then distributes Pacific Bell’s Local

Service Request Electronic Data Interchange Joint Test Plan

(“EDI Joint Test Plan”) to the CLEC via its Pacific Account

Manager. Viveros Attachment U. This document includes an

overview of the test and validation strategies, proposed

timelines, and expectations for the test. Pacific provides

a standardized test case worksheet for the CLEC to use in

creating test cases. The CLEC then finalizes the scope of

test cases with the EDI Test Coordinator and provides their

test data. The Pacific Test Coordinator will perform any

setup required for the test environment to process the LSRs

via EDI. Overall Test Data Strategy and the scope of the

test generally includes the following activities:

- 35 -

· Pacific and the CLEC will agree upon the test data forJoint CLEC testing before signing-off on the test plan.

· The test plan will contain both entrance and exitcriteria.

· Production accounts must be used for all test cases, andall information (e.g., end user name, address) must be insynch with production.

· Purchase Order Numbers (“PONs”) must be the uniqueidentifier for each test case.

· CLEC will submit data files containing productionaccounts.

· Pacific will load the accounts and any reference datainto the test environment.

· All issues will be negotiated until resolved.

60. The CLECs currently in EDI production following joint

testing are: COVAD (December 1998), NorthPoint (March 22,

1999), and GTECC (June 26, 1999). Nextlink is scheduled to

begin production in the 3rd quarter 1999. As of this

writing Sprint has not committed to a testing or production

date, but is estimated to be in production in late November

1999.

61. Pacific continues to support and encourage joint testing of

its electronic interfaces, where appropriate.

62. Pacific has developed a set of OSS performance measures

that will allow CLECs and regulators to confirm that

Pacific is providing nondiscriminatory access. The Johnson

Affidavit describes the specific performance measures in

detail.

- 36 -

63. The following sections describe each of the interfaces that

Pacific is making available for access to each OSS

function. Pacific is making available interfaces that

comply with industry guidelines and standards (where they

exist) and will continue to enhance these interfaces as the

guidelines evolve. Pacific is providing access to some of

the same systems used by Pacific’s own service

representatives. CLECs using these interfaces will receive

immediate feedback with regard to the quality of their

orders and their throughput will only be limited by their

ability to submit accurate and complete requests. This

added capacity is in addition to the known and forecasted

CLEC growth. Viveros Attachment Z provides a set of flow

diagrams that describe the electronic interfaces Pacific is

making available to CLECs. Viveros Attachment V provides a

summary of all the electronic interfaces discussed below

and includes the physical interface, hardware and software

requirements, as well as the hours of operation for each

electronic interface. Viveros Attachment W is a summary of

the OSS documentation made available to CLECs. Due to the

extensive size of the documents referenced in Viveros

Attachment W, we are providing the CLEC Access Developer

Reference Guide (DataGate) as an example of the

documentation available to CLECs. Viveros Attachment X.

- 37 -

PRE-ORDERING

64. Pre-ordering involves the exchange of information between

Pacific and a CLEC about a customer during the negotiation

phase with that customer. Pre-ordering activities enable

the CLEC to submit an accurate service request to Pacific.

Pre-ordering capabilities include address verification,

customer service record review, product and features

availability, telephone number assignment, due date

availability, dispatch requirements, loop length indicator

for xDSL, and PIC and LPIC availability.

65. As a result of an agreement made in the 271 Workshops,

Pacific offers Flexible Due Date(“FDD”), with a minimum

three day commitment for specific orders of 19 or less for

2-wire basic analog loops REQ Type A and B for New Connects

and outside moves. This new due date process allows the

CLECs to provide the most reliable due date to their end

users. Pacific communicated this new process to the CLECs

via accessible letter CLECC 99-157, dated May 7, 1999.

Viveros Attachment Y. LSC methods and procedures were

changed to reflect this new process and all Facilities LSC

representatives were trained on the new process by April

27, 1999. CLEC Handbook section 1.3.5 was updated on May

5, 1999. Viveros Attachment Z.

66. When viewing the next available due date in the pre-

ordering phase of end user order negotiations, CLEC

- 38 -

representatives can provide Pacific's FDD with a three-day

minimum. To offer FDD intervals with a three-day minimum

for 2-wire basic analog loops, Pacific changed its

provisioning process for these non-designed loops. This

change in process also required Pacific to work with CLECs

that wanted to continue receiving design information for

this non-designed service.

67. Prior to implementation of the provisioning change needed

to support the 3 day minimum for 2-wire analog loops,

Pacific was providing FDD tables in Verigate and DataGate

for Basic Resale and POTS-like Loop with Port combinations.

With the provisioning change, Pacific also added the

notation in Verigate and DataGate that FDD with a three-day

minimum was available for 2-wire analog loop requests for

19 or less loops in a single wire center.

68. The Final Decision requires Pacific to analyze the

prospects of providing CLECs with electronic access to loop

quality information and the K1023 process. App. B, p. 18-

19. It also requires Pacific to explain the type of

information that is available in systems that indicate

relevant information about loop length, quality, and

availability. Viveros Attachment AA contains this analysis

and provides the requested information. In sum, the

attachment concludes that Pacific does not provide access

to these back office systems for several reasons. With

respect to PREMIS, all pertinent information, including the

loop length indicator, that might be needed by a CLEC is

- 39 -

already made available to the CLEC through one of Pacific's

pre-ordering applications, e.g., Verigate, DateGate, EDI

SSl3 and CORBA. APTOS contains no information in APTOS

relative to determining availability of loops for DSL, and

all other information stored in APTOS and used by CLECs in

their end user negotiation process is provided through

Pacific's pre-ordering interfaces. As for LFACS, Pacific

cannot feasibly provide CLEC representatives access to

LFACS due to capacity restrictions, such that providing

access to additional users would delay the processing of

all service orders, or in the extreme case, cause the

system to fail completely. In lieu of granting CLEC access

to LFACS, Pacific has developed a Geo Mapping Platform that

will permit a CLEC to pre-qualify a specific customer for

the CLEC's specific DSL type. This new platform will

eliminate the need for the CLEC to submit a K1023, except

to check on the possible interference of disturbers. In

addition, Pacific will implement a new process in July 1999

that permits the CLEC to submit and receive responses to

K1023s electronically using the Internet.

69. As agreed to in the 271 Workshops, Pacific has offered

CLECs the opportunity to identify Central Offices (“COs”)

where the CLECs plan to offer xDSL technologies so that

Pacific can load an equivalent loop length indicator into

PREMIS. App. B, p. 17; OSS Agreement 2.2.2.1. This is the

same loop length indicator Pacific loaded into PREMIS for

COs where Pacific’s retail ADSL service was scheduled for

- 40 -

deployment. Access to this indicator is available to CLECs

via DataGate and Verigate. App. B, p. 17; OSS Agreement

2.2.2.2. Pacific implemented this process by Accessible

Letter CLECC 98-093, which was distributed to the CLECs on

October 1, 1998. Viveros Attachment BB. The Accessible

Letter informed CLECs of the process to follow when

requesting Pacific to load the loop length indicator into

PREMIS for COs where the CLEC intended to provide xDSL.

App. B, p. 18. The Accessible Letter also contained a list

of those offices already loaded in PREMIS, provided

information on accessing the loop length indicator in

PREMIS via Verigate, DataGate, or manually through

Pacific’s Customer Care Center, and explained how to

interpret the indicator returned. In addition, Pacific

advised CLECs of the new loop length indicator

functionality offered in DataGate and Verigate in

Accessible Letters CLECCS 98-048 (Viveros Attachment CC)

and CLECCS 98-047 (Viveros Attachment DD).

70. As of May 31, 1999, eight CLECs have requested the loop

length indicator to be loaded into approximately 213 unique

offices where they intend to deploy xDSL. Viveros

Attachment EE lists those offices where Pacific and CLECs

have requested the Loop Length Indicator loaded into PREMIS

and the dates in which that work was completed.

71. During the 271 Workshops, Pacific committed to hold a

design and development meeting for EDI pre-ordering

interfaces, including EDI SSL3 and CORBA protocols, on

- 41 -

September 23, 1998. Pacific also committed to continue

offering access to DataGate until the EDI pre-ordering

interface was operating on EDI 10 guidelines and then to

allow a reasonable amount of time for CLECs to transition.

WS Agreement 1.1.3. Per the attached September 23, 1998

agenda and supporting documents Pacific discussed with the

CLECs the status of the OBF issue, Pacific’s design and

development plans, joint implementation dates, and the

Change Management Process relative to these new interface

options. Viveros Attachment FF. In a manner reflective of

other elements of the Change Management Process, the

process for introducing new interface options was developed

with active and comprehensive input from the CLECs.

72. All CLECs were invited and four CLECs were in attendance at

this meeting where Pacific reviewed the Order/Pre-Ordering

process flows for Pacific’s existing LEX and EDI ordering

interfaces, Pacific’s current Verigate and DataGate pre-

ordering systems flow, as well as the planned EDI SSL3 and

CORBA flows for pre-ordering. Pacific also shared with

CLECs a document describing the seven business functions of

OBF issue 1278 and the way in which Pacific planned to

implement these functions.

73. In addition, Pacific hosted a Local Pre-Ordering Workshop

on November 17, 1998. This workshop provided a basic

understanding of the EDI Local Pre-Ordering process, the

business specification of the LSPOR and the technical

specifications of the EDI and CORBA solutions. As agreed

- 42 -

to during the September 23, meeting, Pacific followed an

expedited Change Management Process to implement EDI and

CORBA pre-ordering on March 28, 1999. Currently, two CLECs

are preparing to test the EDI pre-ordering interface.

74. The pre-ordering electronic interfaces described in the

following paragraphs will include those interfaces

developed by Pacific ahead of the national guidelines.

Pacific continues to participate in national forums and

committees to develop guidelines necessary for CLECs to

effectively exchange information with Pacific. As national

guidelines are finalized for the pre-ordering function,

Pacific will make such enhancements available to requesting

CLECs, using the Change Management Process.

75. Pacific provides CLECs with a choice of six electronic

interfaces for access to its OSS pre-ordering capabilities:

Starwriter, SORD, CESAR, Verigate, DataGate, and the

EDI/CORBA Gateway, which supports two additional protocols:

EDI SSL3 and Common Object Request Broker Architecture

(“CORBA”). All electronic interface options provide CLECs

with “real-time” access on a dial-up or direct connection

basis. CLECs can choose the electronic interface(s) that

best suits their individual business objectives and systems

architecture.

STARWRITER

76. Starwriter is an on-line system that was developed by

Indiana Bell as a service order negotiation tool that

- 43 -

Pacific adopted for its own retail service representatives.

It is currently used by Pacific retail for single-line

residence orders. Starwriter integrates ordering and pre-

ordering functions and is available to CLECs for pre-

ordering and ordering of single-line residential resale

service. Starwriter provides English translations to

Universal Service Order Codes (“USOCs”)/Field Identifiers

(“FIDs”) and affords CLECs the same access to pre-ordering

capabilities that Pacific offers its retail service

representatives. Since Starwriter serves as both a pre-

ordering and ordering interface, additional detail about

Starwriter is provided in the Ordering/Provisioning section

of this affidavit. Although Starwriter enables CLECs to

effectively perform pre-order functions, empirical data for

its pre-ordering functions cannot be separated and measured

apart from the ordering transactions. Therefore, the

service order will serve as the vehicle for measuring the

CLEC use of Starwriter. Starwriter is fully ready to

support CLEC use for resale services and currently has one

CLEC in production in California.

SORD

77. SORD is an on-line system that serves as the primary

service order negotiation tool for Pacific’s own retail

service representatives, and is currently used for both

business and residence customers. Although SORD is used

primarily for ordering, it also provides access to certain

- 44 -

pre-ordering functions. SORD provides access to the

customer service record in USOC and FID format and displays

the next available due date, applicable to dispatch

required requests, for the service location. SORD allows

CLECs the same access to pre-ordering capabilities that

Pacific offers its retail service representatives via SORD.

Since SORD serves as both a pre-ordering and ordering

interface, additional detail about SORD is provided in

Ordering/Provisioning section of this affidavit. SORD is

ready for use by CLECs and Pacific has assigned 91 CLEC

user IDs through May 1999.

CESAR

78. CESAR is an application that was originally designed for

use by interexchange carriers. CESAR has been enhanced to

provide CLECs on-line access to pre-ordering functions

available from Pacific’s “legacy” systems and was first

made available to CLECs in October 1996. CESAR is a menu

driven system that supports address validation (including

dispatch requirements), product and feature availability,

telephone number assignment, due date availability, and

Primary Interexchange Carrier (“PIC”) availability

functions for both unbundled network elements and resale

services. CESAR pre-ordering functions were developed in

advance of industry standards. With the advent of EDI 10

and EDI SSL3 and CORBA, CLECs were notified via Accessible

Letter CLECCS 99-057, on May 4, 1999, that CESAR pre-

- 45 -

ordering functionality will be retired effective October

30, 2000, pursuant to the timeline for retiring interfaces

in the Change Management Process. Viveros Attachment GG.

VERIGATE

79. Verigate is a GUI from the Toolbar platform that operates

with Windows™ and provides CLECs access to pre-ordering

functions available from Pacific’s “back office” systems,

including address verification, customer service record,

product and features availability, telephone number

assignment, due date availability, dispatch requirements,

loop length indicator for xDSL, and PIC/Local PIC (“LPIC”)

availability. Verigate was designed for CLECs that do not

want to pursue development of their own software programs

or applications and choose not to use DataGate (see

description of DataGate below). Verigate is a plain-

English based interface that provides CLECs with pre-

ordering capabilities for resold services and unbundled

network elements. Verigate also provides extensive on-line

help including a drop-down menu of Service Order

Subcommittee Codes (“SOSC”) needed to order features on new

or migrating service LSRs. In addition, as a Windowsä based

GUI, Verigate makes available Cut-and-Paste and Notepad

functionality as well as View-and-Key to facilitate

transferring information from pre-ordering to ordering.

80. Training for Verigate is available to CLECs as part of the

Toolbar platform applications. Part of the classroom

- 46 -

materials given to the CLECs during training are a User

Guide that includes in-class work cases, an Instructor’s

Guide, which CLECs can use to design training for their own

employees, and job aids Pacific has designed to improve

efficiency for CLECs using the Verigate interface. In

addition, the Verigate User Guide is available on the “CLEC

Online” website, in the IS Call Center site under the Tab

Application Documentation. In addition, the CLEC Handbook

provides hyperlinks when related documentation is

available.

81. As of June 30, 1999, 1,454 user IDs have been assigned for

Verigate. Viveros Attachment HH provides empirical data by

month and year of CLEC use of Verigate. The table displays

data for eight transactions through May 1999 with an

additional four transactions made available to the CLECs in

June 1999. These transactions are used to perform pre-

ordering negotiations with the CLECs and end user

customers.

DATAGATE

82. DataGate is a Pacific proprietary gateway that provides an

application-to-application electronic interface for those

CLECs with their own software programs or applications.

DataGate provides a convenient gateway to allow a CLEC to

acquire all pre-order information from a single interface,

in real-time, using its own negotiation system. This

interface option allows CLECs to connect their own OSS

- 47 -

directly to Pacific’s, thereby minimizing the need for

manual data entry by the CLEC. It provides CLECs with pre-

ordering capabilities for resold services and unbundled

network elements.

83. DataGate is a fully supported middle-ware product that

provides application-to-application interface services to

many internal Pacific applications in addition to CLEC OSS

access. As new protocols for pre-ordering local exchange

services were produced by industry forums, i.e., EDI SSL3

and CORBA, such protocols are used by Pacific to “front-

end” DataGate’s middle-ware, preserving the background

application functionality, data content, and performance

standards that have already been established in a

production mode.

84. A comprehensive CLEC reference guide that is available to

CLECs upon request supports DataGate. In addition, Pacific

offers technical training for CLEC software development

staff. Viveros Attachment X. After completing the

DataGate training, CLEC developers have the knowledge

required to incorporate the necessary code in their service

negotiation systems to electronically access Pacific OSS

for pre-order data on a real-time basis. Two CLECs, COVAD

and NorthPoint Communications, are currently accessing the

production version of DataGate in the Pacific region, with

two additional CLECs targeting 1999 to be in production.

85. During the 271 Workshop discussions around the integration

of pre-ordering and ordering interfaces, Pacific agreed to

- 48 -

provide a document that would explain the pre-ordering

source for filling out the LSR at the request of MCI

WorldCom. OSS WS Agreement 1.1.5. The document known as:

LSR/DataGate Pre-Order Functions/Ordering Fields was

developed on October 1, 1998. This document was

distributed to CLECs via Accessible Letter CLECCS 99-029.

Viveros Attachment II.

EDI/CORBA

86. On March 28, 1999, Pacific implemented another pre-ordering

interface – the EDI/CORBA Pre-ordering Gateway. This

deployment follows industry pre-ordering guidelines and

supports two structural protocols, EDI SS3 and CORBA, as

recommended by the technical industry committees. Pacific

developed plans to implement this gateway interface through

several meetings with CLEC customers as part of the Change

Management Process prior to deployment. This initial

deployment provides the following real-time functionality:

· Address Validation,

· Service and feature availability,

· Access to telephone number assignment,

· Due date availability (for resale, POTS-like Loop andPort UNE combinations and 2-wire Analog loops).

· Dispatch requirements (for resale, POTS-like Loop andPort UNE combinations).

· Primary Interexchange Carrier (“PIC”) and Local PICavailability.

- 49 -

87. The EDI 10 specifications have recently been finalized by

OBF and the Service Order Subcommittee, and Pacific has

begun development work on a second phase deployment to

include CSR, Directory Assistance, and Directory Listing

functionality. Pacific is introducing this enhancement via

the Change Management Process and has scheduled the release

for October 17, 1999.

ORDERING/PROVISIONING

88. Ordering involves the actual transmittal of the service

request from the CLEC to Pacific with the necessary

information for issuance of a service order. Provisioning

includes the exchange of information whereby the CLEC has

the capability to obtain order confirmation data, service

order status, and service order completion information.

Ordering/provisioning capabilities include:

· Order receipt,

· Return of acknowledgments,

· Editing for valid information,

· Return of error information,

· Order confirmation, and

· Return of service order completion status.

89. Pacific provides CLECs with a choice of four primary

electronic interfaces for access to its OSS

ordering/provisioning capabilities: Starwriter, SORD, an

EDI gateway, and LEX. Some CLECs are still using the RMI

gateway. Additional electronic interfaces are also

available for the ordering of Local Interconnection Trunks,

- 50 -

Unbundled Dedicated Transport, Resale Centrex and ISDN, and

to check the status of service orders. For those CLECs

that do not want to utilize an electronic interface for

ordering/provisioning, Pacific also accepts paper service

requests by facsimile and mail/overnight delivery.

STARWRITER

90. Starwriter provides CLECs with a vehicle for ordering (and

integrated pre-ordering) and provisioning for residential

resold services. Starwriter enables the CLECs to perform

migrations, new orders, outside moves, and disconnects of

most residence customers. As noted above, Starwriter is

the same electronic interface that Pacific’s own retail

service representatives have used since 1989 for pre-

ordering and ordering/provisioning service for single-line

residential customers. The proven capabilities of the

Starwriter system provide a robust integrated service

negotiation, pre-ordering and ordering/provisioning

application for CLECs. Use of Starwriter obviates the need

to develop new code sets and facilitates market entry for

any CLEC, particularly those with limited information

services capabilities. Starwriter is a menu driven order

entry system that contains over 1,000 edits that ensure a

high percentage of error-free flow through for retail and

resale residential service orders formatted by the system.

Starwriter is offered as a way for CLECs (large or small)

to quickly begin to electronically negotiate residential

- 51 -

resale orders and efficiently transmit these orders to

Pacific. Pacific has issued 25 CLEC user IDs through May

1999 and currently has one CLEC in production using

Starwriter. As CLECs utilize Starwriter, Pacific will

concurrently continue to work with requesting CLECs on

development of interfaces that operate using industry

guidelines.

91. Training is available for CLEC users of Starwriter. In

addition to the training materials available to CLECs,

Starwriter contains “field help” on each of the screens.

This gives CLECs “user guide” type information on-line,

such as directory listings formatting and PIC search

capability to easily locate long distance carriers

available. Although this on-line documentation is the

primary information source, a user guide is also provided

in training and through account managers. Following formal

classroom training for CLEC personnel, the Pacific OSS

Wholesale Support team is available to CLECs for questions

and onsite support.

SORD

92. In May 1998, SORD was made available to CLECs for ordering

and provisioning resold services. SORD has also been made

available to CLECs for UNE orders. SORD enables the CLECs

to perform all order activity, including migration, change,

new connect, etc., for both their residence and business

customers. As noted above, SORD is the same electronic

- 52 -

interface that Pacific’s own retail service representatives

use in pre-ordering and ordering/provisioning service for

business customers and residential customer activity not

supported in Starwriter. The proven capabilities of the

SORD system provide a sound alternative to industry

guideline based ordering/provisioning mechanisms. SORD can

also be used to supplement LSR ordering for products and

services for which industry guidelines do not exist.

93. SORD contains over 3,500 edits that ensure a high

percentage of error-free service orders being distributed

to downstream provisioning, maintenance, and billing

systems. SORD is offered as a way for CLECs (large or

small) to quickly begin to electronically negotiate orders,

eliminating the need for translation, either mechanically

or manually, and provides the CLEC direct management of

their service order through the request life cycle.

Through May 1999, Pacific’s IS Call Center has provided 91

CLEC user IDs.

ELECTRONIC DATA INTERCHANGE (“EDI”) GATEWAY

94. Pacific’s EDI Gateway provides an electronic interface that

conforms to the Ordering and Billing Forum/Telecommunications

Industry Forum (“OBF/TCIF”) national guidelines. As a

baseline, Pacific’s EDI Gateway currently supports OBF Local

Service Ordering Guidelines (“LSOG”) Version 3 and EDI

Releases 8. Pacific’s EDI Gateway is available to CLECs for

testing and “live” production for the ordering and

- 53 -

provisioning of both resold services and unbundled network

elements. This capability enables CLECs to electronically

submit LSRs to Pacific, receive acknowledgments,

confirmations, jeopardies and completion status utilizing

their own user interface. Using EDI and DataGate, CLECs can

connect their own systems directly to Pacific’s, integrating

pre-ordering and ordering functions and minimizing the need

for manual data entry.

95. For resold services, Pacific’s EDI Gateway enables the

CLECs to perform migrations, new connects, changes of

service, moves, disconnects, and suspend/restore order

requests. Pacific has committed to updating its interface

to support newly adopted OBF/TCIF standards within the

guidelines of the Change Management Process. The next

guideline-based update is targeted for March 2000 when

Pacific will convert to LSOG 4/EDI 10.

96. As previously stated, Pacific’s EDI Gateway currently

supports the ordering and provisioning of certain unbundled

network elements. While national guidelines have yet to be

fully developed for the ordering and provisioning of all

possible unbundled network elements, Pacific has

incorporated the completed OBF/TCIF national guidelines

into its EDI Gateway. As a result, Pacific has developed

and makes available to CLECs for either testing or live

production purposes, the capability of its EDI Gateway, to

submit migration, new connect, change, disconnect, and

records change orders for unbundled local loops and switch

- 54 -

ports as well as number portability, with or without an

unbundled loop. In addition, Pacific’s EDI Gateway also

supports unbundled network element combinations, defined by

OBF, for Loop with Port requests. As LSR industry

guidelines are defined and approved for other unbundled

network elements, Pacific will incorporate those guidelines

into its EDI Gateway using the collaboratively developed

Change Management Process guidelines.

97. Unlike the systems that are used by Pacific itself, and by

its retail and interexchange carrier customers, Pacific’s

EDI Gateway has been developed specifically to accommodate

the preferences of CLECs. Pacific believes that a phased

approach to systems development, joint testing, reviews

e.g. walkthroughs, and trials are certainly a necessity

before “live” activity is allowed to be processed. The

development of Pacific’s EDI Gateway has followed this

approach. In Pacific’s internal testing of the EDI

Gateway, programmers first completed simulation testing,

corrected any problems encountered during the initial

testing period, and re-tested the corrected system. A

quality assurance team simulated various ordering scenarios

and tested any added new functions. The internal testing

involved three main areas as follows: 1) processing of EDI

records, 2) performing data and relational edits for the

creation of feeds to downstream systems, and 3) generation

of Firm Order Confirmation (“FOC”) and Service Order

Completion (“SOC”) processes

- 55 -

98. It is important to note that the EDI ordering processes are

a relatively new development that support an extremely

complex task. Implementation of this interface depends on

the mutual efforts of CLECs and Pacific. For the most

part, large CLECs have been the primary proponents of the

EDI concept because of their embedded information services

systems and the fact that national standards work has

focused upon this concept. Yet other less sizeable

companies are the ones that have developed interfaces,

either themselves or through the use of vendors, to allow

for them to move ahead of the larger CLECs in actual

deployment of EDI.

99. Pacific has provided CLECs information needed to begin

development of interfaces. It should be recognized that

OSS negotiation and implementation progress with each CLEC

varies, and that Pacific’s provision of OSS documentation

to CLECs ranges from simple brochures to complex technical

interface requirements, depending on the negotiation phase,

type of interface and level of interest demonstrated by the

CLEC.

100. The provisioning and exchange of documentation and

interface specifications in today’s environment is a

dynamic process. Ongoing changes and enhancements coming

from CLEC negotiations as well as from the closure of new

OBF issues necessitate ongoing documentation changes and

updates. In addition, through its discussions with CLECs,

Pacific continues to learn of better formats to more

- 56 -

effectively convey information as well as in areas that

require clarification. In order to provide more clarity

and be proactive, SBC developed the LSOR to communicate LSR

ordering requirements based on such input. The latest

version of the LSOR is provided as Viveros Attachment JJ.

101. Prior to August 1996, the obligations of the incumbent

local exchange carriers (“ILECs”) to make unbundled network

elements and resale services available to the CLECs had not

been clearly defined. Consequently, there were no

electronic interface national guidelines for access to

Pacific’s OSS functions.

102. Nonetheless, Pacific has been active in guideline setting

organizations and supports the development of national

guidelines for electronic interfaces with its OSS

functions. EDI is a prime example. Pacific has expended

considerable resources to define requirements and to

develop an EDI gateway for ordering that conforms to

national guidelines. Pacific has multiple representatives

working on national guidelines development specifically

related to LSR order formats and EDI data formats at the

OBF/TCIF committees. In addition, Pacific has 12 people

working on the ongoing requirements for Pacific’s systems

that process the LSRs received from the CLECs. Pacific’s

Information Technology organization has additional

employees who are responsible for the design and

development of this work. As a result of this commitment,

Pacific has an EDI gateway in place that is capable of

- 57 -

processing numerous types of orders for unbundled network

elements, both individually and in combination, number

portability and resale services.

103. As noted above, Pacific has promptly implemented national

guidelines for electronic interfaces within its OSS

functions as they have been developed, and has committed to

implementing new national guidelines within the guidelines

of the Change Management Process developed by CLECs and

Pacific, or by the applicable sunrise/sunset timetables

once set by OBF/TCIF.

EDI Development

104. Pacific conducts joint technical working sessions with

CLECs to discuss industry standard EDI mapping

specifications and ordering requirements. These sessions,

held over a period of one or more months, are held prior to

joint application-to-application testing to ensure CLEC

understanding of business rules and ordering requirements.

Pacific also offers free EDI workshops on EDI mapping for

CLECs. Concurrently, a connectivity test is conducted to

ensure data from the CLEC to the SBC EDI translator is in

the correct protocol format. In addition, the test ensures

that the CLEC is capable of receiving an acknowledgment

from the EDI translator. If there are any connectivity

issues, Pacific works with the CLEC to isolate the problem

and takes the appropriate actions to ensure physical

communication between parties is taking place.

- 58 -

105. In April 1998, Pacific developed an EDI Joint Test Plan and

later upgraded the plan, based on CLEC feedback in the 271

workshops, to include:

· A full explanation of EDI testing, which includesdiagrams that detail the difference between the test andproduction environment, including the flow of both UNEand resale orders, and the point(s) of manualintervention. OSS WS 1.2.5B.

· A full explanation of how Modification Requests (“MRs”)are processed between Pacific and SWBT since EDI is ashared system (Sec. 7.0), OSS WS 1.2.5.

· Account criteria for test cases (Sec. 8.0). OSS WS1.2.5B.

· Super fatal errors of both Pacific and SWBT EDIinterfaces located within. Viveros Attachment U. OSS WS1.2.5C.

106. When the CLEC is ready to begin joint application-to-

application testing, both parties meet to negotiate a CLEC

specific test plan. Most importantly, both parties agree

on the testing scope and schedule. The negotiation session

also includes a review of the CLEC test scenarios and a

determination of whether the CLEC will supply test accounts

or use Pacific’s generic accounts OSS. WS Agreement 1.2.5

A, B, D.

107. During testing, daily or frequent conference calls are held

between testing experts to review test results and

determine actions to resolve issues. Many times, Pacific

brings in business experts to facilitate a quick resolution

of issues. In addition, Pacific provides “key learnings”

- 59 -

out of EDI testing with current and developing EDI users on

an ongoing basis. App. B, p. 6, OSS WS 1.2.5D. The first

Accessible Letter (CLECCS 99-021), dated February 19, 1999,

was distributed with the fourth quarter 1998 key learnings.

Viveros Attachment KK. CLECs were advised that subsequent

Accessible Letters updating “key learnings” from EDI will

be sent quarterly as activity warrants.

108. Pacific continues to provide CLECs with production support

when joint testing is complete and the CLEC begins to issue

“live” Local Service Requests (“LSRs”) via EDI. Pacific

also offers CLECs support at their service center locations

during the initial transition to EDI. On-site support is

usually an average of one to two days with ongoing

operational calls to resolve issues.

109. AT&T went “live” on EDI in December 1998. AT&T tested

various scenarios before issuing “live” LSRs in production.

In addition, the CLEC sent “test PONs” in production to

ensure its business processes for those scenarios were in

place.

110. COVAD also went “live” in December 1998. Pacific began

meeting with COVAD in April 1998. At that time, Pacific

provided basic information on EDI, including connectivity

options, mapping information and business rules

information. Meetings and conference calls continued over

the next several months. COVAD began EDI testing with

Pacific for xDSL capable unbundled loops in September 1998,

and went live in December 1998.

- 60 -

111. COVAD’s vendor and Pacific continue to work to resolve the

issues regarding the submission of correct LSRs by COVAD

and the timely processing of them by Pacific.

112. Pacific has also worked closely with COVAD when it has been

unable to send orders via EDI due to issues with its Value

Added Network (“VAN”) provider. As recent as June 1999,

Pacific allocated significant resources to review close to

200 Purchase Order Numbers (“PONs”) when COVAD stated that

it had not been receiving any Firm Order Confirmations

(“FOCs”) or Service Order Completions (“SOCs”). Pacific

focused on identifying COVAD’s issues and devoted LSC,

systems and CLEC OSS support during the entire period.

After intensive research and troubleshooting by Pacific,

including researching each individual PON, Pacific

determined that there appeared to be problems in COVAD’s

platform. After Pacific isolated the problem, COVAD began

investigations on its end. These investigations revealed

that there were problems between COVAD’s platform and its

VAN provided connection and software that was implemented

during late May and early June 1999. Pacific has offered

to retest connectivity with COVAD to ensure its VAN

problems were corrected before resuming EDI LSR processing.

COVAD has corrected its VAN connectivity issue, however, it

has made the decision to stop sending EDI orders because it

is reviewing how it can achieve a higher level of structure

in doing software upgrades on its end. The decision not to

send EDI orders has also been impacted by the fact that

- 61 -

COVAD would like a different connectivity set up via a

dedicated line using Direct:Connect. COVAD would

transition EDI processing over the dedicated line, instead

of the VAN. Until COVAD resolves these internal issues,

Pacific is accommodating orders from the CLEC via CESAR.

113. NorthPoint also began the testing process with Pacific in

November 1998 and began testing in the production

environment in January 1999. NorthPoint went “live” in

production mode in March 1999.

114. Allegiance Telecom began EDI testing in May 1999 with a

targeted implementation of August 1999. NextLink started

joint testing with Pacific on June 6, 1999 and is scheduled

to implement in July 1999. GTECC went into “live”

production on June 25, 1999, following joint testing. As

of this writing, Sprint has targeted August 1999 to begin

testing with implementation in November 1999. Level 3 and

Momentum have indicated that they will joint test with

Pacific later this year or early 2000.

Documentation and Requirements for Interface Development

115. CLECs are notified of the availability of various

applications or enhancements to existing applications and

the associated documentation via the Accessible Letter

Process e.g., Accessible Letter CLECCS 98-048 titled

UPDATE: DATAGATE DOCUMENTATION, dated September 24, 1998.

Viveros Attachment CC. Most documentation is also

- 62 -

available through a link established in the CLEC Handbook.

App. B, p. 2.

116. In addition, Pacific has developed an indexed library of

available documentation and requirements which provides

CLEC Account Managers and other customer-facing personnel

with those documents required by a CLEC to fully develop,

implement and test a Pacific interface. Attachment W –

Location and Summary of OSS Documentation and When To

Provide to CLECs. Pacific also offers technical sessions

with systems experts to assist CLECs as they begin to code

to an application. For example, the EDI Workshop available

to CLECs preparing to develop EDI, also, provides technical

documents, e.g., the EDI 997 Transaction Set document.

App. B, p. 2.

117. While conducting EDI joint tests with CLECs, the Pacific

Release Testing Teams have, on occasion, found the need to

modify the business rules or associated documentation as a

result of discrepancies discovered during testing.

Accessible Letters are then issued to all CLECs citing the

system or documentation change required and the applicable

implementation dates. CLECCS 99-046, issued March 31, 1999

and CLECCS 99-047, issued April 2, 1999 are examples of

this type of notification. Viveros Attachment LL. App. B,

p. 2.

118. Pacific’s side of its interfaces is fully operational and

consistent with published business rules. Successful CLEC

joint testing results attest to the operational readiness

- 63 -

of Pacific interfaces and the adequacy of related

documentation. Further proof lies in the fact that CLECs

today are actively transmitting in “live” production mode.

App. B, p. 2.

119. As enhancements are planned, Pacific provides notification

to CLECs of targeted release dates via Pacific’s 12-Month

Development View as part of the Change Management Process

(“CMP”). Then in advance of any given release and using

the CMP guidelines for timing, the CLECs are also provided

with first initial then final requirements for each

release, including business rule changes via the Accessible

Letter process. CLECCS 98-084, 99-003, 99-018, 99-046,

Viveros Attachment MM.

120. Evidenced by the existence of COVAD and NorthPoint in

“live’ production using EDI and DataGate, and GTEC using

EDI, Pacific has supplied all applicable documentation,

business rules, and technical support to allow a CLEC to

develop pre-ordering and ordering interfaces in a design

that meets its business needs. Pacific also believes that

compliance with the CPUC’s order on sufficient

documentation for application development will be further

supported with the results of third party testing

(described later in this affidavit).

LEX

121. LEX is a graphical user interface developed for CLECs by

SBC. LEX is designed to operate on Windows™ and is based

- 64 -

upon national OBF/LSR guidelines currently using Version 3.

It allows CLECs to electronically create and transmit

resale services and unbundled network element LSRs to

Pacific. LEX also enables CLECs to receive acknowledgments

and notification of error details from Pacific, and to

track FOC and SOC status of LSRs. LEX is an option for

CLECs that wish to utilize national guidelines ordering

formats but do not have or wish to establish EDI

capability. LEX supports the same types of orders as

Pacific’s EDI Gateway, including flow through capabilities,

for resale services, unbundled network elements, and

unbundled network elements combinations. After concluding

successful testing for unbundled network elements, LEX

became generally available in March 1998 and for resale

services in May 1998.

122. As a result of CLEC feedback during LEX Beta tests in late

1997, additional enhancements (e.g. ability to copy or

template an entire LSR) were added to LEX. The template

capability is a feature, whereby a CLEC order that passes

the system edits can be copied and made into a model. When

subsequent similar orders are created, the template can be

used and only the fields that change would need to be

populated. The template feature of LEX helps reduce time

spent creating an order and the number of order errors.

123. Pacific held internal pilot training classes for LEX in

January 1998. The LEX training classes became generally

available to CLECs in February 1998 and are provided

- 65 -

separately as a half-day class. Part of the classroom

materials given to the CLECs during training are a User

Guide that includes in-class work cases, an Instructor’s

Guide, which CLECs can use to design training for their own

employees, and job aids Pacific has designed to make CLEC

users more efficient while using the LEX interface. In

addition, once the CLEC is utilizing LEX, an on-line help

reference is also available to the CLEC user. Pacific

offers two free workshops as a prerequisite for CLECs

wishing to utilize LEX, which reflect that LEX is based on

the industry standard LSR format. One of the workshops is

related to completing the LSR forms for unbundled network

elements and lasts one and one-half days. The second

workshop serves the same purpose for resold services and is

one-half day long. Once the CLEC is familiar with the LSR

forms, it is in a better position to attend the LEX

training.

124. In April 1998, CLECs evaluated LEX for its ability to

generate requests for a new end user as well as a way to

manage their embedded resale customer base and began

requesting user IDs in April 1998. Through May 1999, the

ISCC has assigned 1,643 user IDs for LEX in Pacific.

125. Pacific’s first on-site support for a CLEC going “live” in

LEX was provided to AT&T by Pacific’s OSS Wholesale

Customer Support team at AT&T’s Mesa, Arizona location.

The support was focused primarily on the LSOR and Resale

business rules support. Based on verbal comments from AT&T

- 66 -

personnel, the visit was very well received by AT&T.

Pacific was also on site in April 1999 when AT&T brought up

another LEX location in California. AT&T began sending

some UNE orders via LEX at that time.

126. Nextlink was the second Pacific CLEC to go “live” on LEX in

June 1998 for UNE Loop LSRs. Pacific again provided on-

site support at initial turn-up. Subsequent on-site visits

were made in July to support LEX Nextlink users. MGC also

went “live” on LEX for UNEs in September 1998 and Pacific

provided on-site support at initial turn-up. IN TOUCH

requested Pacific on-site support in March 1999 where the

focus was on helping the CLEC to understand the resale

error messages received. Advanced Telecommunications Group

was provided on-site support at its request in March 1999.

This visit focused on Resale Business rules and LEX

navigation.

xDSL ORDERING

127. As a result of a 271 Workshop agreement, Pacific agreed to

host a meeting to discuss proposed solutions to ordering

process problems for xDSL compatible loops. WS Agreement

1.2.4. On September 22, 1998 and November 17, 1998, xDSL

forums were hosted by Pacific and attended by CLECs

interested in ordering unbundled ISDN/xDSL capable loops.

Viveros Attachment NN, Accessible Letter CLECCS 98-061. At

these meetings, Pacific presented a plan to identify xDSL

loops from ISDN loops. Further, the ordering process

(e.g., LSR Request) and the rationale behind Pacific’s

- 67 -

Spectral Management Process were reviewed. Discussions

focused on the concept of “dedicated binder group”

assignment for ADSL technology.

128. By differentiating the type of DSL technology intended for

connection to the loop, CLECs will have assurance that the

ordering, provisioning, and maintenance of their DSL loop

will be consistent with the intended service while

protecting the integrity of Pacific’s network for all

users. CLECs were notified of the updated xDSL ordering

process via Accessible Letter CLECC 99-159, May 7, 1999.

Viveros Attachment OO. As of this writing, Pacific

continues to dedicate full-time resources to the further

development of the loop qualification and mechanized

processes that facilitate the flow through of xDSL orders. Listings and E911

129. For resold products, CLECs can submit Listings and E911

information via the Local Service Request (“LSR”) process.

Facilities-based CLECs, in contrast, currently use the

Listings Gateway and the MS E911 Gateway to provide that

information and complete their ordering process.

Facilities-based CLECs access these gateways using a PC or

terminal to create records for direct input into the

gateways. The Listings Gateway can be accessed via a dial-

up line or dedicated circuit. Only dial-up access is

available for the MS E911 Gateway. These processes and

procedures are outlined in detail in the CLEC Handbook and

- 68 -

MS Gateway Training and Reference Guide, and are covered in

the free training Pacific offers CLECs.

130. During the 271 Workshops, CLECs requested the ability to

submit Listings orders and provide E911 information (for

UNEs) to Pacific utilizing the LSR process.

131. Pacific agreed to consolidate E911 (with Pacific Port

orders) and listing information into LEX and EDI ordering

interfaces. Pacific also agreed to form a team to explore

with CLECs currently using or intending to use the EDI or

LEX ordering platforms: methods to accomplish integration;

technical and practical feasibility issues; and

implementation issues. WS Agreement 1.2.2. The E911 and

Listings Integration (“ELI”) project is the result of these

joint, cooperative meetings. The implementation of ELI

will give facilities-based CLECs the choice of providing

listings (for all UNEs and NP) and E911 information (for

UNE port and loop combinations and standalone port, only)

to Pacific utilizing either the LSR processor or continuing

to use the Listings Gateway and the MS E911 Gateway for

direct input. In addition, with the deployment of ELI,

CLECs’ E911 and Listings information submitted via LEX and

EDI will go through the same up-front edits as they do on

the resale side. These edits facilitate the highest

accuracy rates for E911 and Listings data. Pacific’s ELI

project, which is scheduled for implementation in August

1999, will also provide long-term flow through for

Directory Service Requests (“DSRs”). WS Agreement 1.5.5;

- 69 -

App. B, p. 1-2. The ELI project will conform to applicable

industry guidelines, and will be an exception to the Change

Management timeline, by agreement between Pacific and the

CLECs.

132. During the 271 Workshops, the parties agreed to the scope

of the ELI project. The original scope encompassed those

UNE orders where Pacific would be the dial tone provider,

i.e., UNE loop and port combinations and stand-alone UNE

port orders. App. B, p. 1. Pacific also agreed to conform

to industry guidelines. Shortly thereafter, in late August

1998, Pacific launched a feasibility study and commissioned

the “full” implementation (including establishing a formal

project team) in September 1998. At that time, Pacific

also sponsored and chaired meetings between interested

CLECs and Pacific’s Subject Matter Experts, including

members of Pacific’s internal project team. At the first

meeting, the scope of the project was identified and agreed

upon, and CLECs provided their list of requirements. In

some instances, the requirements requested by the CLECs

exceeded the original scope agreed to in the Workshops.

Pacific nevertheless agreed to take them into

consideration.

133. Subsequent meetings held face-to-face or via conference

call continued in October and November 1998. In December

1998, Pacific hosted a preliminary walk-through meeting of

the proposed implementation. In January 1999, the parties

reached a joint agreement and closed on the implementation

- 70 -

design and requirements (including a review of all ordering

scenarios and the draft LSOR document). WS Agreement

1.5.5. Each CLEC/Pacific ELI meeting was announced through

the Accessible Letters process. CLECC 98-038. Viveros

Attachment PP. Additionally, the CLEC and Pacific project

team members communicate on an ongoing basis through email

and telephone calls. A final post-implementation meeting

will be scheduled following the August release.

134. At the CLECs’ request, Pacific has exceeded the original

scope of the ELI project by:

· Including NP (Number Portability) in the scope of theimplementation for Listings.

· Providing “As Is” migration capability for both Listingsand E911 records, even where the end-user’s service issubstantially changed and the underlying network elementsare altered, for both UNEs and NP (as applicable).

· Adopting and implementing REQ TYP J LSRs to providestandalone Listings requests (where no Pacific networkservices are involved) and a simplified CLEC orderprocess for changes to existing Listings.

· Developing simplified LSR disconnect requirements byreducing the number of mandatory LSR fields on therequest.

· Allowing use of either Gateway (LGW or MSG) or the LSRfor CLEC end-user requests, on a per order basis.

135. Pacific expects to implement CLEC requested requirements

prior to the standardization and development schedules of

all industry forums (e.g., Migrating a listing “as is” with

a Number Portability conversion will not be on the agenda

- 71 -

for consideration at the Ordering and Billing Forum (OBF)

until late 2000 at the earliest). As a result, “non-

industry standard” processes and methods will be

implemented in the August release.

136. The implementation of ELI on the LSR for UNEs was announced

to the CLEC community in the 2Q99 Release Accessible

Letters. CLECC 98-084 Viveros Attachment QQ. Due to

expressed CLEC concerns regarding the June 1999 release and

internal timing of system enhancements, the release has now

been rescheduled to August 1999.

137. Pacific participates on all National Emergency Number

Association (“NENA”) standards development committees and

follows NENA standards for local service providers and

recommended measurements for data quality. Pacific exceeds

NENA standards for database synchronization for resale

CLECs. For example, although the NENA standard recommends

database comparisons on an annual basis, Pacific provides a

100% validation of the resale database weekly.

138. Pacific makes available extensive documentation in support

of E911 and Listings, including the CLEC Handbook section

1.0, Ancillary Services, and E911 Training and Reference

Guide. This information is provided during negotiations

with a CLEC to prepare them for submitting accurate E911

and Listing data with their very first order. Pacific also

provides two workshops (one on Directory Listings for

Resale and another for Facilities-based CLECs) that discuss

directory and listings business rules and how to use the

- 72 -

Listings Gateway and the Web-based Listing Lookup tool. In

addition, Pacific provides training classes designed to

enable the CLEC to submit a correct LSR or DSR.

139. During the 271 Workshops, Pacific and CLECs agreed to

establish a Fix-It Team to address E911 and listing issues.

WS agreement 1.2.1. Pacific established the Fix-It Team in

October 1998, and continues to lead and participate

actively in the Fix-It Team. The charter of this team is

to act as a process improvement team for both Listings and

E911. The team has gathered and analyzed data to determine

the root cause of eight key areas of concern for CLECs

operating in California. As a result, corrective actions

have taken place to ensure an increased ease of doing

business for the CLECs and an overall reduction of listings

errors and rejects by 20 percent since the team’s

inception. In addition, numerous CLEC questions have been

answered in this forum by Pacific in providing detailed

information regarding processes, provisioning, and systems

relating to Listings and E911.

140. Pacific has implemented corrective actions to address the

eight areas of concern identified by the Fix-It Team.

App. B, p. 2. These areas of concern are:

· Service Address validation errors due to thediscrepancies between the PREMIS database (used for pre-ordering activities) and the MSAG database (maintained byCounty Coordinators for E911 records).

· Rejects of migrations sent through the MS Gateway due toexisting records remaining locked by the existing

- 73 -

provider.

· Integration of the E911 record information for UNE Loopand Port Combinations and Standalone Ports only into theUNE LSR ordering process, thus eliminating the need toinput through the MS E911 Gateway for those products.

· Dropped DA (Directory Assistance/411) listings.

· White Pages listing problems (missing listings and/orincorrect listings).

· Directory delivery problems (missed deliveries).

· Rejects and errors through the Listings Gateway(understanding why they occur).

· Integration of the Listings information into the UNE LSRordering process, thus eliminating the need to inputthrough the Listings Gateway.

141. Pacific has taken corrective action on the items for which

Pacific was identified as responsible for taking action.

The results of some of the analysis work pointed to

corrective actions that CLECs must take themselves (e.g.,

items for which no Pacific system or process changes or

additional Pacific provided resources would resolve the

issues or reduce the errors). In some cases, there was not

sufficient data provided by the CLECs to properly analyze

the problem and the team agreed to close those items.

142. The partnership between the Pacific and CLEC team members

has been so successful in sharing and distributing

information and resolving issues, the Fix-It Team has

decided to continue this forum on a quarterly basis to

share information and visit any concerns that may arise in

ongoing operations.

- 74 -

143. At the January 20, 1999 Fix-It Team meeting, Pacific

provided clear guidelines for address validation, including

guidelines for discrepancies between addresses that pass

SORD, but not E911 validation processes. App.B, p. 1.

Pacific shared with CLECs the California 709 Error Job Aid

(“Job Aid”) of the known discrepancies and recommended

corrective actions related to address validation

disparities between Pacific’s E911 Master Street Address

Guide (“MSAG”) and PREMIS systems. Pacific explained that

“these occurrences are caused by the unique requirements of

E911 services and the location information required to

support emergency services response. Many are attributed

to the difference between true community names and postal

community names.” CLECC 99-111, Viveros Attachment RR. At

the March 16-17, 1999 Fix-It Team meetings, the CLEC noted

that the Job Aid is very useful. On April 1, 1999, Pacific

distributed the Job Aid to all CLECs via Accessible Letter

CLECC 99-111 Viveros Attachment RR, and created a reference

and link in the CLEC Handbook to the Job Aid. Section 1.0

of Ancillary Services, Page 3, Viveros Attachment Z.

144. Pacific continues to participate actively on the Fix-It

Team and its efforts to gather data, and recommend and

implement corrective actions that will reduce or eliminate

rejections of errors in the directory listings, white

pages, and E911 orders. App. B, p. 2. Pacific has not

only hosted four of the five meetings and chaired all five

meetings to date, but also provided presentations and

- 75 -

documentation which (1) educated CLEC members on Pacific’s

processes, (2) answered specific questions raised in the

forum, and (3) facilitated understanding of the issues and

the team’s data gathering procedures. Pacific has

dedicated six Subject Matter Experts to the Fix-It Team,

representing Listings and the Listings Gateway, E911 and

the MS E911 Gateway, the LSC, CLEC Account Management, and

the Procedures and Policies groups. Pacific continues to

provide additional resources as needed to answer questions,

address specific issues, and implement corrective actions.

Over 45 CLEC participants, representing 17 companies, have

attended Fix-It Team meetings on a regular basis. Pacific

announces each meeting via the Accessible Letter process.

Viveros Attachments SS – CLECCS 98-054.

145. Detailed agendas and complete minutes of each team meeting

are distributed to team participants via email, per the

terms of the non-disclosure agreement created by all

parties. The minutes include the topics discussed, Action

Items, Issues for resolution, Team Roster, any handouts

provided during the meeting, and next meeting logistics and

draft agenda. Viveros Attachment TT – Meeting Minutes

packages and signed Non-Disclosure Agreement.

146. As lead of the Fix-It Team, Pacific has championed the

effort to gather and analyze data to identify root causes

of errors and rejects, and has implemented the corrective

actions as agreed upon by the team. These corrective

actions include:

- 76 -

· Development of an E911 Job Aid for CLECs, which ismaintained and updated in the CLEC Handbook. The Job Aididentifies the discrepancies between the “MSAG” andPREMIS databases to facilitate address validation forE911 records.

· Implementation of a cycle of multiple “retries” toprocess E911 records for CLEC migrations through the MSGateway.

· Enhancements to the Web-based Listings Lookup based onCLEC input for greater ease of use in validating existingCLEC listings.

· Enhancements to the Listings Gateway to eliminateerroneous error code generation for duplicatetransactions.

· Relaxed edits on the LOA (Letter of Authorization)inserts made through the Listings Gateway to reduce thenumber of rejects.

· Monitoring the progress of the E911 and ListingsIntegration (“ELI”) on the LSR implementation.

147. CLECs who have participated in the Fix-It Team are also

working to implement corrective actions to ensure their

service representatives are sufficiently trained and are

taking full advantage of the no cost resources Pacific has

made available.

148. Overall, CLEC Listings errors and rejects have been reduced

by over 20 percent since the formation of the Fix-It Team

and as a result of the combined efforts of all team and

their respective companies.

149. The Fix-It Team has also sought to return CLEC listing

errors back to the CLECs. OSS WS Agreement 1.5.3. Today,

- 77 -

the Listings Gateway, is used by all facilities-based CLECs

for direct input of end-user Listings, edits and returns

all Listings errors back to the CLEC for corrections. This

functionality has been in place and has been utilized by

CLECs since 1996. Existing documentation can be found in

the Handbook, Ancillary Services §1.0 ”Listings” (on-line)

and in the CLEC Listings Training documents.

150. The Fix-It Team investigated this issue and collectively

agreed that Pacific already returns listings and E911

errors through the gateways. It also recommended

implementing, as part of the ELI project design, the

capability for Pacific to return errors through the new LSR

ordering process.

151. In its Final Decision, the Commission directed that Pacific

work with the smaller facilities-based CLECs to improve the

E911 data entry gateway’s ability to meet those CLECs’

needs. App. B, p. 1. On February 16, 1999, Pacific hosted

the first Quarterly Pacific Bell/CLEC E911 Database Forum.

Invitations were sent to the CLECs listed in the 911

Database CLEC Contact List. Viveros Attachment UU. The

invitations also solicited CLEC input regarding agenda

items. Viveros Attachment VV. The Sign-In Sheet shows

that 27 people participated, representing 13 CLECs as well

as Pacific. Viveros Attachment WW. The Forum Agenda

covered a wide range of subjects, including E911 Database

- 78 -

changes, DBMS/ALISA conversion,7 E911 Database Support,

helpful tips from the CLEC Handbook, and related reference

materials. Viveros Attachment XX. The complete minutes of

the Forum were distributed via Accessible Letter CLECC 99-

075, dated March 15, 1999. Viveros Attachment YY. The

second quarterly forum was held June 22, 1999. Viveros

Attachment YYY. Pacific’s establishment of and

participation in Quarterly Pacific Bell/CLEC E911 Database

Forums is evidence of Pacific’s commitment to serving all

of its CLEC customers.

152. As a result of the 271 Workshops, Pacific agreed to revise

the CLEC Handbook to reflect the updated ALI record unlock

process for UNE orders. WS Agreement 1.5.1. On August 13,

1998, Pacific implemented the automated unlock of ALI E911

records for migration of UNE elements to another carrier.

Paragraph 1.13.3 of the CLEC Handbook was updated to

include a description of this process. Viveros Attachment

Z. Prior to modification of this process, UNE records were

processed via an interim work-around process. MCI

questioned the impact of the automated process on its

orders processed using the work-around. Correspondence

between Pacific and MCI Viveros Attachment ZZ shows that

Pacific coordinated the unlocking of those records with the 7 Database Management System - Automatic Location Identification Service

Adjunct is a Lucent product that represents the new databse platform forthe management of E911 calls. This is the system that allows the 911Dispatcher to identify the caller's location when they make an emergencycall.

- 79 -

CLEC. This correspondence also shows that Pacific took the

initiative to verify those records still belonging to MCI.

After this verification, Pacific could coordinate the

unlocking of the appropriate records when MCI was ready to

issue a migration request for each order.

153. Today, all CLEC end user Listings reside in the Listings

Gateway database. Pacific introduced the Web-based Listings

lookup application September 1, 1998. This inquiry tool is

offered at no charge to all CLECs and provides authorized

users access to the Listings Gateway database. This

database is the repository for all CLEC Listings, resale,

UNE, and Number Portability (“NP”). A CLEC may verify the

existence of its end-users’ listings, view the white pages

appearance of a straight-line listing, and validate the

directory delivery options chosen for each of its end

users. App. B, p. 2; WS Agreement 1.5.2.

154. Pacific announced the release of its Web-Based Listings

Look-Up via Accessible Letter CLECCS 98-036, dated August

28, 1998. Viveros Attachment AAA. Included in this

Accessible Letter were the application description, access

requirements, and the URL. A subsequent Accessible Letter,

CLECCS 98-040, dated September 11, 1998 was sent to clarify

CLEC access to the Web-Based Listings Look-Up. Viveros

Attachment BBB. As of April 8, 1999, 23 CLECs have

obtained passwords to gain entry to the application.

155. CLECs also have the ability to check their E911 and

Listings information electronically for accuracy. Resale

- 80 -

and facility-based CLECs have “real-time” direct access

into the E911 Management System (MS) database for viewing

their E911 customer records.

156. Pacific has developed standards for an application-to-

application interface for the entry of E911 data. App. B,

p. 1. The E911 Database Enhanced File Transfer is under

development to enable a more direct connection to the E911

Database for data entry and modification. The CLECs were

given advanced notice of the Pacific development standard

via Accessible Letter, May 17, 1999. CLECC 99-173, E911

Enhanced File Transfer Specifications – California, Viveros

Attachment CCC. The intent of the notice was to provide

CLECs with ample time to plan for the acquisition and

development of the systems and programs required for

utilization of the file transfer process upon introduction.

The Enhanced File Transfer Feature is being developed to

provide an alternative to the manual dial-up processes

available today and will utilize the NENA 3 file format for

E911 database updates. It is the intent of Pacific to

implement the actual interface in 2000 via the Change

Management Process.

157. White Pages directory delivery and Complex Captions are

discussed in the Hopfinger Affidavit.

EDI/LEX FLOW THROUGH

158. The FCC defines flow through as “the percentage of orders

that an incumbent LEC processes electronically through its

- 81 -

gateway and accepts into its back office systems without

manual intervention.”8 The FCC has concluded that flow

through, “applies solely to the OSS ordering function, not

the OSS provisioning function. In other words, Order Flow

Through measures only how the competing carrier’s order is

transmitted to the incumbent’s back office ordering system,

not how the incumbent ultimately completes that order.”9

159. Flow through does not require that Pacific’s legacy

operating systems process customer transactions in a

specific fashion; rather, flow through is a measure of

whether CLEC transactions successfully navigate through the

OSS electronic interfaces for the purpose of generating a

SORD order.

160. Once an order is generated and reaches Pacific’s legacy

systems, the process is the same for wholesale as it is for

retail. Pacific retail does not have any more capabilities

after the order is distributed through SORD than those

capabilities available to a CLEC. It is thus appropriate

to measure the percentage of orders that are correctly

entered by CLECs and flow through without manual

intervention to Pacific’s legacy systems. Flow through is

in effect a tool to measure not only the capability of the

incumbent LEC’s OSS to process orders without manual

intervention, but also, the ability of CLEC service 8 In the Matter of Performance Measures and Reporting Requirements for

Operations Support Systems, Interconnection, and Operator Services andDirectory Assistance, CC Docket 98-56, Notice of Proposed Rulemaking, FCC98-72, released April 17, 1998, para. 72.

9 Id. at 71.

- 82 -

representatives to create an error-free local service

request.

161. Automatic Order Generation (“AOG”) is a mechanized means of

creating and distributing orders. A service order type

complies with AOG, if it has the potential to flow through

without manual intervention. Once the order has been

distributed, the order is handled through normal back

office systems. Service orders that are mechanically

generated may still “fall-out” or err out prior to SORD

distribution. Service order fall-out can occur for many

different reasons. Significantly high rejection rates

could reflect problems in obtaining access to the incumbent

LEC’s ordering system. These rates might also indicate

problems with the ordering interface used by a competing

carrier. In numerous cases, the service order fall-out is

a result of incorrectly populated LSRs. In the past, fall-

out rates have been higher for those relatively new

ordering interfaces. With experience, rejection rate drops

dramatically.

162. When LEX and EDI were made available to CLECs in California

for resale, Pacific was able to take advantage of the

existing flow through capabilities of RMI for Resale

requests. Therefore, from the time of the introduction of

LEX and EDI, Pacific had flow through for resale basic

exchange orders for migration activity. Since that time,

Pacific has deployed a very aggressive flow through release

schedule to increase flow through volumes. Pacific’s

- 83 -

releases have included, or are scheduled to include, the

following flow through enhancements for resale and UNEs:

· Basic Exchange Resale - New Connects (Exists)

· Basic Exchange Resale - Disconnects (Exists)

· Basic Exchange Resale - Changes (Exists)

· POTS-like Loop and Port Combinations - Conversion AsSpecified (Exists)

· POTS-like Loop and Port Combinations - New Connects(Exists)

· POTS-like Loop and Port Combinations - Changes (Exists)

· POTS-like Loop and Port Combinations - Disconnects(Exists)

· 2-wire Loop with or without Number Portability (NP) -Conversion As Specified (Exists)

· 2-wire Loop with or without Number Portability (“NP”) -New Connects (Exists)

· 2-wire Loop with or without Number Portability (“NP”) -Disconnects (8/99)

· xDSL Capable Loops - Disconnects (8/99)

· Directory Service Requests (8/99)

· Listings and E911 on the service order for UNE requests(8/99)

· xDSL Capable Loops - Conversion As Specified (10/99)

· xDSL Capable Loops - New Connects (10/99)

163. On February 25, 1999, Pacific met with the Commission to

share Pacific's flow through release plan. App. B, p. 3.

The Commission provided concurrence. As of this writing,

flow through exists for Loop with Port Combinations for

- 84 -

basic exchange for Conversion as specified, new connects,

change and disconnect activities. Flow through of Assured

Loop New Connect and standalone LNP was effective April 10,

1999. Flow through of Loop with Port for listings and E911

will be added with the August 1, 1999 release. Accessible

Letters CLECC 99-191 and CLECCS 99-068, Viveros Attachments

O and DDD. Flow through exists for two-wire basic and

assured loops with and without LNP, for Conversion as

specified, and New Connects. Flow through of two-wire

basic and assured loops disconnects will be implemented

with the August 1999 release. Flow through of directory

service requests will be implemented in the August 1999

release. Flow through exists for standalone LNP for

Conversion as specified. Flow through of Resale basic

exchange was complete with the December 19, 1998 release.

164. Pacific has a plan for implementing flow through of xDSL

loop with and without LNP by the end of 1999. Final

Decision, p. 91-93, App. B, p. 3. On February 11, 1999,

Pacific met with CLECs to discuss Pacific’s flow through

plans for 1999. At that time, Pacific reviewed its updated

Pacific/Nevada Bell Flow Through Plans LEX/EDI matrix

(formerly referred to commonly as Page 35 of the Final

Staff Report) and agreed to host a sidebar meeting to

further discuss flow through of xDSL capable loops.

Accessible Letter CLECC 99-082 “Final Minutes From February

11, 1999, Special Change Management Process Meeting-

California,” Viveros Attachment EEE.

- 85 -

165. Pacific held the sidebar meeting on March 3, 1999 with 13

CLECs in attendance. During that meeting, Pacific reviewed

the xDSL Ordering Template, presented Pacific’s flow

through proposal, sought CLEC input (including forecasts on

relevant activity types for inclusion), and agreed to a

follow-up call on March 24, 1999 to report back on issues

identified in the meeting. Accessible Letter CLECC 99-116

“Final Minutes From March 3, 1999, Change Management

Process Meeting on xDSL-California,” Viveros Attachment

FFF.

166. On March 24, 1999, Pacific hosted the follow-up conference

call with CLECs in which Pacific proposed and sought

concurrence on outstanding issues and agreed to provide a

revised Pacific Flow Through matrix with the April 28, 1999

QCMP agenda. Accessible Letter CLECC 99-142 “Final Minutes

From March 24, 1999, Change Management Process Meeting-

California,” Viveros Attachment GGG.

167. On April 21, 1999, Pacific provided CLECs, via the

Accessible Letter process, a final agenda for the April 28,

1999 Change Management Process meeting, which included

working documents for the meeting. Included in those

working documents was Pacific’s documented flow through

plans in the Pacific/Nevada Bell Flow Through Plans -

LEX/EDI Revised April 8, 1999. The matrix was reviewed

during the meeting and Pacific agreed to make any

identified modifications prior to releasing the matrix for

wide distribution in the final minutes of the QCMP meeting.

- 86 -

During that meeting AT&T requested, and Pacific concurred,

that the revised matrix be put under change control going

forward. Accessible Letter CLECC 99-129 “Final Agenda and

Working Documents 2Q99 Quarterly Change Management Process

Meeting - California”, Viveros Attachment N.

168. Pacific also notified all CLECs on April 27, 1999, via

Accessible Letter CLECCS 99-054 of its initial requirements

for Pacific’s 3rd quarter release, which includes flow

through of xDSL capable loops with and without LNP.

Attachment Q. The Accessible Letter provided an Index of

Changes and the web site and instructions where CLECs can

access both the Index of Changes and Detailed Requirements

and ask that all CLECs, manual or mechanical, review these

changes.

169. During the 271 Workshops, CLECs and Pacific agreed to 10

Flow Through Principles that Pacific would use in its

future development of its flow through plans. App. B, p.

3, OSS WS 1.2.3. The ten principles are as follows:

· Principle 1 – For flow-through improvements that willhave an effect on CLEC interfaces CAT1 process developedfor changes management will be used. For changes thatare internal to Pacific Bell and do not effect the CLEC,notice is required. Change management process group canbe used to further detail on the “notice.”

· Principle 2 – Pacific Bell will explore sourcingrequirements that allow flow-through with CLECs whenthose requirements are not contained in industryguidelines.

· Principle 3 – For the purpose of today’s discussion

- 87 -

“flow-through” refers to service order generation.

· Principle 4 – Resolving disagreements surroundingimplementation issues re[garding] flow-through willutilize the process developed for CAT1 outstanding issuesresolution developed in the Change Management process.

· Principles 5 and 6 – Objective of flow-through is tomechanize process of going from LSR to existing SORDorder without disrupting downstream processes.

· Principle 7 – In developing incremental flow-throughefficiencies and improvements (not requirements) certaininformation requirements must be included. Some of thisinformation is addressed by OBF. There should be adialog[ue] to agree on how to supply information which isnot addressed by OBF.

· Principles 8 and 10 (combined) – When identifying andprioritizing flow-through, these factors will beconsidered:

· volumes (real and forecasted)

· cost effectiveness

· inherent manual nature of the process-P102 for unb.DS1, for example

· efficiency – balance (will CLEC be manual still)

· factors affecting ability to compete and equivalentaccess

· other factors

· Principles 9 – There are some products that will neverhave flow-through.

170. On February 11, 1999, Pacific hosted a Special Change

Management Process meeting to discuss with CLECs, Pacific’s

flow through plans for 1999. During that meeting, CLECs

and Pacific reviewed the 10 Flow Through Principles and

- 88 -

agreed on their meaning as documented in the final meeting

minutes. Viveros Attachment EEE. Also, during that

meeting and the discussion of xDSL flow through, CLECs

agreed to provide Pacific with anticipated activity volumes

in the scheduled March 3, 1999 meeting on xDSL to help

Pacific in prioritizing its flow through plans.

171. Pacific held the xDSL sidebar meeting on March 3, 1999 with

13 CLECs in attendance. During that meeting, Pacific

presented its flow through proposal and sought CLEC input

(including forecasts on relevant activity types for

inclusion). Accessible Letter CLECC 99-116 “Final Minutes

From March 3, 1999, Change Management Process Meeting on

xDSL-California, Viveros Attachment FFF.

172. Pacific’s flow through team also performed an audit of the

10 Principles against the flow through plans for xDSL

capable loops in October 1999. In this audit, Pacific

determined that it had applied the 10 Flow Through

Principles in the development of our flow through plans for

xDSL. Flow Through Principles xDSL, Viveros Attachment

HHH. In short, Pacific has incorporated all of the flow

through principles, in developing flow through plans for

xDSL and is committed to continuing to do so in the future.

173. Pacific has taken action to significantly relax or

eliminate the flow through exceptions or explain why it is

not technically feasible or practical to significantly

relax or eliminate the flow through exceptions and supply

minutes from the Quarterly Change Management meeting where

- 89 -

the exception to the flow through issue was addressed.

FD, p. 95, App B, p. 3. In particular, Pacific explored

relaxing or eliminating each of the following exceptions to

flow through: project quantity, supplemental orders, and

partial account conversion, for each of the required order

types to which they apply. FD, p. 95, App. B, p. 4. On

February 11, 1999, Pacific hosted a Special QCMP sidebar

meeting, during which the CLECs and Pacific reviewed the

following exceptions to flow through: project quantity,

supplements, and partial account conversion (the discussion

on partial account conversions was deferred at that meeting

to the April 28 QCMP). CLECC 99-082 dated March 16, 1999 –

“Final Minutes from February 11, 1999 Special Change

Management Process Meeting,” Viveros Attachment EEE.

174. During the February 11, 1999 meeting the following

agreements were reached with the CLECs: 1) “On cancels,

there was general agreement that flow-through would not be

a benefit,” (“Final Minutes from February 11, 1999

meeting,” Viveros Attachment EEE); 2) On Due Date Changes

and all other supplement types, “It was agreed that we

would abey further discussion for six months for CLEC data

collections” (see Final Minutes from February 11, 1999

meeting); 3) On project quantities, Pacific confirmed for

CLECs that 100 or more numbers on an LSR constitutes

project handling for LNP, and that Pacific has increased

project quantities for loop and loop with LNP from 20 to

41; 4) On partial account conversion, Pacific solicited

- 90 -

input from the CLECs on identifying scenarios and

frequencies by scenario of the types of partial account

conversions Pacific was being requested to process. CLECs

were unable to provide this information during the February

11, 1999 meeting, therefore it was abeyed to the April 1999

QCMP meeting as an agenda item. At the April 1999 QCMP

agenda, Pacific was again prepared to discuss the CLEC

findings. No CLEC in attendance came prepared with the

data. This discussion was again abeyed by the CLECs who

agreed that they would provide this data to the Pacific

Account Manager by May 14, 1999. Pacific agreed to host a

conference call during the week of May 17 to review the

data received. To date, Pacific’s Account Managers have

not received partial account conversion data from any CLEC,

and this conference call has not been held. “Final Minutes

from April 28, 1999 Change Manage Process Meeting,” Viveros

Attachment O CLECC 99-191 dated May 25, 1999.

175. In addition, Pacific explored both the technical and

practical reasons for not eliminating or further relaxing

these exceptions. For practical reasons, many cancels and

due date supplements are received on the due date which

requires the LSC to contact provisioning or field personnel

to make the change in a timely manner. For the third type

of supplement that covers all other types of change, LSC

service representatives need to assess the change(s) by

comparing the Supplemental LSR to the existing SORD order,

then correct the existing order. On the technical side,

- 91 -

Pacific’s Automatic Order Generator (“AOG”) was not

designed to retrieve a distributed service order (SORD) for

the purpose of making changes. The flow through of

supplements would require a complete redesign of AOG.

Pacific’s own Starwriter system also does not have the

ability to supplement the original order created by the

system. Practical and technical reasons for not further

relaxing the project quantities hinge on the fact that

Pacific requires the negotiation of due dates for

established quantities by product based on the product,

quantity, available facilities, workload, etc., for both

retail and wholesale. Pacific does not have established

critical dates for retail or wholesale requests that exceed

those established project thresholds. Therefore, Pacific

is unable to store critical dates in a back office system

to be used in flow through. Although Pacific has not been

provided with CLEC data regarding partial account

conversions, Pacific has considered the extreme technical

difficulty of creating logic in a system to review the

existing end user account structure, identify those lines

to be migrated using the LSR, and then create one or more

orders based on that assessment. For this reason, today

LSC representatives have to manually assess the impacts of

the partial account conversion request and then generate

the service orders required to support the CLEC’s request.

FLOW THROUGH EXCEPTION, Viveros Attachment III.

- 92 -

Notifications

176. If a CLEC’s electronic local service request, sent via LEX

or EDI, is rejected with a fatal error or an up-front edit

in Local Access Service Request (“LASR”), an electronic

reject notification is sent and the CLEC must correct that

error and resend the LSR before it can flow through. Fatal

errors are caused as a result of incorrect information that

the CLEC puts on the LSR. Other non-fatal errors are

processed by the LSC and will be rejected using the LASR

GUI deployed in the LSCs July 6, 1999. Pacific’s LSCs will

also use LASR GUI to send jeopardy notifications beginning

in August 1999.

177. Local Access Service Request (“LASR”) is the application

used by Pacific to edit incoming local service requests

received from EDI and LEX. This application, which was

implemented in Pacific in March 1998, verifies record

layout and edits content.

178. As mentioned above, Pacific currently has electronic

processes in place to provide reject notifications to the

CLECs. For example, reject notifications are returned to

CLECs electronically over the EDI interface when edits from

the LASR system are not passed. The December 1998 release

established real-time, event-driven processing for the

receipt of LSRs and return of electronic rejects as

recommended by the Commission. The LASR edit application

was a batch system when initially deployed in March 1998.

As the local market has developed and grown, it has become

- 93 -

necessary for LASR to process orders real time, rather than

in a batch mode. In order to lessen the impact to the

CLECs and other OSS as LASR became a real-time application,

Pacific implemented a four phase plan to move LASR to real

time. The four phases are outlined below:

· Phase 1 - Near Real-Time for In-Bound (LSR Receipt,Process and Return Rejects): EDI: Improved batchprocessing intervals for the receipt of LSRs and returnof electronic rejects from every two hours to hourly.(Implemented on April 17, 1998.) LEX: Established real-time processing for the receipt of LSRs and return ofelectronic rejects from every 15 minutes. (Implementedon May 31, 1998.)

· Phase 2 - Near Real-Time for Out-Bound (Return ofFOC/SOC): EDI/LEX: Improved the outbound return of FOCsand SOCs for the EDI and LEX interfaces. The FOC/SOCprocess previously ran 5 times a day. Dramaticimprovements occurred in this area. The FOC/SOC processnow executes every hour on the half hour. (Implementedon June 22, 1998.)

· Phase 3 - Real-Time EDI In-Bound (LSR Receipt, Process,and Return Rejects): Establishes real-time, event-drivenprocessing for the receipt of LSRs and return ofelectronic rejects. (Implemented on December 19, 1998.)

· Phase 4 - Real-Time Out-Bound (Return of FOC/SOC)Process: EDI/LEX: Completes full, real-time processing.Improves the out-bound return of FOCs and SOCs from everyhour to real-time. After the completion of this phase,EDI and LEX will have real-time processing for both thein-bound (receipt of LSR and rejects) as well as out-bound (return of FOC/SOC.) (Implemented on December 19,1998.)

- 94 -

179. Pacific made necessary changes to LEX and EDI to provide

real-time processing for orders in a manner equivalent to

that employed by Pacific to process its own retail orders.

App. B, p. 4. With the LASR release on December 19, 1998,

Pacific brought LEX and EDI into real-time processing of

requests, including receipt, editing, rejects, Firm Order

Confirmations/Service Order Completions (“FOCs”/”SOCs”),

and Automated Order Generator (“AOG”) distribution for flow

through candidates. Viveros Attachment JJJ LASR Real-Time

Process Comparison (Prior To and Implemented December 19,

1998), Viveros Attachment KKK -- Business Requirements -

Project Charter LASR Real-Time Processing Project including

Diagram of the LASR Real-Time Release December 19, 1998,

and Viveros Attachment LLL -- LEX Specifications December

19, 1998 Release. Pacific notified CLECs of the changes

being implemented to bring LEX/EDI into real-time

processing in a number of Accessible Letters, beginning

with CLECCS 98-028 dated July 28, 1998, titled “Pacific

Bell Quarterly Release Initial Notification.” Viveros

Attachment MMM.

180. A subsequent notification came in the form of the “PB/NB

12-Month Development View” as an attachment to CLECS 98-051

dated September 28, 1998, titled “Pacific Bell Revised

Agenda for Quarterly Change Management Meeting.” Viveros

Attachment NNN. The 12-Month Development View includes,

under the Category of LSR Ordering for Interfaces EDI/LEX,

“Implement real-time event driven process for the receipt

- 95 -

of electronic LSRs and the return of electronic error

notification for the EDI interface” with an implementation

date of December 19, 1998. The 12-Month Development View

was also reviewed with CLECs at the October 27, 1998 QCMP

meeting. A third Accessible Letter - CLECS 98-076 dated

November 19,1998, entitled “Pacific Bell Enhancements to

LEX,” also advised CLECs of the change to real-time

processing in LEX. Viveros Attachment OOO.

181. The following information will support the use of Customer

Account Record Exchange (“CARE”) records by Pacific to

notify CLECs of lost accounts by demonstrating that CARE

provides like, or in some cases, additional information, as

the Loss Notification Record (“LNR”).

182. CARE records are in a format that are easily utilized, and

have been used by Interexchange Carriers since 1984. These

records provide CLECs with substantially similar

information as that contained in a LNR. App. B, p. 3.

· Notice Type: CARE uses Transaction Code and StatusIndicator to provide an explicit activity indicator. LNRdoes not use Notice Type, as LNR serves only one purpose.

· Working Telephone Number (“WTN”): Both LNR and CARE useWTN to identify the telephone number that was convertedto another provider. LNR ranges sequential numbers onone notification while CARE sends one notice per number.CARE also provides additional information when the WTN ispart of a Multiline Hunt Group. Unlike the LNR, CAREwill provide the Multiline Hunt Group Number (“HML”) andTerminal Number (“TER”). The TER is the only uniqueidentifier in a group without discreet TNs.

- 96 -

· Conversion Date (“CVD”): CARE and LNR both provide thedate the end user converted to the new CLEC.

· LSP’s Authorization Number (“LSPAN”): This optionalinformation is not required by Pacific for any purpose.

183. Both CARE and LNR were developed by industry forums for the

purpose of providing options for exchange of loss

notifications associated with an end user customer moving

from one CLEC to another. In conclusion, CARE provides all

pertinent information in a useable format for CLECs wishing

to be notified in the event of loss.

184. Pacific has implemented an automated reject notice process

for orders that involve a UNE or resold services. FD 84-

85, App. B, p. 3. With the deployment of EDI and LEX for

both UNE and resold services in 1998, Pacific provided an

automated process for the return of rejects for LSRs. If a

CLEC’s electronic LSR is rejected with a fatal error, or an

up-front edit in LASR, an electronic reject notification is

sent. Electronic rejects account for 98% of the rejects on

LSRs. With the December 1998 LASR release, Pacific now

rejects LSRs in a real-time mode. For the remaining 2

percent of the rejects, a LSC representative returns the

reject notification electronically via the interface

through which it was received, using Pacific’s LASR GUI

deployed July 6, 1999. LASR GUI is a desktop tool used in

the LSC to manage their workload. The LSC Methods and

Procedures dictate that the service representative

electronically reject the LSR to the CLEC at the point

- 97 -

where the error is detected while processing the PONs

assigned to that representative in a given day. CLECs were

notified of the planned May release for electronic rejects

by Accessible Letter CLECCS 99-017 dated February 17, 1999.

Viveros Attachment PPP. This Accessible Letter included

the 12-Month Development View Change Log showing for first

quarter 1999, Move “Implement mechanized process to

electronically return previously manual reject reasons via

the EDI and LEX interfaces” to the May 1, 1999 Release.

With the May 1, 1999 release, Pacific began beta tests on

LASR GUI in the LSC. This beta test allowed the service

representatives in the LSC the opportunity to provide

feedback, leading to system enhancements and the time

needed to effectively train all LSC service

representatives.

185. The processing of jeopardy notifications is currently a

manual process in Pacific’s LSC. This manual process

requires the LSC to be notified by the field personnel

responsible for the facility assignment or the provisioning

of the end user service. Currently, the LSC is notified by

report six times a day of jeopardies on pending CLEC

orders. The LSC then makes a courtesy call to the CLEC and

follows-up with a faxed copy of the jeopardy notice. This

process significantly exceeds that which is available in

Pacific’s retail offices. Retail service representatives

usually discover a jeopardy on a pending order when that

order fails to complete on time. Seldom do they receive a

- 98 -

phone call from the field. Moreover, there is no mechanized

reporting of jeopardies in Pacific’s retail environment.

186. With the release of Phase 2 of LASR GUI planned for third

quarter 1999, LSC service representatives will be able to

send jeopardy notifications electronically to CLECs for a

number of jeopardy scenarios, including no facilities and

missed appointments. CLECs were notified of this targeted

functionality in an Accessible Letter. CLECCS 99-018,

dated February 18, 1999, Viveros Attachment QQQ. This

Accessible Letter contained the 12-Month Development view

which stated for second quarter 1999, “Implement mechanized

process to electronically return previously manual jeopardy

notifications via the EDI and LEX interfaces.”

187. Pacific provides electronic firm order confirmations.

Effective with the December 1998 release, changes have been

made to improve real-time processing for LEX and establish

real-time processing for EDI. This release completes full,

real-time processing and improves the out-bound return of

FOCs and SOCs from every hour to real-time. EDI and LEX

now have real-time processing for both the in-bound

(receipt of LSR and rejects) as well as out-bound (return

of FOC/SOC). In addition, real-time FOC/SOC notification

was also implemented ahead of previously published

schedules for both LEX and EDI with the December 19, 1998

release.

- 99 -

RMI Gateway

188. Prior to the existence of industry guidelines, AT&T

requested that Pacific make available an application-to-

application batch interface to support ordering/

provisioning of resale services. Pacific began in fourth

quarter 1995, by conducting meetings with AT&T to discuss

and review the ordering process for resale under

development at the time. AT&T and Pacific jointly agreed

to the necessary information exchange requirements and

developed a file structure for bulk data transfer of

multiple requests. This structure and the interface that

processes these files was dubbed RMI.

189. RMI was first implemented in April 1996 for electronic

transmission of basic exchange resale order requests as

well as firm order confirmation and service order

completion notices between AT&T and Pacific. In May 1996,

RMI was enhanced to include reject and jeopardy

notifications from Pacific and to allow PBX and DID resale

ordering. Throughout the remainder of 1996, RMI was

expanded several times to include additional activity types

(e.g., suspend and restore of service), support ordering of

more features (e.g., caller ID and pay-per-use features),

and to enhance the directory listing/assistance process

(e.g., creation of the listings “as-is” indicator on

migration requests).

190. RMI usage by CLECs increased from its inception, as

evidenced by the 424,252 requests processed between April

- 100 -

1997 and May 1998. Genesis Communications International

Inc. (“Genesis”) began use of RMI in September 1996. In

fourth quarter 1996, Pacific reached agreements with both

MCI and Sprint to convert from a manual process to RMI.

MCI implemented RMI in February 1997 and Sprint converted

in March 1997. The frequency of batch transmission also

increased. The frequency of transmitting batches is

determined by the needs of the CLEC and currently occurs as

frequently as hourly.

191. Between March and November 1997 there were four releases to

add to or improve the capabilities of RMI. These changes

ranged from redesigning how CLECs communicate hunting

specifications to the introduction of changes required to

facilitate complete flow through of migration as is and

migration as specified requests.

192. Pacific implemented another change to RMI in May 1998.

This change was primarily composed of the changes necessary

to support resale in an exchange order format and resale

billing out of Customer Records Information System

(“CRIS”). Based on CLEC input and the withdrawal of the

major CLEC users from the resale market in February 1998,

Pacific will retire RMI in October 2000.

PBSM

193. Pacific Bell Service Manager (“PBSM”) is available for

ordering Centrex and ISDN resale services. PBSM enables

the CLECs to submit migrations, new orders, outside moves,

changes and disconnects of business customers. PBSM is the

- 101 -

same electronic interface that Pacific’s own retail

customers can use in submitting service requests for these

services. As with Pacific’s own retail operations, there

currently exists no means to electronically process service

requests for Centrex and ISDN resold services. Pacific’s

current process to handle these types of service requests

for its own retail customers requires extensive manual

coordination on the part of Pacific service

representatives. The LSC receives orders submitted via

PBSM and processes these service requests in the same

manner as they are handled for Pacific customers.

194. Due to the unique and varied arrangements that can be

negotiated with the customer, Pacific has never developed a

front-end interface for its own use for complex business

services, such as Centrex. In the event that Pacific

develops additional electronic functionality for complex

services to be used by Pacific’s retail operations, these

same enhancements will be made available simultaneously to

CLECs. In addition, Pacific is working to incorporate

complex services requirements into Pacific’s EDI Gateway

and LEX offerings.

CESAR

195. Pacific developed the CESAR Interconnection Service Request

("ISR") sub-system to support facility-based competition in

California in late 1995, before there were any industry

guidelines developed. CESAR/ISR was developed based on the

- 102 -

existing ASR ordering sub-system of CESAR that had been

serving Interexchange Carrier ("IXC") ordering of Access

Services since 1984. It supports ordering of unbundled

local loops, number portability and local interconnection

trunks. Pacific received 221,422 requests/supplements from

over 46 CLECs through the CESAR/ISR system from July 1997

to May 1999. Based on the functionality available in LEX

and EDI today, in addition to the flow through of many UNE

requests submitted through LEX/EDI, Pacific announced at

the April 1999 Quarterly Change Management meeting that

Pacific would retire CESAR/ISR in October 2000 using the

CMP 18 month guideline for retiring interfaces. This

announcement was followed by an Accessible Letter

distributed to all CLECs. Viveros Attachment GG.

196. Based on the direction set at OBF, Pacific has modified the

ASR ordering sub-system of CESAR to accommodate Local

Trunks. These changes were effective with the introduction

of OBF Version 19, on May 16, 1998. Version 20, effective

on February 27, 1999, implemented two additional changes

that enhanced the ordering of local interconnection

products. The OBF continues to work on additional changes

needed for the long term ordering process of local

interconnection products first raised by Pacific in early

1996. Based on requests for a bulk-data-transfer option,

Pacific is converting to the ASR process before all the

necessary OBF work is done. Pacific is committed to making

additional modifications to the CESAR/ASR system in

- 103 -

conjunction with the introduction of the OBF version that

includes the resolution of OBF issue 1177, "Ordering

Process for Local Interconnection Trunks."

197. CLECs can use the ASR process in requesting dedicated

facilities, such as unbundled transport or SS7 Signaling

Links. These are the same ordering procedures that are

used by Interexchange Carriers ("IXC") for the ordering of

Access Services, but are uniquely identified. These

guidelines are included in the workshop for the CLECs on

Interconnection offered by Pacific. The workshop is in

"train the trainer" format and is offered free of charge

for up to six students from each CLEC.

ORDER STATUS

198. Pacific also provides CLECs with three “real-time”

electronic interfaces to review pending service orders that

have been entered and accepted for processing. First,

through access to Pacific Bell Order Dispatch (“PBOD”), a

CLEC can review the service order; obtain status on the

Service Order (e.g., pending, dispatched, missed,

completed, or canceled); and review a narrative associated

with the category of status. This information is available

via the DataGate interface described previously. Status is

available on Basic Exchange Resale, Interim Number

Portability, Unbundled Loop and Unbundled Port orders.

Service order status is not available for special services

- 104 -

type orders (e.g., Multi Wire Center and Four Wire

Circuits).

199. The second interface for reviewing pending service orders

is Provisioning Order Status (“POS”) available via the

Toolbar. POS provides current service order information

(via searches by Service Order Number) regarding services

purchased from Pacific. POS is a Windows based GUI which

provides OSS access for obtaining provisioning status on a

CLEC’s basic exchange field work orders. POS provides

technician scheduling and routing information. CLECs may

also view due date status. POS allows retrieval status for

Resale Basic Exchange, Directory Number Call Forwarding

(“DNCF”), and UNE service orders. Access and training for

POS is available through the CLEC’s account manager.

200. The third available service order status for all products

is through the SORD system. Obtaining service order status

information from SORD and PBOD is the same status

information available and utilized by Pacific’s retail

channel.

ORDERING/PROVISIONING CONCLUSION

201. Building an OSS infrastructure for the ordering/

provisioning of local service is complex and takes time.

Therefore, Pacific offers multiple choices of electronic

interfaces to meet the needs of all CLECs, regardless of

size and information technology capability. The major

CLECs have underestimated the complexity of providing

- 105 -

service in the local exchange market and the difficulty of

developing an entirely new ordering process, EDI, within

the timelines CLECs had projected. For this reason, and to

accommodate CLECs that do not wish to develop their own

EDI, Pacific makes available the systems used for its own

internal operations, Starwriter and SORD, which provide

immediate OSS access. In addition, the LEX GUI allows

CLECs OSS access for resale and unbundled network elements

without the investment of developing their own EDI

capabilities.

202. Pacific is committed to providing sufficient processing

capacity to meet the demand of CLECs using any of Pacific’s

electronic interfaces. Pacific has made substantial

investments to increase its OSS capacity in preparation for

CLEC usage of Pacific’s electronic interfaces. Most of

Pacific’s electronic interfaces and OSS functions are

designed to be scalable, since these applications utilize

state of the art client/server technology. Pacific also

has processes in place to monitor capacity needs. The OSS

are monitored for CPU and memory utilization. Once the

engineering level is reached (approximately 60% utilization

for mid-range computers and approximately 90% utilization

for mainframe computers) analysis is performed to determine

which appropriate corrective action should be taken. Re-

allocation of CPU on existing hardware to increase an

individual OSS capacity may be sufficient. Where

additional hardware is required it is typically provisioned

- 106 -

within twelve weeks. Engineering points are set so that

the time period required to take either of these corrective

actions does not impact users, either the CLECs’ or

Pacific’s.

MAINTENANCE AND REPAIR

203. Maintenance and repair involves the exchange of information

which gives CLECs the capability to request repair of

resold services and unbundled network elements, and to

check on the status of trouble reports. Pacific provides

CLECs with several options for reporting trouble, and

requesting maintenance and repairs. CLECs can call the

LOC, as discussed in more detail in the Tenerelli

Affidavit. In addition, as discussed below, Pacific also

provides CLECs with a choice of two electronic interfaces

for access to its OSS maintenance and repair capabilities

for resold services or unbundled network elements: the PBSM

application and Electronic Bonding Interface (“EBI”).

PBSM

204. PBSM is a Pacific developed on-line interface that has been

used by Pacific retail business, CLECs and IXCs for

maintenance and repair administration since January 15,

1992. PBSM has been enhanced and made available to CLECs

so that they may electronically submit and check on the

status of trouble reports. In addition, PBSM has the

capability of initiating a mechanized loop test (“MLT”) and

receiving the test results for resold POTS lines and

- 107 -

unbundled network element combinations of an analog switch

port and 2-wire 8db analog loop (POTS like unbundled

network element combination) without initiating a trouble

report. PBSM also provides trouble history to the CLEC for

resale lines and unbundled network elements.

205. The PBSM test results provide a Direct Current (“DC”) test

which will reflect the ohms readings of the Tip to Ring,

Tip to Ground, and Ring to Ground, and the Alternating

Current (“AC”) readings for the same three measures. These

readings allow the CLEC to verify that the loop is balanced

or determine that trouble is in the loop or wiring and

equipment beyond the network interface device at the end

user’s premises. The test also provides a capacitance

reading so that the CLEC can determine the loop’s distance

from the central office. The test results also provide the

MLT test verification code and an English statement, such

as “Test OK.”

206. Pacific makes the training documentation and leader guide

available to the CLECs who attend PBSM training. This is

an instructor led class that walks the student through the

use of all of the PBSM functions and capabilities. Pacific

also makes available to CLECs a PBSM User Guide. The User

Guide displays copies of all the screens that the user will

see while using PBSM. It walks the user through “Logging

On” to PBSM, and describes in detail each of the functions

that are available with the PBSM application, complete with

copies of screen prints. The User Guide will be updated as

- 108 -

necessary by Pacific to document enhancements to the PBSM

application.

207. The PBSM application flows-through electronically to

Pacific’s back office systems. When the CLEC issues a

trouble report or requests the current status of an

existing trouble report, the PBSM application interfaces

directly to the back office systems to perform that

function. There are no manual interventions in the trouble

administration process for the creation of trouble reports

for resale services or unbundled network elements, provided

CLECs utilize the PBSM interface.

208. PBSM is a Pacific proprietary interface. However, the

interface utilizes many of the fields and definitions as

defined by the Electronic Communications Implementation

Committee (“ECIC”) and the American National Standards

Institute (“ANSI”) T1.227 and T1.228 standards. These

include, Trouble Report Format Definitions, Trouble Type

Codes, Trouble Status and Trouble State Codes. The

capability of requesting and viewing MLT tests on resale

and POTS like unbundled network element combinations is in

advance of the development of standards by ECIC with

regards to test results. Again, Pacific has taken a

proactive approach in the development of its interface

capabilities and making them available to CLECs, well ahead

of national standards.

209. Viveros Attachment RRR provides empirical data of CLEC use

of PBSM over the last several months. There has been a

- 109 -

steady increase of CLEC use of PBSM. To date, most CLECs

have opted to submit trouble reports by calling the LOC.

As a result, Pacific is required to spend considerable time

and resources to handle manual requests that could be

handled electronically by PBSM.

ELECTRONIC BONDING INTERFACE (“EBI”)

210. The Pacific EBI was developed to incorporate national

standards, based on ANSI T1.227/228, for trouble reporting

and obtaining status updates. EBI enables CLECs to submit

trouble reports, and to receive trouble status updates and

closure information. Pacific's EBI provides flow-through

capability for CLECs. For example, when a request to

create a trouble report is sent by the CLEC, the trouble

report will be opened in Pacific's back office system with

no manual intervention by Pacific. Due to the complexity

and the information technology resource requirements of

developing an EBI, larger CLECs are most likely to utilize

the Pacific EBI. Small and medium size CLECs tend to

remain in a manual mode or utilize the Pacific Bell Service

Manager (“PBSM”) application which does not require CLEC

development.

211. EBI is in operation today for trouble administration of

interexchange access services and local services. EBI is

currently being utilized by MCI for interexchange access

services and by MCI Worldcom for local service. From May

1998 through April 1999, EBI has successfully processed

- 110 -

numerous local trouble reports on their behalf. EBI has

been successfully "stress tested" in a prototype

environment to allow the creation of 4,000 trouble reports

per day. Transaction volume increases and any

corresponding impact on response time will continue to be

monitored by Pacific to determine when system capacity

should be increased. Trouble Reports, Viveros Attachment

SSS.

212. The process for establishing an EBI generally follows a set

pattern. After a CLEC has expressed interest in

establishing an EBI interface for local exchange service,

Pacific requests the EBI functional requirements from the

CLEC so that all attributes can be verified and operational

issues can be identified. EBI's information flow differs

from EDI in that the CLEC, as the first step of the

process, provides its functional requirements to Pacific.

A Joint Implementation Agreement ("JIA") is then developed

to document any differences that cannot be accommodated

between the functional requirements of the CLEC and

Pacific's back office system limitations. Once the JIA is

developed, the next step is for Pacific and the CLEC to

agree on a timeline and begin the process for the

following: 1) Installation of Circuits between the CLEC's

Gateway and Pacific's Gateway, as required; 2) Network

Testing; 3) Stack to Stack Testing; 4) Gateway to Gateway

Testing; 5) End to End Testing; 6) Network Verification

- 111 -

Test; 7) Operational Readiness Test; and 8) Live

Production.

213. The above process is complex and merits further

explanation.

· Installation of Circuits establishes the physicalfacility between the CLEC's EBI Gateway and Pacific'sGateway.

· Network Testing or Circuit validation verifies that theconnection between the CLEC and Pacific computers isoperational.

· Stack to Stack tests validate the interoperability of theupper layers of the Open Systems Interconnect ("OSI")stack, Session, Presentation, and the Association ControlService Element ("ACSE").

· Gateway to Gateway tests validate the interoperability ofthe Guidelines for Definitions of Managed Objects("GDMO") interface between the manager (CLEC) and agent(Pacific) over the Common Management Information Protocol("CMIP").

· End to End test executes an agreed-upon set of cases totest from the CLEC's back office OSS through the EBI andto the Pacific back office OSS. These cases areperformed to "test" the OSSs while the systems are not ina "live" production system.

· Network Validation tests the connectivity of the circuitsand connectivity in a live production environment.

· Operational Readiness is a subset of tests from the Endto End test cases that are now performed in theproduction environment.

· Production is the actual date established for the CLEC tobegin sending "live" trouble reports over the EBI.

- 112 -

214. Pacific has been involved in different levels of

negotiations with AT&T, Sprint, and MCI for the development

of an EBI for local service. AT&T had indicated that it

would initially deploy its EBI for local services.

However, on March 3, 1998, AT&T informed Pacific that its

work on EBI had been indefinitely postponed. AT&T stated

that it would continue development of its EBI possibly mid-

year 2000. Sprint turned up its EBI for interexchange

access services in April 1999. Sprint has since started

negotiations with Pacific regarding establishment of an EBI

for local service. On January 16, 1998, MCI became the

first CLEC to establish an EBI with Pacific for local

exchange service.

215. Pacific has indicated through performance data which

interface is used to place trouble tickets, with an

approximate breakdown for resale, unbundled loops and UNE

combinations. App. B, p. 4. Pacific has collected data on

trouble tickets received from CLECs, both by manner of

interface and major services from December 1998 through

March 1999 (see below).

- 113 -

TROUBLE TICKETS BY METHOD OF SUBMISSION/PRODUCT

December ‘98 January ‘99 February ‘99 March ‘99

PBSM EBI CALL PBSM EBI CALL PBSM EBI CALL PBSM EBI CALL

Resale 187

4.5%

112

2.7%

3802

92.7

%

231

5.9%

76

1.9%

3645

92.2

%

234

6.5%

74

2.0%

3302

91.5%

241

6.4%

97

2.5%

3446

91.1

%

UNE

Loops

0 0 1666

100%

0 0 1985

100%

0 0 1948

100%

0 0 2180

100%

UNE

Combo

s

0 0 0 0 0 0 0 0 0 0 0 0

LNP 0 0 1054

100%

0 0 1117

100%

1

.1%

2

.1%

1652

99.8%

1

0%

2

.1%

2690

99.9

%

BILLING

216. Billing involves the exchange of information necessary for

CLECs to bill their end users and IXCs, to process the end

user’s claims and adjustments, and to view Pacific’s bill

for services provided to the CLEC. Pacific provides CLECs

with a choice of five options for obtaining electronic

access to billing information: Custom Billing Disk/CD

Bill, Mag Tape and EDI 811 for resale; Carrier Access

Billing System (“CABS”) Bill Data Tape (“BDT”) for

unbundled network elements and interconnection products;

and Usage Extract Feed for resale, interconnection and UNE.

- 114 -

CUSTOM BILLING DISK/CD BILL

217. Custom Billing Disk/CD Bill is an electronic telephone bill

that provides CLECs with the same information contained on

their paper bill for resold services, plus much more.

Custom Billing Disk/CD Bill is a user friendly PC software

package designed to increase the efficiency of managing

telecommunications expenses. Various reporting options

allow the CLEC the capability of analyzing their billing

data within Custom Billing Disk/CD Bill. In addition, the

CLEC can extract the billing data to its internal systems,

thus allowing unlimited analysis of the data.

Specifically, Custom Billing Disk/CD Bill enables CLECs to:

· Receive their monthly Pacific bill on diskette or CD ROM.

· View the bill on screen and search for informationquickly.

· Generate a variety of standard, customized, or historicalreports.

· Print any portion of the bill or any report generated bythis service.

· Track IntraLATA Toll calls.

· Export data to other software programs, word processors,or spreadsheets.

218. Pacific has a dedicated group that provides on-site Custom

Billing Disk/CD Bill demonstrations for CLECs and maintains

a toll free number for CLEC assistance. Currently, Pacific

is providing Custom Billing Disks to five CLECs and CD Bill

to another 26 CLECs.

- 115 -

MAG TAPE

219. Magnetic (Mag) Tape is a standard 9-track magnetic reel or

cartridge which provides details of billing records for

resold services in a medium that can be used in a

mechanized environment. Data is available in ASCII or

EBCDIC language, in Exchange Message Record (“EMR”) format.

Mag Tape includes flat-rated charges, usage sensitive

charges, call detail and Customer Service Record (“CSR”).

Technical support and a User Manual are available. Six

CLECs are currently receiving Mag Tape.

EDI 811

220. EDI for billing provides an interface that enables CLECs to

receive their resold services billing data in an industry

standard electronic format utilizing the EDI 811

Transaction Set. The billing data consists of the same

information that appears on the CLEC paper bill for resold

services. Pacific’s EDI bill provides the data elements

that the Telephone Bill Work Group (“TBWG”) has defined as

industry guidelines for billing. EDI billing transmits an

811 Transaction Set that includes flat-rated charges,

usage-sensitive charges, call detail, and CSR. EDI billing

enables access to billing information two to three days

earlier than via paper bill. To date, two CLECs are

receiving bills via the EDI 811 Transaction Set, with two

additional CLECs anticipating starting in July 1999.

221. Pacific also makes available a team of billing specialists

to provide CLECs with EDI technical support. Their purpose

- 116 -

is to ensure the CLECs understand and are completely

comfortable with the billing data that is transmitted. For

CLECs who choose to utilize EDI, technical support is

available to answer questions and resolve any issues that

arise with regards to EDI billing. Pacific has delivered

on its promise to provide OSS access to all CLECs, as

proven by offering electronic billing options for small,

medium and large CLECs. EDI and Mag Tape are utilized by

CLECs of all sizes, while Custom Billing Disk/CD Bill is

typically utilized by small to medium CLECs. BDT

222. Pacific makes available to CLECs today a BDT, from its CABS

database, containing the same information that would appear

on the CLEC’s paper bill for unbundled network elements and

interconnection products. The BDT follows industry

standard Billing Output Specifications (“BOS”) guidelines

as defined by the Technical Review Group (“TRG”). The BDT

is offered electronically via CONNECT:Direct™ or on

magnetic tape. To date, nine CLECs are receiving billing

information via BDT.

USAGE EXTRACT

223. On a daily basis, Usage Extract provides CLECs,

electronically or via magnetic tape, with information on

the usage generated by its accounts in industry standard

Exchange Message Record (“EMR”) format. This capability

became available for CLEC use in April 1996. Currently 45

resale CLECs receive resale usage and two CLECs receive UNE

- 117 -

usage via CLEC Usage Extract. In addition, 26 facilities

based CLECs receive Meet Point Billing usage in this same

manner.

224. Pacific has produced a Usage Extract Technical Guide. This

document details, among other things, transmission vehicles

supported by Pacific, the setting of certain indicators,

and file characteristics and packing requirements with

header and trailer details. In addition, it outlines

Pacific and CLEC responsibilities and data center mailing

information. This document is provided to any CLEC that

has expressed an interest in Usage Extract and is provided

in paper format or electronically via e-mail.

225. At the option of the CLEC, a test tape or file is provided

by Pacific to enable the CLEC to analyze a sampling of the

EMR records. Before a CLEC is turned up live to receive

Usage Extract, Pacific performs testing with the CLEC to

ensure that the CLEC can receive the Usage Extract and can

process the data. The CLEC is also provided an initial copy

of the industry standard EMR document. Pacific provides

the CLEC assistance with regard to processing of the data,

interpretation of records and applicable indicators to

ensure the CLEC is comfortable with the data provided and

the process so they can develop their billing system.

226. As a matter of clarification with regards to the data

provided to CLECs via the Usage Extract feed, Pacific

includes in the daily Usage Extract feed whatever is billed

on the monthly bill as usage sensitive, either for resale

- 118 -

or for unbundled network elements. There is no usage

recorded for flat-rated local calls or attempts to place

such calls.

227. Viveros Attachment TTT provides empirical data by month and

year of Resale CLEC usage provided in Pacific’s Usage

Extract over the last several months with UNE usage

messages included in totals as of April 1998. CLEC use of

this electronic interface is robust and millions of

messages are exchanged monthly.

CRIS BILLING

228. There are two billing systems in use at Pacific. They are

the Customer Record Information System (“CRIS system”) and

the Carrier Access Billing System (“CABS”).

229. CRIS is used to bill Pacific’s retail products to its

residential and business customers. In addition, CRIS is

used by Pacific’s wholesale operations to bill CLECs for

resale products. CRIS has proven to be a timely and

accurate method of creating bills throughout its 24 years

of commercial use in California. The system processes 4

billion usage records monthly and creates 12.5 million

bills monthly that are issued to customers throughout

Pacific’s territory. The system has been developed to

comply with all regulatory requirements and industry

guidelines for retail billing.

230. CRIS is the same system, with the same processes used for

creating bills for Pacific’s retail and wholesale

- 119 -

customers. As such, CLECs benefit directly from the

expense Pacific has spent over the years to develop a

highly controlled and efficient retail billing system. For

this reason, any degradation in the system for CLECs would

be detrimental to Pacific as well.

CABS BILLING

231. Pacific uses the CABS to issue bills for IXC customers in

its access operations and for CLECs using UNE and

interconnection products. CABS has been used to create

bills for IXC’s access products since 1984 and for CLEC

customers since 1996. The system produces 3.5 billion

usage records monthly and creates 500 bills monthly for

Pacific’s customers. In its wholesale operations, CABS is

used to create bills for UNEs, including loops, switch

ports, loop and port combinations, local transport, and

interconnection. Because CABS is the same system used for

creating bills for IXC customers, any degradation in the

system for CLECs would be detrimental to Pacific’s access

operations as well. This acts as an additional protection

against discrimination against a CLEC in Pacific’s

provisioning of billing services.

Billing Rate Changes

232. Pacific assigns prices to products and services purchased

by CLECs based on existing or new rating processes defined

in Pacific’s interconnection agreements with CLECs. Rates

themselves are maintained in billing rate files. In

- 120 -

addition, there are several tables which contain a variety

of CLEC-specific data necessary to accurately assign prices

or discount percentages based on negotiated or arbitrated

rates. Changes to rates or percentages are made within 30

days from the billing organization’s receipt of the change.

Changes in rate structure can be accomplished through

system changes that normally require a full development

cycle of six months. When Pacific is unable to immediately

assign UNE prices in accordance with an interconnection

agreement, Pacific uses existing rating routines that favor

the CLEC by assigning prices at or below those defined in

their agreement until such time as the system changes can

be completed. An automatic adjustment is then made to the

CLEC bill to reconcile the past retail rates to those

included in the interconnection agreement, and an

appropriate refund is made to the CLEC. These scenarios

would be associated with initial implementation of an

interconnection agreement, re-negotiated rates in an

existing agreement, or as a result of arbitration or

regulatory rulings.

Billing Dates

233. Each customer is billed monthly by Pacific for the products

and services purchased. This billing includes monthly

recurring charges, usage charges, and one-time charges.

Pacific divides its billing in CABS into 12 monthly bill

dates. Pacific uses 3 billing dates per month per region

- 121 -

(Northern CA and Southern CA) to bill CLEC products and

services for UNE and interconnection. These dates are the

1st, 14th and 26th. Of these three, the 1st is

specifically reserved for CLECs only. IXC billing can also

occur on the 14th and 26th bill dates. The remaining 9

monthly bill dates are used for IXC billing only.

234. Pacific has 19 bill dates per month per region for resale

customer accounts billed in CRIS. This is the same number

of bill dates Pacific uses for its retail customers.

Billing Cycles

235. The bill cycle refers to the process of creating, auditing

and mailing a bill. The billing cycle starts on the

billing date of each month. Customer account information

that is effective as of the bill date and updated to the

appropriate CRIS or CABS customer databases is used to

process bills. The customer account information is

established and changed through service or record order

activity. By the third workday after the bill date, CRIS

and CABS assemble all the billing records they have

accumulated over the past month (since the last bill date)

and create a data file with the usage, product and service

information needed to create a bill.

236. The data is then processed through a series of edits that

verify both the format and content of the data. Data that

does not pass these program edits is distributed to the

error correction unit where problems are investigated and

- 122 -

corrected. Corrected data is resubmitted to the system for

processing. The billing data and account information that

satisfies the program edits is used to create control

totals and bills that can be reviewed for accuracy. The

control totals are used for fluctuation analysis of

revenues and bill volumes.

237. Bills that will be printed on paper are produced in one of

the Pacific Bill Print Centers. These centers use

specialized hardware and software to print, assemble, and

prepare the bills for mailing. These centers create and

mail both the retail and wholesale bills using the same

hardware, software and personnel. Bills are ZIP-code

sorted and then delivered to the U.S. Post Office for

delivery to customers.

238. Pacific offers consolidated bill rounds for resale. This

offering was announced via Accessible Letter CLECC 99-206,

dated June 2, 1999. App. B, p. 4; Viveros Attachment UUU.

Resale Select Bill Date allows resale CLECs to consolidate

their new or existing CRIS bill rounds to as few as one

bill round per billing region (North and South). Prior to

the initiation of Resale Select Bill Date, a CLEC might

receive up to a maximum of 38 bills, 19 for each region.

Bill consolidation allows CLECs to minimize costs

associated with billing. UNE bills (BANS) are processed

via CABS and are already consolidated to one of three bill

dates in a month, by region.

- 123 -

Billing Timeliness

239. Whether through paper or electronic means, Pacific is

providing billing timeliness. Bills are mailed or

transmitted by the fifth workday after the bill date. This

is the same guideline used for both retail and CLEC

accounts.

PACIFIC PARTICIPATION IN OBF

240. Pacific participates in the OBF. As part of the OBF,

Pacific works with other ILECs and CLECs to help shape the

national guidelines for billing. Pacific is in compliance

with all current OBF billing guidelines.

BILLING CONCLUSION

241. The wholesale billing processes and systems were built

using the knowledge, experience and pre-Act billing systems

that Pacific has invested millions of dollars to develop.

These systems are in use today processing billions of usage

records monthly and issues millions of bills monthly.

242. As a result of the 271 Workshops, the Commission ordered

that Pacific resolve all outstanding problems it has with

single bill and single tariff and that it has paid any

monies due to other carriers. FD, p. 104, App. B, p. 5.

243. Originally Pacific was unable to process originating meet

point billing records from CLEC’s on single bill/single

tariff. As of the June 1999 CABS billing release, Pacific

has begun to bill IECs for CLEC originating traffic on

behalf of all CLECs on single bill/single tariff using

Pacific’s own tandem recordings.

- 124 -

244. Pacific has sent letters to all existing single bill/single

tariff CLECs requesting that they contact Pacific

immediately if they have any outstanding single bill/single

tariff issues. As of this writing, none of these CLECs has

identified any remaining issues.

245. Two claims have been submitted by TCG and PacWest. These

CLECs claimed they lost monies because Pacific did not

convert them over to multiple bill/single tariff meet point

billing to coincide with their tariff effective date.

However, these CLECs interconnection agreements providing

for multiple bill/single tariff billing were not in effect

on the tariff effective date. Once the multiple

bill/single tariff contracts were approved by the CPUC,

both CLECs were converted to multiple bill/single tariff.

246. All outstanding monies due to CLECs with single bill/single

tariff meet point billing arrangements were paid on June 4,

1999.

OSS TEST PLAN

247. In its Final Decision, the Commission required Pacific to

file an OSS test plan with the Commission and serve all

interested parties by January 11, 1999. The Final Decision

set forth various parameters for the testing of Pacific’s

OSS interfaces. App. B, p. 6. In particular, the

Commission’s decision required Pacific to:

· submit a detailed test plan with the Commission andinterested parties describing the scope and methodologyof the test. The test plan shall:

- 125 -

· identify the scope of the test by:

· enumerating the order types and permutations of ordertypes it plans to test;

· delineating the order types which the company believes itdoes not need to test because it has sufficientcommercial volumes and three months worth of performancemeasures;

· indicating the end-to-end process it proposes to test andhow the proposed test will simulate this end-to-endprocess;

· showing how specific interfaces will be tested;

· explaining the method for conducting the test and themethodology for compiling and analyzing results;

· describing the benchmarks for evaluating the test; and

· comparing its test plan to Bell Atlantic OSS EvaluationProject Master Test Plan developed in New York.

248. On January 11, 1999, Pacific filed a detailed OSS Master

Test Plan (“OSS MTP”) with the Commission and served all

interested parties. Pacific responded thoroughly and

directly to each compliance requirement, as outlined above.

Included in this January 11, 1999 filing, Pacific provided

a comparison of its MTP to the BANY test plan, as outlined

in BANY’s Master Test Plan document, dated July 31, 1998.

Viveros Attachment VVV. Interested parties filed comments

on Pacific’s OSS MTP on February 1, 1999. App. B, pp. 6-7.

249. Pacific also authorized the Telecommunications Division

(Staff) of the Commission to contract with a consultant

experienced in OSS interface testing to assist in the

Staff’s review of Pacific’s OSS MTP and the results of the

- 126 -

tests, as directed in the Final Decision. Final Decision,

pp. 116-117. In January 1999, Staff hired Telcordia

Technologies (“Telcordia”) as the Technical Advisor to the

Staff. Telcordia’s initial task was to evaluate Pacific’s

OSS MTP.

250. On April 23, 1999, an Assigned Commissioner’s Ruling

(“ACR”) was issued that requested interested parties to

comment on eight issues related to OSS testing. Appended

to the ruling were two Telcordia reports of Pacific’s OSS

MTP. The eight issues identified in the ACR were in the

following areas: Electronic Data Interchange (“EDI”),

Master Test Plan, Business Rules, Test Scenarios, Scope

Process Covered, Billing, Timing, and Role of Independent

Third Party.

251. Pacific and interested parties requested the Assigned

Commissioner to convene collaborative workshops for parties

to discuss and reach agreements on enhancements to the OSS

MTP, in lieu of submitting comments. In meetings with

staff, Pacific also shared proposals for enhancing the OSS

MTP. On May 21, 1999, an ACR granted the request for

collaborative workshops (“May 21, 1999 ACR”). The

workshops were scheduled and convened for seven days

starting on June 7, and ending on June 15, 1999.

252. On May 24, 1999, pursuant to the May 21, 1999 ACR, Pacific

submitted a summary of enhancements Pacific proposed to its

January 11, 1999 OSS MTP. On June 2, 1999, Pacific

submitted a revised OSS MTP Version 2.0 that incorporated

- 127 -

all of Pacific’s proposed enhancements, and that contained

a detailed comparison of Pacific’s MTP with the BANY OSS

evaluation Project Master Test Plan. Viveros Attachment

WWW - OSS Master Test Plan Version 2.0. The revised OSS

MTP was the basis for discussion during the collaborative

workshops which concluded on June 15, 1999.

253. On June 29, 1999, the Assigned Commissioner issued another

ruling asking the parties to comment on the revised OSS MTP

Version 3.0, that the Commission and Telcordia prepared as

a result of the OSS testing workshops. The Commissioner

found that the MTP “reflects the hard work, compromise and

due diligence of the numerous parties that gathered” for

the workshops. Comments on the MTP were submitted by the

parties on July 12, 1999.

254. The goal of the MTP is to provide a plan to validate and

assess Pacific’s readiness and capability to provide pre-

ordering, ordering, provisioning, maintenance and repair

and billing OSS functionalities to CLECs.

255. The validation will include an assessment of functionality

including performance measurements and capacity (relative

to mechanized systems) for Pacific OSSs. The purpose of

testing the OSSs is to demonstrate operational readiness,

performance, and capability to provide pre-ordering,

ordering, provisioning, repair and maintenance and billing

functionality to the CLECs, where such readiness and

capability are not demonstrated through live commercial

volumes.

- 128 -

256. The OSS testing will be performed in addition to normal

daily retail and wholesale order and repair activities in a

production environment. In other words, testing order and

repair volumes will be in addition to normal production

volumes.

257. The OSS test is a ”blind” test to ensure objectivity.

Pacific employees will not be aware they are processing

test orders or pre-order queries; will not know when the

test orders or pre-order queries will be submitted; will

not know the product mix for the test orders other than at

the highest levels.

258. By agreement of the parties, the test includes order and

product types associated with various modes of CLEC entry:

Resale, LNP, UNE, Loop with Port, Basic and Assured Loops,

xDSL, DS1 Capable Loops, and stand-alone directory

listings. The functional areas of pre-ordering, ordering,

provisioning, billing, and maintenance and repair will be

tested. Testing will include both residence and business

orders encompassing new, conversion “as specified,” partial

configurations, disconnects, cancellations, supplementals,

and suspend and restore order types. From an ordering

perspective, the testing will generate acknowledgements,

error rejections, FOCs and SOCs. In addition, testing will

include a variety of feature combinations, directory

listings (“as is” and “as specified”), hunting, 900/976

blocking, and toll restrictions.

259. The test focus includes:

- 129 -

· End-to-End/Functionality Test (FT) - will test end-to-endprocesses from pre-ordering through provisioning,billing, and maintenance and repair. Testing will beperformed with Pacific’s production OSSs and processes.Testing will focus on Unbundled Network Element (UNE)Loop with Port, Basic and Assured Loops, DS1 CapableLoops, and Digital Subscriber Line (xDSL types ofservices). For xDSL product test cases, the K1023-LoopFacility Pre-Qualification process will also be tested.Additional testing will also be completed for stand-aloneDirectory Listings and E-911.

· Capacity Test (CT)- will test the capacity of Pacific’spre-ordering and ordering processes for Resale, UNE Loopwith Port, Basic Loop with and without NP, stand-aloneLocal Number Portability (LNP) and stand-alone DirectoryListings types of service. Testing will be performedwith Pacific’s production systems and processes.

260. Pacific production systems will be used to conduct the End-

to-end/Functionality Test. The Functionality Test will

assess the DataGate and Verigate interfaces for

preordering, and the EDI and LEX for ordering. AOG and

LASR systems will also be included in the ordering

functionality test. The PBSM Interface will be used for

trouble reporting. The systems required to perform

provisioning, maintenance and repair, and billing for

wholesale are the same Pacific legacy systems used for

retail customers and will be included in the functionality

test.

261. For the Capacity Test, Pacific production systems will also

be used. The Capacity Test will include DataGate and

Verigate interfaces for preordering and EDI and LEX for

- 130 -

ordering. The Capacity Test will be through SORD

distribution and includes the backend system that provides

Firm Order Confirmation (“FOC”).

262. The OSS MTP provides for a documentation and process

analysis related to scalability of OSS interfaces and

wholesale service centers. An analysis will also be

performed on the ability of the Test Generator to develop

interfaces and establish connectivity to Pacific’s OSS

using Pacific’s system documentation and guidelines. These

additional facets make testing forward looking, and not

just an evaluation of current performance.

263. As defined in the OSS MTP Version 3.0, the Commission is

the test owner and will provide for overall project

management. Attachment XXX. The independence and the

expertise of the tester are two important attributes of OSS

testing. The OSS MTP addresses the importance of these

attributes by defining roles and responsibilities that

provide for the highest level of involvement that the

Commission and independent third parties will have in the

testing process.

264. The implementation of the OSS MTP requires direct project

management by the Commission with assistance from a

Technical Advisor, Telcordia. Although Pacific agreed to

pay for Telcordia’s evaluation, the Commission has control

over selecting, directing, monitoring and supervising the

testing consultants. Implementation of the OSS MTP also

requires two additional distinct roles: Test Generator and

- 131 -

Test Administrator/Manager. The Test Administrator/Manager

will oversee test execution as defined by the OSS MTP and

assess the processes and test results. The Test Generator

will develop interfaces and install connectivity using the

same set of requirements and documentation available to the

CLECs in the development of pre-ordering/ordering system

interfaces. The Test Generator will also be responsible

for the creation and input of test orders(LSRs) and pre-

ordering queries.

265. The development of the OSS MTP provided ample opportunity

for the CLECs to provide input into the scope, methodology,

strategy, and overall approach to OSS testing. Among other

things, the OSS MTP incorporates CLECs’ input in

determining order types and test volumes, as agreed upon in

the OSS testing collaborative workshops. The OSS MTP

evidences the efforts of the CPUC to ensure and provide the

opportunity for all parties’ participation and involvement,

starting with the 271 Workshops in August 1998 through the

OSS testing workshops in June 1999, and including the

various comment cycles on Pacific’s original MTP filed on

January 11, 1999, and on Telcordia’s reports analyzing the

original MTP. The workshops provided a collaborative

setting to identify issues and develop solutions that

directly contributed to the development of the OSS test

plan.

266. Ultimately, all testing decisions related to interfaces,

transaction and order volumes, and transaction and order

- 132 -

types were based on the collective inputs of interested

parties during the OSS Testing workshops convened on June

7, 1999. Moreover, the measures of success to be applied

as part of the OSS MTP were based on performance measures

and benchmarks that were in most instances jointly agreed

to by the parties. OSS testing, reporting of results, and

preparation of an analysis report is expected to be

completed by October 1999.

CONCLUSION

267. As demonstrated above, Pacific has provided various

interface options to the CLECs, demonstrations to aid them

in choosing the interface that is most effective and

efficient for their needs, documentation ranging from

brochures to technical specifications, and classwork to

teach CLECs to use the options. Pacific developed

interfaces well ahead of the establishment of industry

standards in several instances. Where commercial volumes

do not exist, Pacific’s interfaces are being tested to

demonstrate they provide CLECs with the ability to perform

all OSS functions in substantially the same time and manner

as Pacific’s own service representatives.

[SIGNATURE PAGE FOLLOWS]

- 133 -

I declare under penalty of perjury that the foregoing is true

and correct to the best of my knowledge.

Executed on ____________, 1999

________________________________

Christopher J. ViverosDirector – OSS Planning andRegulatory Support