› publicaffairs › publicpolicy › other › viveros › viveros-affidavit.pdf affidavit of...
TRANSCRIPT
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
“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