*************************************************** NOTICE *************************************************** This document was converted from WordPerfect to ASCII Text format. Content from the original version of the document such as headers, footers, footnotes, endnotes, graphics, and page numbers will not show up in this text version. All text attributes such as bold, itallic, underlining, etc. from the original document will not show up in this text version. Features of the orginal document layout such as columns, tables, line and letter spacing, pagination, and margins will not be preserved in the text version. If you need the complete document, download the WordPerfect version or Adobe Acrobat version, if available. ***************************************************** FEDERAL COMMUNICATIONS COMMISSION In Re: ) ) COMMON CARRIER BUREAU ) OPERATIONS SUPPORT ) SYSTEMS FORUM ) Volume: 2 Pages: 151 through 293 Place: Washington, D.C. Date: May 29, 1997 Before the FEDERAL COMMUNICATIONS COMMISSION Washington, D.C. 20554 In Re: ) ) COMMON CARRIER BUREAU ) OPERATIONS SUPPORT ) SYSTEMS FORUM ) Room 856 FCC Building 1919 M Street, N.W. Washington, D.C. Thursday, May 29, 1997 The parties met, pursuant to the notice, at 9:02 a.m. BEFORE: RICHARD WELCH Common Carrier Bureau Federal Communications Commission APPEARANCES: On behalf of the FCC: RICHARD WELCH KALPAK GUDE Panel I: STUART KUPINSKY Department of Justice CHARLOTTE TERKEURST Illinois Commerce Commission JOHN LENAHAN Assistant General Counsel, Ameritech APPEARANCES: (CONT'D) Panel I (Cont): ELIZABETH HAM Executive Director, Interconnection & Resale Technical Implementation Southwestern Bell Telephone Company WAYNE FONTEIX Local Markets Director, AT&T PATRICK SOCCI Vice-President MIS, Teleport Communications Group VENKATES SWAMINATHAN Director of Marketing, Telesphere Solutions Panel II: BETH LAWSON Area Manager, Finance Operations Southwestern Bell Telephone Company MARY BERUBE Senior Product Manager, Network Marketing & Sales SNET ROBERT V. FALCONE District Manager, New Market Development, AT&T DENNIS PERKINS Vice-President Corporate Controller, Brooks Fiber Panel III: GLORIA CALHOUN Director, BellSouth DAVID SWAN Vice-President Carrier Services, Bell Atlantic BOB WELBORN Director, Operations Planning, Sprint ROD COX Manager of Market Expansion/Operations, Consolidated Communications, Inc. APPEARANCES: (CONT'D) LARRY BLAINE, Staff Economist, Nevada PSC DIANE MOORE, MCI TRACY STROMBOTNY, LCI NANCY DALTON, AT&T JAY BRADBURY, AT&T HANK CLUBFELD, SAIC I N D E X VOIR WITNESSES: DIRECT CROSS REDIRECT RECROSS DIRE None. Hearing Began: 9:02 a.m. Hearing Ended: 1:00 p.m. P R O C E E D I N G S MR. WELCH: Good morning. Welcome to day two of the FCC's forum on operational support systems and the role in developing local competition. I am Richard Welch from the Common Carrier Bureau. I have a few brief announcements before we get started. First of all, and this may be the most important thing we say all day. If there is an individual named James Maple and you have lost a credit card, you should check with the desk down on the first floor. They are holding that down there for you. Before ten people go running down there to try to claim that, you might have to identify yourself. I want to reiterate something that I said yesterday about the ex parte rules and the relationship to this proceeding. We are exploring these issues in the context of the docket on local competition, Docket 96-98, and a video of this proceeding will be put in the record of that docket. Again, I want to remind everybody about the relationship to Section 271 applications. We do have a couple of pending applications before us that raise some of these issues, but the point of this forum is not to address the merits of those pending applications, and I would ask everybody's cooperation in that regard. I would also like to recognize a few people from my staff who worked very, very hard to put this on today. These are all folks in the Policy Division in Common Carrier, and a lot of work went into trying to organize this forum and arranging the panels and inviting all the panelists and everything. I would like to thank from my staff Jake Jennings, Robb Tanner, Rochelle Cohen from the front office, Anthony Butler, Don Stockdale, Vaikunth Gupta and Lisa Gelb, and I would particularly like to acknowledge Kalpak Gude, who has done a yeoman's work in organizing this forum. (Applause.) MR. WELCH: We will proceed today along the same lines that we did yesterday. We have three panels set up. I think we had a good session yesterday. We had some interesting discussions, and I think we learned a few things. For example, we learned that the Baltimore Orioles are in fact eight games ahead of the New York Yankees, and I will update that for you this morning. Both teams won last night, so that lead continues to be eight full games. We also learned that baseball sometimes can be a useful metaphor in this area, and so the next time that any of you go to a baseball game and you see an infielder boot a ground ball and get charged with an error, you can turn to the guy sitting next to you and say, "Doesn't that just remind you about competition in the local loop and operational support systems?" He'll probably look at you with a funny look on his face and take a sip from his beer and then get up and move to a different seat. Without any further ado, we will get into the panelists today. We have three of them. We will start with a panel on ordering and provisioning, which will run from 9:00 until 10:30 a.m., take a quick break, come back at 10:45 a.m. with a panel on billing issues, take another 15 minute break and come back at 12:00 p.m., from 12:00 to 1:00 p.m., with a panel on repair and maintenance. The focus on these three panels is to get into a little bit more detail on some of these individual issues involving operational support systems. If I could invite the panelists from the first panel to come on up here? I will run over, and we will get started. (Pause.) MR. WELCH: Good morning. Actually, I have not had a chance to meet everybody on the panel, but welcome and thank you for coming. I hope we have everybody in order as I read through the names here. If I mess this up, please raise your hand, and we will correct it. Starting over on the far right we have a familiar face to some of us at the FCC, Stuart Kupinsky, who is with the Department of Justice and whose title is trial attorney. I do not think that does him justice, but welcome, Stuart. Next to Stuart's right is Charlotte TerKeurst from the Illinois Commerce Commission. Charlotte is manager of the telecommunications division at the ICC. Sitting next to Charlotte is John Lenahan from Ameritech who was on a panel yesterday. John is assistant general counsel at Ameritech. Sitting next to John is Elizabeth Ham. Welcome. Elizabeth is with Southwestern Bell where she is the executive director of interconnection and resale technical implementation. That is a mouthful. How do you get that on a business card? MS. HAM: You do not want to. MR. WELCH: Sitting next to Elizabeth is Wayne Fonteix from AT&T. Wayne is director of local markets. Sitting next to Wayne is Pat Socci from TCG. Pat is vice-president in charge of MIS. Sitting next to Pat, and please forgive me because I hope I get this right, is Venkates Swaminathan. Is that close? MR. SWAMINATHAN: Yes, very close. MR. WELCH: Thank you. He is with Telesphere Solutions, Inc., a vendor, and he is director of marketing. We welcome him to the panel today. We will proceed like we did with the other panels. The panelists will make a brief opening statement. We ask everybody to please try to hold it to around three minutes. After everyone is through with their statements, we will ask some questions from the Bureau, and then hopefully we will have a little bit of time for some questions from the audience. Why do we not start at the far right with Stuart Kupinsky from the Department of Justice? Stuart? PANEL I MR. KUPINSKY: Thanks, Richard. On behalf of the Department, I want to again express our appreciation to the FCC for organizing this timely and informative forum. On my own behalf, I need to point out that my comments are my own and do not necessarily reflect those of the Department or the Commission. The Commission defined access to OSS functions as both an unbundled element and the terms or conditions or part of the terms or conditions of offering other element services. In discussing these incredibly complex systems and the intricate legal issues surrounding them, I find it helpful to remember that dual definition and to keep in mind the rather straightforward goal of Section 251 of the Act and the Commission's rules. The goal was obviously not to provide access to a series of large computer systems and databases in the depths of an incumbent network, but rather the goal was to spur competition by providing, among other things, resale services and unbundled elements. The Commission determined, though, that making these complex operation support system functions available was a key ingredient in facilitating this over arching goal of competition. Specifically regarding ordering and provisioning functions of OSS, at the current embryonic stage of competition these functions are critical to new entrants who are just now signing up their first customers and are depending on these functions to do so. Thus, a customer's first impression of a new entrant will likely depend on the performance of these functions by an incumbent competitor. For both practical and legal reasons, I also think it is helpful to separate out the discussion of the ordering interfaces between carriers from the OSS functions performed by an incumbent when they receive an order via the interface. The interface itself can be thought of as simply a delivery system, making a part of the means for providing access to OSS functions, but, more generally, part of the mechanism for providing resale services and unbundled elements. Thus, even if the Commission had never identified access to OSS functions as a requirement under Section 251, I would suggest that some such automation and some such interface would have been a practical requirement of providing resale services and unbundled elements. Once an order is received over an interface, it may initiate a series of incumbent OSS functions. The extent to which this interaction between the interface and the OSS functions is automated has a significant effect on the quality of OSS access and the efficiency of service and element provisioning. As a result, I think our discussion today needs to address both the interfaces themselves and the interaction of these interfaces with the OSS functions. It is this combined perspective that encompasses the Commission's rules regarding access to OSS functions. If either piece of this puzzle is missing, a CLEC may not receive the nondiscriminatory access to OSS functions or the meaningful opportunity to compete using resale services and unbundled elements that the Commission's rules require. This is not to say that all order and provisioning functions need to or should be automated. Where the incumbent automates processing steps in its own retail operations, analogous functions provided to CLECs should be similarly automated. Where the lack of automation in either piece of this puzzle precludes a meaningful opportunity to compete, however, the Commission's rules would suggest that automation is necessary. Finally, as an additional guide, standard setting bodies such as ATIS can serve as a vital common denominator of automation in this regard. Thus, rather than getting carried away either figuratively or literally with regard to providing access to OSS functions as a separate network element or goal, and in particular the ordering and provisioning, these particular functions are perhaps best viewed as creating the critical terms or conditions of providing resale services and unbundled elements under Section 251. Thank you. MR. WELCH: Thanks, Stuart. Next we will hear from Charlotte TerKeurst from the Illinois Commission. Charlotte? MS. TERKEURST: Good morning. It is good to be here. I was thinking about Richard's baseball analogy. If I go very far, I will probably show my ignorance of the game, but there are some analogies, and I would like to point out that we have seen one game, the opening game of the season. The incumbents have so far fairly soundly trounced the new entrants that are trying to get in, and we are trying to figure out whether it is because the new entrants really are not very good at what they are doing or whether the incumbents are throwing spitballs. MR. WELCH: There are 162 games in the major league season, if that helps your analogy. MS. TERKEURST: Yes. I think we need a little more experience. That is kind of summing it up in a nutshell what the Illinois staff has found. Like Stuart, obviously I have to have a very big caveat that what I say here is strictly my views. This issue is pending before the Illinois Commission as well, and I certainly do not speak for the Commission. We also cannot determine how it is going to come out by reviewing their play books, you know, and trusting them that they will play fair and square in the future. We are taking the position that we need some more experience. We need to see how things are actually operating. We certainly cannot figure out how they are going to play baseball based on how they have played soccer. We found in several realms of hearings in Illinois that significant progress is being made. I will say that. I think good progress is being made. I think Ameritech is operating in fairly good faith in trying to get these systems up and running, but our basic conclusion is we still need to see a little bit more progress before we are comfortable with how things are going. With that in mind, I guess what I can do in the short time that I have is point out some of the items that we are looking at, some of the things that we think need to be examined in deciding whether these systems are working reasonably well. There was a good deal of discussion yesterday describing the electronic interfaces that the various carriers have. Ameritech does use an electronic interface EDI for ordering resale services. They use what is called ASR for ordering unbundled network elements, and that necessarily requires manual intervention on every order. I know plans are being made to move that to a more automated system, but in the meantime that does raise concerns about their ability to process large numbers of orders if they were to develop in the marketplace. The EDI function for resale includes order confirmation, order jeopardy, order status and order completion. Resellers are currently using the EDI order confirmation and order completion functions, but the order jeopardy and order status functions are not yet being used at all by any resellers. The ASR provisioning interface for unbundled services offers only order confirmation, and that is being used. We are still looking in Illinois for some more experience on ordering and provisioning of unbundled switching and network platforms in particular. There was discussion yesterday about Ameritech working with AT&T to try to get a trial underway, but at this point they really have not reached agreement on how you order, let alone provision these functions, so we are following that trial with great interest. We have taken the position that Ameritech should work with the new entrants as much as possible to try to help them get their side of the interfaces up and running, to work out any ambiguities that may exist in the specification manuals and things like that. Presumably they are good faith. Reasonable people can interpret spec manuals very differently, and a good bit of work between the companies is needed. I think a good bit is actually happening in that regard. The information that came in in the recent hearings has shown significant improvement in the percentage of orders that are able to be processed electronically without manual intervention. That was very good to hear. I am running out of time. Let me just mention the stability of OSS specifications. There was some talk yesterday about the need to manage the changes as systems are upgraded in a way that does not keep new entrants from having problems continuing to operate. We talked yesterday about the need to make sure that OSS capacity can expand as needed. Certainly the volumes that are going through to date do not really give us great confirmation that they will be able to handle the volume of orders that we are hoping will materialize in the near future. The parity of access to OSS functions again is an item that needs to be looked at carefully. The measurements that are reported need to be looked at carefully to make sure that they actually are parity, if that is the intent of the measurement. Thank you. MR. WELCH: Thank you, Charlotte. Next we will hear from John Lenahan from Ameritech. MR. LENAHAN: Thank you, Richard. Continuing with the baseball analogy, I feel like this is a double header for me. With respect to Charlotte's comments, I agree that it is nowhere near the end of the season, but I think we are well beyond the first game in terms of the implementation of OSS. I would like to address basically the three questions that the FCC laid out: What functionality is needed to permit successful ordering and provisioning, what level is flowthrough all about, and then what performance measures are needed to determine whether or not you have parity. In terms of functionality, I think at the most basic level, the system needs to be designed and signed so that it can accept a projected mix of orders, resale and unbundled network elements, and then within the orders how many are assume as is, how many are assume as specified, how many are brand new, how many are disconnect and those kinds of things. We have in sizing our interface gone through and tried to project what is a logical mix of orders and what is the relationship between services that are provisions using network elements and what is the mix of resale. That is all important to, from the point of view I like, being capable of providing OSS functionality to order. In terms of the functionality for provisioning, I think Charlotte mentioned all of them, and I will not repeat them. We agree essentially. In the EDI world, there is an order acknowledge, then there is an order commitment if there is a change in status, and then there is an order completion. Our EDI interface provides all of them. I think the most contentious issue, though, is flowthrough. Following up on what Stuart said a little bit, when you talk about flowthrough you need to distinguish between flowthrough for the EDI interface and flowthrough in the OSS Legacy systems. The EDI interface is simply a prearranged way of exchanging data in an agreed format, which facilitates the receipt electronically of a third party's order and gets it into another carrier's or our Legacy system's back end. That is the interface flowthrough. Once it gets into the Legacy system, at least in Ameritech, and I assume most other Bell companies, the Legacy systems were designed in a time where the identity of the carrier was irrelevant, and so once it is in the Legacy system the flowthrough through the Legacy system is identical to between the wholesale and the retail orders that go through. I think the focus should be on what is the interface flowthrough because that is the only thing that is different in the new world. The interface flowthrough within Ameritech is from January to May we have processed, and this is EDI resale, about 20,000 orders. Of those, nine percent approximately have been electronically rejected. Ninety-one percent have been processed we would say as planned. Of those, about just a little better than 50 percent were processed electronically without any manual intervention, and the other percentage required some manual intervention. Now, manual intervention to a large extent I believe is becoming the major red herring of this debate because manual intervention is caused essentially by one of two things; either the order as received is incomplete, or it is complex. In the first case, the ILEC has a decision. Do I reject the order because no one wants an incomplete order or incorrect order flowing through the system because it ultimately will cause problems and affect the customer satisfaction. The decision is if it is a minor edit, change it as opposed to rejecting the order. Many of our manual interventions are simply putting a period in or the street address was W-E-S-T on the order, and on the service record it is W period. We change those types of things. The other reason for manual intervention is the order is complex. We have not mechanized that in our back end systems -- Centrex orders, orders that require facilities, orders that have the Remarks field filled in. By definition, the design is that some person needs to take a look at it and see what does that say and why was the Remarks field filled in. Last, the EDI reject is similar. There are basically two reasons for a reject; either the EDI syntax is wrong, i.e., the format was not followed and so the back end cannot accept it because it does not understand what this order is all about, or the order has an incorrect USOC or some other information that is incorrect, and the system cannot process it. Last, and I know my time is up, in terms of performance, I think performance reporting is integral to any of these interfaces, and the performance reports that are relevant to ordering are the Fox, the 865s, the order completions, and probably most relevant is do the orders get installed on time. MR. WELCH: Thank you, John. Elizabeth Ham from Southwestern Bell. MS. HAM: Thank you, Richard. I guess to follow also the baseball analogy -- I do not want to be the one that is left out -- I certainly hope that Southwestern Bell has hit a grand slam with the operational support systems that were are offering. We think we have, and we hope those that signed up to use them will agree. We believe that we have provided a meaningful opportunity for the CLECs to compete by providing the multiple interfaces that we are offering. We also offer a 90 day free trial to test the interfaces, a 90 day free trial in a live mode to train the service reps with the CLEC to use the systems. We also have support organizations that are specifically designed to help the CLECs. We have an OSS help desk that is manned 24 hours, seven days a week, to help with any interface problems that the CLEC has. We also have the local service provider service center, which is our pre-order and ordering manual center, and we have the local service provider center, which is our provisioning and repair and maintenance group. We have delivered on our promise to provide nondiscriminatory access to all CLECs. We have 23 signed agreements with CLECs to use our OSSs. Eight of them have committed to implementation, and seven of them are using our proprietary interface. Yesterday one of the panelists indicated that one size does not fit all. We agree 100 percent. We provide both proprietary interfaces that have been developed by Southwestern Bell so that CLECs may use them immediately, and we also provide an application to application interface based on the available industry guidelines so a CLEC can in fact build their own custom user software. We have available EASE, which is our Easy Access Sales Environment. It is exactly the same system that our retail centers use. We provide an EDI Gateway. We also provide a new system called LEX, which is LSR Exchange System. All of these, we believe, meet the FCC's requirements for equivalent access. EASE, as I said, is used by our retail operation. We have over 5,000 consumer residential service reps that use it every single day. Business EASE is our proprietary business interface system. We have over 1,200 service reps using that. The CLECs who are using EASE have exactly the same access to pre-ordering and ordering capabilities that our retail operation has. We will support in the business EASE environment up to 30 business lines and in the residential environmental up to five residential lines in one order. EASE also presents the information in both English and in USOC, so they are both there. The translation is done for the service representative. In addition, with the EASE application there is no need for a CLEC to re-enter into their system, into their customer care system, the billing and customer information. We will provide daily a tape of all the pending and completed service order activity to each CLEC so they can feed that into their system, and they do not have to do dual entry. LEX is a new system that we developed. It is Windows based. It is a GUI that provides the OBF/LSR standards, and it is used by CLECs that either do not have the IS capability or they are not interested in providing or doing the work for an EDI Gateway. The CLECs can submit both resale and UNE orders into LEX. The LEX GUI uses the LSR standard formats. The use of the LSR standard formats then provides the same standards that are developed for all ILECs to be used with the mechanized system into the Southwestern Bell interfaces. LEX will be available for testing. We have two CLECs who will test it in June, and it will be updated as any OBF standards have been issued and finalized. Of course, EDI is the application to application interface based on the OBF standards. It provides both capabilities for resale and UNE. I believe that EDI is an example of the work that Southwestern Bell is doing in advance of industry standards, just as the ATIS committee recommended yesterday. EDI does meet all of our negotiated agreements. It provides functionality in advance of finalized standards, and we are conforming to the guidelines to merge all of the EDI standards that have been provided by OBF. We started testing ED with a large CLEC, and we hope to have good results on the transactions that are being provided by the CLEC over the Gateway. We also support the submission of manual orders. We will also submit the submission of manual orders into our LSP service center who do not want for whatever reason to utilize an electronic interface. For order status, we provide a GUI located on our tool bar that provides real time access to pending and posted service orders for individual CLECs. I have ten seconds. I better hurry up. We do not believe that any kind of particular level of flowthrough is required to meet the requirement for nondiscriminatory access. The test is really whether, as has been mentioned, the CLEC can order the service that is provisioned at parity with the ILEC. Our consumer EASE product permits a 99 percent flowthrough of all service orders that are entered by our residential or consumer retail operations. We would expect the same flowthrough from a trained CLEC service rep. In addition, on our EDI flowthrough we support residential and basic business resale, conversion with change, conversion as is, a disconnect, suspend, restore and semi-public. We will have enhancements to EDI available in June for a new connect, a change order and a records order. We have, and I guess I will talk a little bit about performance measurements. We have negotiated measurements for installation, repair, ordering and provisioning. We also have liquidated damages. Southwestern Bell will provide any parity measurement that we currently measure for ourselves for resale services. In addition to that, we will negotiate any other performance measurements on unbundled network elements that the CLEC wishes to negotiate. We believe they are free to negotiate any kind of additional measurements, and if they are willing to pay for them we will put them in. In no event do we believe that performance standards should be imposed upon a CLEC or an ILEC. They should be required. In fact, the CLEC should be required, if we do have imposed measurements, to provide accurate and detailed forecasts of their volumes. We will, as we have been, continue to negotiate in good faith. We will work individually with CLECs and the industry to provide the interfaces and to provide the functionality that they require for their business. Thank you. MR. WELCH: Thank you, Elizabeth. Wayne Fonteix from AT&T. MR. FONTEIX: Good morning, and thank you for the opportunity to be here today to discuss these issues. Unlike the three previous panelists, I will not begin with a baseball analogy. I will save that for my closing. Yesterday's discussions and the earlier discussions this morning have made it clear that new entrants are completely dependent upon the incumbents for their operation support systems for ordering and provisioning of both total services, resale and unbundled elements, including the combinations and the combination known as the platform. Yesterday's panel also highlighted the fact that the Commission's decision and its Order to require parity of those interfaces was absolutely the right thing to do. Just about all parties seemed to agree on this parity standard. Nowhere is parity more important than in the ordering and provisioning fields. Let's talk about parity for a short time. I ask you to consider parity from three perspectives. First, the assessment of parity. Parity cannot be determined without hard data about how the incumbent provides services and functionalities to itself and its customers vis-a-vis that which it provides to competing LECs. This is the issue around performance benchmarks and reporting. Second, we all agree that the systems that the CLECs and the ILECs use to provide these OSS capabilities are sophisticated, and they cannot be integrated effectively without the full cooperation between two parties. Third, given the way we know the ILECs operate today, parity simply cannot be achieved without the automated flowthrough of ordering and provisioning of information. Let's consider these issues in reverse order. Katheryn Brown yesterday encouraged the industry to develop performance standards based on what the customer wants. AT&T could not agree more strongly. We believe we know what the customer wants. Of course, each company in this room today believes the same thing. In fact, I am sure each company believes they know it better than anybody else in the room, and that is what competition is all about. We all agree, though, that at a minimum the new entrants will need to be able to provide at least the same level of service to those customers, or we will not be able to win and retain those customers. This is where we come to a minimum parity standard for all competitors. It is not possible without the flowthrough of orders similar to the way the incumbents flowthrough their orders in their systems today downstream. How do we achieve this seamless operation of systems? As these systems are integrated, it is essential that the ILECs work cooperatively with the CLECs and that no ILEC be allowed to unilaterally impose the standards for the interfaces nor the standards for the performance. Standards in software are only part of the story. We also need to understand the significance of the business rules, the development and implementation of the business rules, so that we know when we pass an order and we can build into our systems and the systems that support it on the ILEC side of the interface that if in fact the appropriate abbreviation of West Avenue is not W period but the full spelling of W-E-S-T that that order hits an edit before it ever goes through into the incumbent's systems. We need to have that information up front. It needs to be on a parity basis in the edit similar to what the incumbent has in its own systems. Cooperation is necessary in the context of both resale and unbundled elements, and at this point in the game we do not yet have developed agreed upon business rules nor processes for the ordering and provisioning on an automated basis of the combined unbundled network elements. As a result, electronic ordering of a platform is simply not yet available. The ILECs alone will control the degree of difficulty that will be involved in taking the existing resale interface systems, enhancing them to support the unbundled elements and the unbundled elements in combination. Finally, how do we know when we have achieved parity? The issue of measurements. Parity relies on hard data, hard and stable data; not assertions by one party, responses on the part of another, but established performance measures with established performance targets that are stable. The baseline in all cases is what the ILEC provides for itself, either in services or in comparable services where elements can find an analogous representation in services that are offered on a retail basis. The local competition user's group has in fact proposed a limited set, in the neighborhood of 24 measures, that can be applied across resale and unbundled network elements that we believe establishes a benchmark for parity. The stability is an important issue, and let me give you an example of what I mean by the performance measures cannot be fungible. Ameritech has stated, and we agree, that they have instituted some measures for performance. However, those measures, in our assessment, do not capture parity and are not stable. For example, over the course of April, of the orders that AT&T submitted to Ameritech for services resale that were submitted within the established standard interval for due dates, 15 percent of those orders Ameritech unilaterally changed the due date. This is not a stable measure. Let me close with the analogy as proposed on baseball. We know in baseball between first base and second base is exactly 90 feet. It is 90 feet for the home team, and it is 90 feet for the visitors. The base runner knows if he does not get there before the ball, he will be tagged out. The umpire will call that play. The 90 feet does not change. If we do not have established and stable parameters for the benchmarks, think of a baseball game in which the home team can be running to second base, see the throw is going to beat them, and suddenly move the bag up to 75 feet, slide in and call themselves safe. We need the FCC to set those bases at 90 feet. Thank you. MR. WELCH: Thank you, Wayne. I am not exactly sure what I started here. Pat Socci, do you want to try a crack at this baseball stuff? MR. SOCCI: Well, I am from New York, so until the Yankees get hot you will not hear any baseball analogies from me, nor football, nor hockey, nor basketball. I am on the defensive this morning, Richard. Good morning. My name is Patrick Socci, vice-president of MIS for Teleport Communications Group, TCG. We are the largest and the most experienced CLEC in the United States. I am very pleased to be here today to speak to you about the roles that OSS can play in ordering and provisioning of unbundled loops. As a facilities based CLEC with its own OSS, TCG's interests in the OSS of the ILECs is perhaps different from others represented here. We see the ILEC OSS as simply a means by which the ILEC will meet its statutory obligations to provide interconnection and unbundled network elements to CLECs with the same level of quality and service that it provides to itself. We call this the performance parity principle, and it is fundamental to the development of local competition. TCG already has its own OSS infrastructure. We have our own customer service representatives, our own network management centers, our own repair technicians and our own billing systems, so we neither want nor need unbundled OSS from the ILEC. On occasion, however, we may choose to purchase an unbundled loop from the ILEC, and we fully expect that the ILEC will process our order in a manner that represents the quality that is at least equal to that which the incumbent provides to itself. Currently unbundled loops are primarily ordered and provisioned manually via fax machines and telephone conversations. When submitted an order, TCG generally must submit the order via facsimile. However, TCG can never be certain that the correct person received the order, that the transmission went through clearly, or even if the fax was ever delivered. Even if such an order were correctly delivered, the ILEC recipient must re-key the information in their own OSS. Such a manual process with multiple failure points cannot be relied upon. The current provisioning processes are also ineffective at delivering equal quality service from the ILECs. Instead of being able to check electronically on the status of installation and testing dates and testing results and capacity measurements, CLECs must telephone the ILEC and request the information verbally. Typically this could involve being put on hold and transferred several times until finally reaching someone who could answer the question. Again, manual processes are simply not up to the task. If an ILEC could install our loops as quickly as it installs its own loops when we order via facsimile, so be it. If an ILEC could give us an installation status or an outage status information orally as quickly as it provides its own folks with the same information electronically, so be it. TCG believes, however, that as order volumes increase, the ILEC's performance will only worsen. TCG believes that the ILECs will not be able to deliver equal quality without electronic bonding of the ILEC's OSS with the CLEC's OSS, and you can be certain the TCG will be diligent in making sure that the ILECs meet their performance parity obligation. In short, the performance parity principle demands, by whatever means, the ILEC must provide interconnection and unbundled elements in a manner that is at least equal in quality to that which the ILEC provides to itself. Parity must be provided for all stages of the interconnection and unbundled element delivery process, including ordering, provisioning, maintenance and repair. It has been TCG's experience that the current processes do not provide such parity and that equal and nondiscriminatory interconnection and unbundled element access is only likely to be achieved through electronic bonding through CLEC and ILEC OSS systems. Finally, it is important and indeed essential to recognize that the industry cannot simply say that the ILECs must deliver OSS bonding and once it is operational then all is well and the job is done. Effectively OSS processes are necessary for a variety of other essential network relationships to function effectively and fairly. Electronic bonding of OSS systems means simply that the information can flow promptly and accurately between the CLECs and the ILECs. If the ILECs are delayed or inept in installing, maintaining or repairing unbundled elements, then the prospects for a robust and fair competitive market will be diminished. Thank you. MR. WELCH: Thank you, Pat. In addition to all the carriers on the panel, we are fortunate to have a representative from a vendor today, Venkates Swaminathan. MR. SWAMINATHAN: Thanks, Richard. Being from where I am, I have to avoid the baseball analogies because I do not know baseball well enough, so I am going to keep away from it. Thanks for inviting us to be part of this panel. What I will be talking about here in this statement is basically Telesphere Solution's point of view on some of these issues that have been raised here regarding operations support systems and their interconnection with a specific focus on ordering and provisioning issues. Basically Telesphere's point of view on this issue starts from the premise that OSS interconnection is a matter for software to handle as far as possible and humans to be involved in as little as possible. We call these systems OSS interconnection systems. At the platform level, Telesphere believes that ILEC and CLEC OSS interconnection systems should have certain critical features that will make OSS interconnection initiative successful. These features are technological fundamentals, we believe, to insure smooth, automated exchange of information between ILECs and CLECs. They include six features. The first and most important is scaleability. Scaleability is important so that as competition grows and order volumes increase, OSS interconnection systems are able to grow with them. The second feature is transaction integrity. OSS interconnection systems must be able to insure especially for ordering and provisioning transactions that a transaction is either completed or entirely rolled back. Third is integrated reporting. OSS interconnection systems must be able to produce reports indicating, for example, which orders were processed, why an order was rejected, what the average and maximum order processing times were by trading partner and order complexity, and what the availability of the OSS interconnection system was over a period of time. Fourth is availability. OSS interconnection systems must be highly available to allow high levels of customer service. Fifth is automated connections to internal ILEC and CLEC processes. We believe that this is very crucial to provide the kind of performance that is needed to create high service levels high enough for competition to be viable. This is important, we believe, both on the ILEC end and the CLEC end. The connection to the internal operations of both systems must be automated as far as possible and involve human intervention as little as possible. Sixth is support for multiple interface standards. The industry is using a variety of different interfaces right now, both in terms of data formats, as well as transport and in terms of application definitions. For example, there is electronic data interchange, there is the Web, there is ECLite, and they are all in use today for ordering and provisioning. Carriers need to be able to support multiple interface types on the same interconnection platform. Specifically for resale and unbundled network elements, standards are being defined today by industry bodies like the ordering and billing forum and the telecommunications industry forum. We believe that use of such standards is critical in providing CLECs with a cost effective and manageable way to offer local service and in providing ILECs with clear guidelines on what they need to do. Finally, I would like to make a point about independent software vendors like us. We believe that independent software vendors like Telesphere Solutions have a major role to play in this process. Products such as PowerGate, our run time and development environment for OSS interconnection systems, are being used by a number of ILECs and CLECs to improve service levels and time to market. In general, by leveraging infrastructure products focused on electronic communications for telecommunication service providers, vendors can substantially lower the cost of deploying OSS interconnection systems for both ILECs and CLECs and consequently create higher levels of automation and service. Thanks. MR. WELCH: Thank you. Now we will turn to the next phase of the program, which is presenting the panelists with some questions. Hopefully we will get some back and forth among the panelists. Stuart, let's start off with you. What types of electronic interfaces do you think meet the legal standards of Section 251 and the Commission's rules? Do these interfaces provide machine to machine interconnection such as flowthrough? Based on your experience so far, what is your evaluation of the various methods of access of interfaces either in use now or proposed for ordering and provisioning activities in terms of their ability to provide nondiscriminatory access? I can repeat some of those as we go along, if you would like. MR. KUPINSKY: I just want to remind everyone of the caveat I started out with. MR. WELCH: Which was that? MR. KUPINSKY: These are my comments and not the Department's. I think you can start out as far as Section 251 is concerned with the two standards that the Commission articulated, and that is the nondiscriminatory access standard and the meaningful opportunity to compete standard. If you apply those standards as you go through and consider the interfaces, you come out with different outcomes depending on which interfaces you are talking about and which CLECs you are talking about. For example, a terminal emulation interface might be appropriate for smaller carriers. That type of interface, though it does not allow you to electronically transfer information from your OSSs to the interface or vice versa, may still be appropriate for a small carrier that does not have its own OSSs. This may provide nondiscriminatory access and a meaningful opportunity to compete. I guess with regard to larger carriers who have their own OSS systems, this same sort of terminal emulation or GUI interface, that type of interface, may be inappropriate because they are not able to populate their own databases at the same time as placing orders as the incumbent can. For larger carriers, I think the proper way to interpret Section 251 and the Commission's rules is to require the more robust application to application interfaces such as EDI. We heard an excellent discussion of why the standardization of those interfaces is so important. For larger carriers, I think an application to application interface is the proper interface under the Commission's rules. As far as the legal interpretation is concerned, I wholeheartedly agree with Liz that a combination of these interfaces is probably the way to satisfy one's obligations because if you have a combination of the terminal emulation or GUI interfaces and standardized application to application interface, you have sort of covered all your bases. As far as the experience to date, I think what we have seen in the industry and what I have seen is that the introduction of manual processing in its various forms at any stage of the ordering process introduces significant problems. There is the potential for significant errors and delays in processing orders and provisioning resale services and unbundled network elements. I think I would disagree with the panelists that suggested that the flowthrough is only important with regard to the interface. As I said in my opening comments, I think you have to look at both pieces of this puzzle. We have seen some very specific experience in the industry that manual intervention on the back end after the interface has done its job and delivered orders can have cataclysmic results on the efficient delivery of resale services and unbundled elements. If there is any manual intervention between a CLEC's OSSs and the incumbent's OSSs, you have the potential for introducing errors and delays. MR. WELCH: Thanks. Would any of the other panelists like to respond to that? MS. HAM: I would. MR. WELCH: Elizabeth? MS. HAM: Thank you. As I said in my opening statement, we believe that we have met the requirement. We also agree with Stuart. We do not want manual processes in Southwestern Bell. They are expensive on the human size, and we agree that any type of fallout may delay the process. We also are working diligently to flowthrough as much of the EDI application to application transactions and capabilities as possible. What we have done is to focus on the high volumes. There will be some manual fallout and some manual handling on unbundled network elements because that does not, at least in our market, seem to be where the high volume is currently. The high volume is in resale, whether you are using an EDI Gateway or whether you are using our proprietary interface. There are certain orders that we do not process for ourselves in a mechanized environment. They are manual. When we do develop a mechanized process for any of those order types for our own retail operations, we will pass along the same capabilities to the CLECs who are using our proprietary interfaces. MR. WELCH: I am going to turn to Kalpak Gude to ask the next question, please. MR. GUDE: This is directed initially at least at Charlotte. Please discuss how your state has addressed the pricing issues for OSS access for various resold services and network elements. Are costs of OSS included within the charges for those services and elements, or have you approved separate charges for electronic interfaces and OSS access? MS. TERKEURST: Luckily Kalpak had told me he was going to ask me this question, so I worked with my staff over the last day or two trying to come up with the best answer to that that we could. There are a lot of different ways in which the costs of OSS are being handled in Illinois. We did have a completed docket on pricing of resale services, and the pricing has been established for them. Basically the costs of OSS were considered in establishing the net cost in the resale formula, so it was factored into the existing rate structure of wholesale services. There is a service ordering charge. It is different than the service ordering charge for a retail service, and part of the difference reflects the cost of the OSS. That is my understanding of how that works. MR. LENAHAN: Can I clarify? MS. TERKEURST: Yes. MR. LENAHAN: Again just to divide the OSS into two pieces, the interface cost is the cost that was included in the wholesale rate. The computer cost of maintaining the Legacy systems is the cost of running the business and would be recovered in the retail rates generally. It is the unique cost of implementing an EDI Gateway, etc., etc., but that is a small portion of the cost of maintaining the electronic Legacy systems. MS. TERKEURST: So the formula starts with the retail rates, subtracts out the costs that are saved as a result of it being a wholesale service offering, and then adds back in the additional costs that are created by the OSS and other costs of operating in the wholesale environment. On the unbundled network elements side, we established interim rates in the arbitration dockets and are in the process now of litigating a case that will establish permanent rates for Ameritech. How you handle OSS costs is an issue in that case. Ameritech is proposing prices for service ordering and other rate elements that are based on their view of the cost of providing OSS. Other parties are arguing that the costs that Ameritech are proposing are too high. For example, Ameritech's costs are based on the ASR interface that requires manual intervention. The parties are arguing that the service ordering costs should be based on an EDI type interface that would, in their view, have much lower costs than the ASR interface. That is it in a nutshell. It is still pending. MR. WELCH: Pat or Wayne, would you like to comment on the pricing at all? Do you have any thoughts? MR. FONTEIX: I am not personally familiar with the litigated case that Charlotte just referenced, but I did want to make clear that AT&T's position is where there are costs incurred in transacting business, obviously in a typical commercial relationship that cost is recovered in the supplier charges to the customer. Where we disagree is in the notion that all the costs required or incurred in establishing the interfaces to support competition are borne by the competitors alone. MR. WELCH: Pat? MR. SOCCI: TCG changed the focus a little bit. We are more concerned with the overall process. You can have an EDI interface, but what happens beyond that? The net result, we believe, is you monitor from beginning to end what is the on time performance. For example, last week on time performance with the ILECs was 35 percent for circuit turn up and testing, whereas by our own standards it is at least 95 percent. Anything below 95 percent, you have a lot of explaining to do internally. Our focus is not just the EDI interface, but rather what is the performance of the overall process. Are the circuits turned up on time? Are the circuits provisioned properly? Do they work the first time? Do they work right the first time, or is there a lot of rework? EDI and interfaces and GUIs, and I love the technology because I am a technologist, but the net result is I do not think we should fall in love with the technology, but look at the overall process and what is the performance because that is what ultimately determines whether we have effective local competition or not. MR. WELCH: Charlotte? MS. TERKEURST: There is one more thing that I forgot to mention that is a big component in determining how these costs should be assessed is the anticipated demand over which you spread the start up costs. The numbers in the pending case can range. The end result can vary by a factor of ten just based on what kind of demand assumptions you are using. MR. WELCH: Wayne, if I could ask you to address this question, please? At AT&T, what interfaces have you tested or used? Which specific interfaces seem most satisfactory? Which are the least satisfactory? If you could, please describe the problems associated with the interfaces. MR. FONTEIX: We are in the process of testing several interfaces around the country. As you know, we are in the market in California. We are in the market in Illinois and Michigan. We are in the market in Connecticut. We are in the process of testing interfaces with pretty much all of the other incumbent RBOCs with the exception generally of U.S. West right now. We have recently begun EDI testing with some Western Bell. We are pursuing, as has been stated before, some testing of interfaces at a very initial stage for the unbundled platform with Ameritech. The bottom line here is on the EDI interfaces, which clearly is AT&T's interface of choice as a large volume carrier, these interfaces and where they are being implemented today, and they are at the very early stages of implementation, are just in the initial stages of testing in limited cases. We have still ongoing discussions to try to close on the business rules I referred to. We understand the pipe. We understand the interface on the pipe. We need to have the business rules on either end of that pipe established so that we do not pass orders that get rejected because we do not have comparable edits on our end of the interface to what the incumbent has. There is a lot of work to be done on that as well. It is not simply the interface, but the rules surrounding it. Stuart is absolutely right in regard to the large carriers and the use of the proprietary interfaces or the Web/GUI interfaces. It puts us in the position of having to do double entry into our systems, as well as directly into the Legacy systems or into the Web/GUI interface. Literally at any kind of volume, that is not efficient. Unquestionably, EDI is our interface of choice, and we are in the very early stages of testing that. MR. WELCH: Does anyone have anything to add to that? Elizabeth? MS. HAM: Yes, just one thing. AT&T is also testing in our market our proprietary interface for residential resale services. That testing began this month. From what I am hearing from both the AT&T operations side and our operations people is that the test is going very well. As to any kind of implementation, there are start up issues that you have with any issue, but we feel that we have a good test going. I think it is to the credit of AT&T that they have done sufficient training on our proprietary interface prior to beginning the trial and using the system. MR. FONTEIX: Could I just add one point? We are absolutely pursuing a test to implement the consumer areas with Southwestern Bell, which may seem to be in conflict with our standard objective of moving to EDI interface. This is an issue of timing. We have a very, very strong parity to get into the market yesterday. The EDI interfaces are not ready to support that market entry today. We need to take what is available on that basis such as the proprietary basis to accomplish market entry today with the stated need to move to a parity basis on EDI. MR. LENAHAN: I would like to add one thing and encourage AT&T in those markets where it is entered in Illinois and Michigan. I think they are beyond testing, and they are into commercial sales. If they would accelerate their testing and use some pre-ordering, the quality of the orders they are able to submit would improve dramatically. We would encourage AT&T to start using the pre-ordering interfaces that are in place. MR. WELCH: Pat? MR. SOCCI: Yes, Richard. Just a little back drop. We do a reasonable amount of business with the interexchange carriers. We are the vendor. They are the customer. We provide the local loop. We have built interfaces to all the interexchange carriers. Since we are the vendor and they are the customer, obviously we have to meet their needs. It is American capitalism at its finest. We find now where we are interacting with the ILECs, they are the vendor, and we are the customer, but yet we have to adhere to their requirements. The paradigm has broken down. The net result is we are playing around with various ILECs, with dialogue interfaces, Internet access interfaces. They are all very costly, not so much from the interface aspect, but the additional human resource because now they have essentially broken every single process that we have in our company for ordering, provisioning, maintenance and repair. We now have to have a special group of people to deal with these special interfaces. They vary from ILEC to ILEC to ILEC. In essence, they have broken all of our processes, and it is very expensive. I agree with AT&T. EDI is really the way to go, but our position is we look at the overall process. Whatever will give us effective competition in the local markets at least cost, that is what we will be happy to do. MR. WELCH: Venkates, if I could ask you to look into the future and do a little predicting here? What can we expect incumbents to do in the near term, for example, the next six months, to obtain ordering and provisioning? Are the methods of access available today likely to be long term solutions to the telecommunications industry needs as it moves to a more competitive environment? What trends or innovations can you predict as likely or desirable for the industry over the upcoming years? MR. SWAMINATHAN: Good question. Several points about that. First of all, before I get to the specifics of the question, I just want to say one other thing. There is a common assumption made that if an ILEC provides a GUI for a CLEC to access that this is a fine method of access for the smaller CLECs and that the only people who have a problem with it are the much larger CLECs. I am not sure that is entirely true. I think it is true for smaller CLECs only if the smaller CLECs are very geographically focused in the sense that the offer service only maybe in one state or two states or within a single ILEC's territory. I think there will be in the very near future a lot of very small CLECs that are nationally focused nevertheless and address their market to maybe specific groups of people, but they are not localized groups of people. You can imagine it would be very hard for a small CLEC like this to have eight or 11 different GUIs sitting on somebody's terminal and trying to understand the differences in the ordering and pre-ordering interfaces to each one of those ILECs. To move on and specifically answer your question, I think in the next six months I think what the industry will see is a continuing evolution. I think the standards are still in their infancy right now. There are the EDI based standards, the TCIF, Issue 7. They still only address a very small subset of services, which is relatively simple resold services and unbundled loops and stuff like that, but not a lot of other services like Centrex. For CLECs who are trying to enter the market, there is still a great deal of need for manual intervention, so what I would expect to see in the next six months is an evolutionary process where there is a process by which these systems slowly get more automated. By automated, I mean end to end automation, automation both at the CLEC end, as well as the ILEC end. It is equally important for the automation to take place within the CLEC systems as well because the overall process, as Pat pointed out, is what is really important. Manual intervention, significant manual intervention if it is needed, at the CLEC end also slows down the overall process. In the next six months, I would suggest that there will be more of an industry move towards standards such as the TCIF standards and Issue 7, Issue 7.1 and so on. Beyond that, for the long term I think there are several things that we can and should expect. One is I think that independent software vendors will start to play a much more significant role in providing the software both on the ILEC and the CLEC end for this kind of interconnection to take place simply because the costs of each ILEC and each CLEC developing completely custom, individualized software are too great. What we will see are basically the standards being used to allow IFBs to develop software that is based on the standards and allows CLECs and ILECs to connect their systems more transparently perhaps over the Internet and perhaps, you know, with greater degrees of functionality than we have today. MR. WELCH: Thank you. Does anybody else want to take a crack at predicting trends or innovations in the future? Charlotte? MS. TERKEURST: I wanted to raise an issue. It is more something that I have been wondering about, and perhaps he can answer this. Even within the standards, there would still be room for proprietary applications of those standards, from things that I have heard. The standards just set out general guidelines, but not necessarily how you apply them. Is work being done on trying to open up the process and making it non-proprietary so that software could actually work from one carrier to another? That is a trend that is needed, whether it is in the works or not, it seems to me. MR. SWAMINATHAN: Like I said, there is an evolutionary process with respect to the standards. The standards as they are right now do leave a lot of room for interpretation, do leave a lot of areas unaddressed and are still evolving perhaps to address those areas. Even in the end, there will still be some services that different ILECs offer that are not entirely captured by the standards. I do not think it is practical to imagine a world where every ILEC offers exactly the same services, and I do not think that is something really that is the goal of the whole process. What is really the goal is to create an environment where there is sufficient standards in place so that the differences are literally small by comparison to the similarities. Right now what we have is a situation where the differences are very big compared to the similarities so that there is essentially a need for a one on one connection between each CLEC and each ILEC. There is basically a different system in place for each CLEC and each ILEC, and this is a system that is very hard to maintain and support and very expensive. MR. WELCH: Stuart? MR. KUPINSKY: I think to put Pat's earlier comments in a different way, I think over the next six months we are also going to see an evolution of the debate itself. To date, we have been talking a lot about the specific technology, the specific interfaces, but we see the debate starting to evolve into questions of performance standards, performance measures and the results that CLECs are obtaining using these interfaces. I think because of the complexities of these systems that evolution will continue, and it will be eventually a very result oriented outlook seeing whether there is parity in the results of the use of these interfaces or resale services. MR. LENAHAN: I would like to second that. I think the trend is OSS is a means to an end. The end is efficient, error free implementation of an order, and it is very effective means to accomplish that. Once the means is in place, then the focus should rightfully shift to measuring the overall performance of the overall process of either ordering and provisioning service or repairing service or obtaining a customer service record. I see two key elements. One is standardizing the interface for OSS so that the means is easily accomplished, and then in the process hopefully of contract negotiations a more commercial means of establishing the level of service, agreed upon performance measures and agreed upon performance reporting procedures. MR. WELCH: That is actually a nice segu‚ into our next question, which Kalpak will ask. MR. GUDE: This is directed towards John and Elizabeth initially, and I would definitely like to have the CLEC representatives comment on this as well. What measuring system or reporting mechanisms have you implemented to insure that you are providing ordering and provisioning on a nondiscriminatory basis, as well as providing CLECs with a reasonable opportunity to compete? Do you measure or report on the availability of access used by your retail operations? MS. HAM: I will go first, if that is okay. We do report on the parity issue, the overall system access on our proprietary systems. We will provide that. It is the same system. If we have a slow response time or if we have a system down, right now it affects us more than it affects anybody. We will provide the overall availability of our systems. We also will provide a parity measurement on speed of answer into our LSP/SC, which is our pre-ordering and ordering center, our service center, that supports the CLEC in a manual mode, as compared to our retail operations' speed of answer. We do provide I guess what affects the end user the most, and ultimately that is was the service delivered when we promised it would be delivered or when the CLEC promised it would be delivered, and was it right. On any of the resale measurements that we collect, if they are provided internally or if they are provided to a PC, then we will provide a parity measurement to a CLEC who is doing resale business with us. If we do not have that measurement in place and we are asked to develop it through negotiations, and that is how we believe it should be done is through negotiations, then we will look at what are reasonable performance measurements, and we will negotiate providing those with a willingness to pay on whomever is asking. MR. GUDE: Just one follow up. Do you also provide a comparison between and amongst CLECs? MS. HAM: Yes, we do for unbundled network elements. That we do not provide ourselves, but we will provide that measurement. MR. LENAHAN: Ameritech basically provides the same type of let's call them bottom line results -- percent of firmware commitments provided within the contracted period of time, percent of due dates met within the contract period of time. More important, though, our EDI system, our pipe, if you will, measures all kinds of things like number of orders processed, number of orders processed electronically without any human intervention, number of orders that required human intervention, percent of availability of the system itself. What we have instituted recently is we have a daily internal review of all of the electronic orders, and a team was put together to examine what percentage of orders were rejected, what were the reasons for the rejects, and can we communicate back to the CLECs so that they can better understand either the EDI rules or the business rules that Wayne mentioned, and then with respect to the percentage of orders that required manual intervention why did we have to perform manual intervention and this same thing. It is clear to us, and I think most people on the panel would agree, that the more electronic flowthrough, the better. It is a learning process. It is complicated, and we are starting now to review actual results and share the results with the carriers that are using the interfaces. I would see that as a short term measurement activity. The long term should be basically confined to the due dates met and the intervals and those types of things the customer cares about. MR. WELCH: Does anyone else want to add anything to that? Wayne? MR. FONTEIX: We are in amazing agreement about the need for the performance measures and parity. Where we will continue the debate, as Stuart indicated, is how that gets measured and what those measures are. Today it is pretty obvious that the incumbents do not have an incentive to be forthcoming with the data on their own self-provisioning, especially to the extent that it would show some lack of parity. There needs to be a contract, as was discussed yesterday by several panelists. There is not the incentive to provide as on a commercial basis all that competitors need to determine parity, an incentive, in fact, for a period of time to keep that from seeing the light of day. The second issue that has to be debated here and resolved here is how it does get measured. Displaying the information? Providing it? In fact, some RBOCs have suggested that it needs to remain confidential. I am not sure what the regulators think, but that clearly is not going to work. How it is provided, what the measure is, if the performance measure is orders completed within six days and it is 95 percent for the incumbent and 95 percent for the CLEC, that maybe sounds like parity, but you need to understand is in fact the average order completion rate for the incumbent two days and the average order completion rate for the CLEC five days? They are both within six days, but it is not parity. We are going to have to get to the issues of hard data measurements. MR. WELCH: You mentioned that this is not going to be resolved through commercial negotiations. What, in your view, is it going to take to make that happen? MR. FONTEIX: I believe that is why we are here today to urge some action to establish those requirements. MS. HAM: Could I respond to that? MR. WELCH: Sure. MS. HAM: Our commitment at Southwestern Bell is to provide the same quality of service to the CLECs that we have provided to our community for years. To meet those parity requirements, we take it very seriously. I am charged in my company for insuring parity and insuring compliance. If there is the issue that Wayne has indicated, then we will investigate it. We will look at it down to a wire center level. We will look at it even beyond that if it is required. I still think, and it is my belief, that those types of things are negotiated one on one that we will provide to any regulatory body. We have expressed our desire to work with the regulatory bodies to develop meaningful performance measurements, and that is the way it should be done. MR. WELCH: Charlotte, and then Stuart. MS. TERKEURST: Just a couple of points. I tend to agree with some of the things that Wayne said about unfortunately this is not something that is open to particularly arbitration by state Commissions on a case by case basis. We have been encouraged when companies have come in and had some performance measures negotiated in their agreement, but when there has been disagreement that the parties have brought to the Commission for arbitration the Commission has been very reluctant to impose standards within an individual contract because there are obviously inefficiencies if there is one set of reporting requirements between Ameritech and AT&T and another set of reporting requirements between Ameritech and MCI. To the extent regulators need to get involved, it does need to be done on a broader basis than individual agreements. Wayne also raised a number of the problems with some of the current measurements that are coming before us. Unfortunately, so far Illinois has been looking at whether the measurements that are being reported are adequate. We have not really delved into what they should be. Obviously we need to look very carefully at whether they are measured when they are supposed to be measured, whether they are accurately reporting on parity or whether some of the details are getting buzzed over in the measurements that are coming in. MR. WELCH: Just to follow up on that, Charlotte, you may not be aware of this, but do you have any sense for what states in general may have been doing in this area? Do you know if other states have been looking at or developing performance or reporting requirements? MS. TERKEURST: I know some work has been done in that area. Whether they have actually gotten to the point of Commissions issuing Orders, I do not know. Wayne might know more about that since he operates in a multi-state area. MR. FONTEIX: Charlotte's experience in Illinois is pretty typical of the state experience. Where we were unable to reach agreement through the negotiation process on some performance standard measurements, we took it to arbitration. Typically the state Commission deferred for the very reasons Charlotte brought up. In several cases we did reach some initial closure on some performance measures that unfortunately were not detailed enough to preclude the types of confused issues I referenced earlier. We continue to go back and try to further negotiate those details so we can come to a meaningful measurement. We have not had, with the exception of one or two states, any decisions imposed through the arbitration process. Where that has happened, it has typically been a baseball type arbitration. MS. HAM: Baseball? MR. FONTEIX: There you go. It has been awhile since we have had an analogy to baseball. MS. HAM: Two of those states were within our five state region, and they were arbitrated. The two Commissions that ruled ruled that the quality of service measurements that we currently provide at least now are sufficient, but that does not, as we have said all along, close the door to future negotiations. MR. WELCH: Stuart? MR. KUPINSKY: I think it is important to point out where we are in the baseball game again. I think as more and more challenges to parity or a meaningful opportunity or the manner in which resale services and unbundled elements are provided come down the pipe, it is inevitable that a more comprehensive set of performance measures are going to have to be established. This is the only way of determining these parity issues. It is I think just a matter of time and not whether or not we will ever have these. MR. WELCH: Pat? MR. SOCCI: Wayne made a good point. We cannot just look at comparisons of the ILEC and CLEC intervals. That is not sufficient. I think we need to also look at the resale unit of the ILEC versus the main body of the ILEC as it serves its own customers. Also, remember that we are always talking about competition. There is a customer involved in competition, so I think we need to look at what our internal measurement is, customer concurred due date. What date does the customer want it? What date did the customer actually get it? That is the ultimate test, and I think that is the date we need to look at as to how the CLEC provides the service and the ILEC, not just intervals. How many times did we hit the target for the customer because the customer is part of the competition formula. MR. WELCH: On a somewhat related note, Pat, if I could follow up, when a competing carrier is taking elements from the incumbent, and, of course, obviously the incumbent does not provide elements to itself so you have a breakdown in this measurement of parity, what should be the proper basis of comparison for performance in that type of situation? Do you have any thoughts on that? MR. SOCCI: We are talking about ordering. Certainly, you know, when are the firm order commitments made? When are the products received? When are the circuits tested? Is there capacity available? If capacity is available, is it made available to the CLECs the same way it is made available to the ILEC for internal purposes? Those I think are the important things. We could talk about maintenance and repair, but that is for other discussions later today. It is the availability of those services for the CLEC as measured against its availability for the ILEC itself. MR. WELCH: John? MR. LENAHAN: In our case, in those situations where there is not a comparable to the retail side of the basis, for example, unbundled loops, each of our interconnection agreements has a specific performance interval; five days if it is more than ten loops, ten days if it is ten to 20 loops. Those vary depending on the CLEC, and typically there are liquidated damage provisions if that interval, that specific interval, is not met. In those cases where there is no retail comparable, I think it is important that the interconnection agreement define the expected performance target. MS. HAM: We are in the same situation with liquidated damages. MR. FONTEIX: I would like to just offer one other relevant comparison, and that is in the case of purchase of a combined loop and unbundled switch where there is no actual physical work involved in cross connecting or pulling apart elements that are already in combination. Clearly it is not a physical change. It is a software change, and I believe there are relevant comparisons within the existing retail operations. MR. WELCH: Well, one of the great things about baseball is that there is no clock. It is just whoever has the most runs at the end of the game. Unfortunately, we have a clock. The time on this panel has gone by very fast because I think it was terrific. We got a lot of interesting discussion back and forth. I would like to thank our panelists, Venkates Swaminathan, Pat Socci, Wayne Fonteix, Elizabeth Ham, John Lenahan, Charlotte TerKeurst and Stuart Kupinsky. Thank you very much. (Applause.) MR. WELCH: We will take a 15 minute break and start back up promptly at 11:45 a.m. (Whereupon, a short recess was taken.) // // // // // // // // // MR. WELCH: Let's go ahead and get started with our second panel today, which will focus on issues involving billing. We have four panelists here. Going from right to left, we have Beth Lawson from Southwestern Bell. Beth is area manager of finance operations. Sitting next to Beth is Mary Berube from Southern New England Telephone Company. She is senior project manager and network marketing and sales. Next to Mary is Robert Falcone with AT&T. He is district manager of new market development, and finally, on the far left, we have Dennis Perkins. Dennis is with Brooks Fiber. He is vice president and corporate controller. So, this panel will focus in on billing issues and we will proceed as we have before, with brief opening statements from the four panelists, so why don't we start with Beth, if we could, please? PANEL II MS. LAWSON: Good morning, I'm Beth Lawson from Southwestern Bell Telephone. Billing involves the exchange of information necessary for CLECs to bill their end users and also to process their end users claims and adjustments, and also to view Southwestern Bell's bills for services provided to the CLECs. Southwestern Bell provides multiple electronic options to receive billing data. We offer a product called Bill Plus, and this is essentially a paper bill, has all the information that will be contained on the paper bill, and you can receive it via three different mechanisms. You can get a PC diskette, or you can have it downloaded to your computer system via modem, or we're getting ready to offer a new option in June of '97, which would be via a CD-ROM. This will include auxiliary information also included on there. With this Bill Plus, the CLECs can search for information on their bill, they can generate, standardize or customize reports using any data that appears on the bill, and they also can print any portion of the bill. Currently, we have over 650 retail business customers receiving their bills via bill plus, and this equates to over 25,000 accounts. We also offer a EDI 811 864. This is an industry standard ANSI XR12 electronic interphase. This enables the CLECs to receive data in an electronic format, from Southwestern Bell's CRIS database with the same information that would appear on their monthly resale bill. This also enables the CLECs to manipulate billing data without rekeying the data. It also generates reports involving the billing data, and also allows you to track your intraLATA calls and export data to the CLECs internal computer systems. Currently, we have 35 retail business customers receiving their bills, and this equates to over 30,000 accounts. We also offer a Bill Data Tape, BDT. This is available today to CLECs to receive data in electronic format from Southwestern Bell's CABS database with the same information that would appear on their paper bill for their unbundled network elements. We also offer Customer Network Administration, CNA. This is available today for on line access to obtain the same billing information for both resale and unbundled network elements that would appear on the CLECs paper bills. We also have introduced the usage extract feed. This provides the CLECs with daily information on usage that will be subsequently billed on their monthly bill, in the industry standard EMR format. This was implemented in December, 1996. We've sent several test files successfully to CLECs and we have two CLECs that are currently live receiving the usage extract feeds today. CLECs will have to complete the coding, though, to receive this usage data into their billing system, so that they can, in turn, rate and bill their end user customers. Southwestern Bell meets the requirements of the 1996 Act and complies with the FCC's order in terms of providing CLECs with at least minimum equivalent electronic access to billing data that provides the same information that we provide to ourselves, our customers and carriers. Thank you. MS. BERUBE: Good morning. There are four major points I'd like to highlight regarding access to billing information. First, non-discriminatory access to information, rather than to systems, will best meet select needs. Second, a single standard for billing format and media will not meet today's requirements and capabilities of all CLECs and ILECs. Third, if a CLEC requested billing functionality exceeds that which the ILEC provides for itself or its end users, CLECs should assume costs of development and implementation of that functionality. Finally, the quality, accuracy and timeliness of end user billing is the responsibility of the CLEC. On the first point, non-discriminatory access to information rather than to the systems which store the information, will best meet CLEC needs. Over time, ILECs have developed large and complex systems to meet our customer and internal requirements. These systems collect, process, store, merge and distribute data to and from various other systems and process millions of transactions daily. It would be untimely, burdensome and expensive for even the largest and most sophisticated of carriers to directly access these billing systems, and for the smallest carriers, it would be impossible. It is the data within these systems that is critical to the CLECs, rather than direct access to the systems themselves. Basically, the major categories of data or information that the CLEC needs from the ILEC billing systems are billing detail for the services that the CLEC purchases from the ILEC, and, in a reseller environment, end user usage detail such as toll detail. Related to my second point, and, I think, a common theme in the discussions during the last few days, is that a single standard for the exchange of billing information will not meet the requirements and capabilities of all CLECs and ILECs. For example, only the largest CLECs operating in Connecticut can presently accommodate electronic transmission of billing information. The smaller CLECs continue to rely on traditional monthly paper bills. To mandate only an electronic standard discriminates against those CLECs who cannot at this time cost-justify or implement electronic capabilities. As another example, many CLECs today in Connecticut cannot support and have not requested daily usage feeds. While daily usage feeds may provide more timely data, some CLECs do not have the capability to accept and process this information. Out of the 19 certified CLECs in our territory, only two are currently using daily usage feeds. One was implemented approximately a year ago, and the other since the beginning of this year. Until the others have more fully defined the level of billing services they choose to provide their end users, this duality will continue to exist. To the third point, to meet the billing information needs of CLECs, an ILEC may be required to support new capabilities and functionalities which exceed what is currently available and provide it to itself and its end users. Costs will be incurred to meet these additional requirements. Consequently, CLECs must assume the costs to develop and implement these capabilities. This is also consistent with the FCC's definition of Unbundled Network Elements to include access to the OSS functions. Finally, the CLEC is responsible for the quality and accuracy of its end user billing. Since the CLEC has direct access to its customer information, with the possible exception of usage data, including the services which it orders for and provides to its end users, the CLEC has the best source of data for end user billing. The relationship for end user services exists between the CLEC and the customer, not between the customer and the ILEC. Thus, the CLECs should be accountable for the reconciliation of services provided to end users and not need to rely on the ILEC bill for that purpose. In closing and as discussed yesterday by the OBF representatives, much progress has been made and is being made in the industry to meet the billing needs and challenges of this new environment. As new competitive carriers gain experience providing local service, new billing requirements will be identified and appropriate cost recovery mechanisms will need to be established. In Connecticut, SNET and the CLECs are working hard to define and implement with state regulatory commission oversight, the best approaches to provide non- discriminatory access to billing functionality. This work is an ongoing process, which should and will evolve as market forces dictate. Thank you. MR. WELCH: Thank you, Mary. Next we'll hear from Robert Falcone of AT&T. Robert? MR. FALCONE: Thank you, Richard. Billing is the most common and often the only way that local companies have to interface with their end users. End users today are accustomed to getting accurate bills from their incumbent local telephone company and simply will not tolerate inaccurate bills from CLECs. Therefore, it is absolutely critical that the incumbent billing operation support systems support timely and accurate data to the new entrant for both resale services and unbundled elements, to allow the new entrant to bill their end users, IXCs for access and other local companies for reciprocal compensation. When a new entrant buys resale services, they need billing information from the incumbents' operational support systems, provided in electronic format, and meets three basic requirements. First, incumbents billing data must provide an accurate and complete record of the usage for the new, for the CLECs end users, both for their dialed usage and for any usage sensitive features that that CLEC customer may employ. Second, the incumbent must provide the usage data on a timely basis, based on agreed upon intervals, and third, the bill to the CLEC from the incumbent for the resale service, the discounted resale service, must be provided timely and accurately, both for the discounted service and for any appropriate non-recurring charges. When a new entrant is buying unbundled elements from the incumbent LEC, they also need accurate and timely information, as I mentioned above, with resold services. However, billing for unbundled elements provides new challenges for the incumbent LEC in their operation support systems. Not only do they have to provide all the data that was mentioned above, but they have to develop their operational support systems to allow them to bill for the unbundled elements that the CLEC is purchasing. This is particularly critical with elements such as the switch, which has both a flat rated component and a usage space component. These billing issues are further magnified, because a new entrant who buys unbundled switching not only needs the billing information I mentioned above from, with respect to resale, but they also need data to allow them to bill originating and terminating access to IXCs and the reciprocal compensation to the other LECs operating in the area. Although incumbents do not currently measure terminating access on a line by line basis, the data necessary to provide this information to CLECs is recorded in the switch and available. However, the incumbents' billing systems must be enhanced to allow them to cull out that information on a line by line basis, to provide the CLEC who is using an unbundled switch accurate access information, so that the CLEC can bill the IXCs the access that they're entitled to. In order not to preclude CLECs from purchasing unbundled switches until these billing enhancements come along, the CLECs must do two things to move the ball forward and allow us to buy unbundled switching and the platform, until this enhancement to their billing systems is done. First, the incumbents must develop terminating access factors. These factors are needed to allocate determining access coming into the unbundled switch to determine what of that terminating access or how much of that terminating access the CLECs that are using that switch are entitled to. I think it's important to note that there's a history in the industry of using terminating originating factors dating back to divesture, when pre-equal access, the local companies could not bill terminating access at all. The capability was not there. They derived the terminating access from the originating usage, based on T to O ratios, until such time as the switches were enhanced to measure that terminating usage. Secondly, the incumbents must provide new entrants with carrier specific access usage information in a timely manner, so not only do we know how many terminating access minutes are we entitled to, we would know which of the IXCs operating in that area to bill those access minutes to, we, the CLECs. Again, appropriate hour assessed enhancements must be made, both to provide the short term solutions to allow us to move forward with purchase of the unbundled switch and get all the data that we need, and enhancements must refer them to allow for the long term solution to actually cull out the line by line usage that is recorded in the switch and could be provided to the end user. Thank you very much. MR. WELCH: Thank you. Finally, we'll hear from Dennis Perkins from Brooks Fiber. Dennis? MR. PERKINS: The message I bring today is on the need for billing standards and interface standards. The telecommunication industry requires a significant amount of billing data to be passed between telephone companies. This data needs to be passed quickly and in a standard electronic format. As we work to establish our billing processes and the required data exchanges with the various RBOCs, it has highlighted the need for a fresh look at the current processes and standardization. Many standards do exist today, while many others need to be addressed. A standardization of interfaces needs to includes processes, data formats and required data elements that are necessary to insure accurate and timely billing information. As a new entrant in providing local exchange services, Brooks must set up interfaces with the RBOCs. Setting up the various required interfaces with one RBOC is difficult, and this is multiplied when dealing with multiple RBOCs. Brooks has had to work the same type issues with each RBOC on a one item at a time basis. In turn, this makes the process more costly, as well as time consuming. In addition, each new entrant is faced with conforming to the existing RBOC systems in each region. In working with each RBOC, we hear statements like, this is how we do it in our region. In setting up our operations, we are required to conform to the unique and different practices in each region. This places a burden on the new entrant to expend resources and conform to each region. Some of the interfaces have not been previously done, and many interfaces and processes are being developed as they are encountered. In the absence of standards, these processes take on an individual life of their own. I have several examples that illustrate billing interface differences that we have encountered. My purpose in reviewing these is to highlight the need for performance and interface standards. For instance, when it is necessary to exchange clearing house records with Southwestern Bell, we must exchange records in EMR format as category 92 records. With Bell South, we use a different EMR format. Another area that has different interface requirements is IntraLATA toll access. For example, in New Mexico and Arizona, we must set up an interface with the originating responsibility plan to receive compensation for IntraLATA toll access. Other areas do not have an ORP process, and require different interphases. The next example deals with local access record exchange. There are not standards in the industry for format, data substantiation requirements or billing formats. In working with each RBOC, we are establishing the process and reporting requirements to bill each other for local access. A lack of standardization will lead to many disputes in this area. In the area of carrier access billing, some of the general requirements are the same between RBOCs, but each has a separate and different process. Another interface is billing and information for unbundled network elements. There is a need for standardization and providing of electronic data. These invoices are sometimes created electronic format and sometimes paper format. In many cases, the RBOCs have not yet identified how the information will be made available, for billing of certain network elements and electronic bill providing in a CABs format and other bills are sent in a paper format. At U.S. West, they will supply a paper bill or an EDI version, but in a CRIS format. Like I said, others to be determined. The last example I want to mention has to do with an electronic data exchange request with Ameritech. For alternatively billed calls to reported numbers, Ameritech only supplies this information to Brooks on a paper bill. An electronic version of this information is not available. By only receiving the message detail on paper, Brooks does not have an electronic means to bill the end user. Without the electronic information, Brooks incurs expenses from Ameritech and sustains lost revenues from the lack of Brooks being able to bill these calls to its end user. In summary, these interfaces can be complex and they are made more complex by having multiple processes to accomplish the same task. The point that I want to make is that without performance and interface standardization, including processes, data formats, data requirements, an entry of competition will be slower and more expensive. Thanks. MR. WELCH: Thank you. Now we'll move to the question and answer session, and I'm going to turn to Kalpak Gude to take the lead in asking the questions. MR. GUDE: First, I want to direct the opening question to Beth. What processes are being or should be used to transmit billing information to competitors? I think you mentioned that briefly in your opening. Also, could you talk a little bit about whether these systems are fully tested and to some extent, how they were tested? MS. LAWSON: With regard to the billing information for resale, with our CRIS Resale 811, this has been in existence for a number of years, and we have live customers receiving over 30,000 accounts currently today. So, we are in a live mode with this. This was something that we used in our retail business operations and the type of billing information for resale is the same products and services that we would sell in our retail operations. So, as far as resale, that was already in existence. With regard to Unbundled Network Elements, that was introduced as a feature group, you and our CABS billing system, so we utilized a local CABS bill data tape, which is similar to what they do in the access world, except it would be an access bill data tape. So, it's the same type of electronic format with a current CABS version that's been implemented. With regard to Bill Plus, that is a PC diskette and that is a proprietary system that we actually customize programming ourselves, so that we can provide the data so you wouldn't have to do any programming yourself, and provide standardized reports, but you can also do ad hoc reports if you would like. With regard to the usage extract, which is the new area that's been added, that is in standard EMR industry format that's been agreed to by OBF. MR. WELCH: From Mary, could we hear the response to that? MS. BERUBE: Sure. Currently, we are providing on the resale side billing out of our CRIS system. For, as I mentioned earlier, for two of our customers, we're providing electronic via an NDM protocol, electronic transmission of billing detail data that more fully or finer point of granularity of the billing detail that's on the paper bill. For the remaining, it's paper bill. We are currently evaluating electronic means, however, we have not had specific requests from other CLECs at this point for electronic means, so our intention is to do our internal evaluation, and then propose to our CLECs some of the ideas that we've come up with. In terms of Unbundled Network Elements, it is our intention to provide those through CABS, so for those carriers with whom we have existing NDM transmissions for CABS billing data, that will continue. For others, we will need to have those discussions when they order those services from us on the transmission means that they intend to use. Daily usage feed is an NDM feed again in EMR standard format, for those customers who are presently availing themselves of that offering. MR. WELCH: Dennis earlier mentioned in his opening the problems with developing different systems to deal with different incumbents. As national standards are developed in the billing area, do you have plans to move towards the implementation of national standards? MS. BERUBE: I think it depends, in fact, what the national standards are and the services that are supported by those national standards. Certainly in the Unbundled Network Element area, those have been discussed at the OBF, data elements have been identified and the formats that are currently in place seem to fit those needs. In terms of resale, there is definitely a divergence of opinion by the industry where and how to best bill, out of what systems and how to best bill for those services. While, in the OBF, there are guidelines which have developed that identify the data elements, the systems that provide that information have been in question and we will continue to evaluate, based on our capability and our assessment of our customers' needs, the appropriate systems from which to bill those services. MS. LAWSON: Can I -- oh, what I was going to say was respond as far as with resale, the EDI that's being proposed in the ordering world as an industry standard, the 811 transactions that have been out there, it's been utilized, it is an industry standard. So, from Southwestern Bell's perspective, there is a standard that is available and can be utilized by any ILEC that -- and a lot of them do go ahead and offer CRIS resale to their business customers, and they can make that option available, as well, to the CLECs. That way, the CLECs would be able to receive an industry standard, same format, for any type of billing. With regard to usage, that has been pretty well defined, that OBF with the EMR, and the unbundling, I think that's being further defined as they get into some of the component pieces, as the local switching and other unbundled elements get a little better definition. MR. GUDE: Bob? MR. FALCONE: Yes, Kalpak, thank you. I agree with my fellow panelists with respect to resale. There are interfaces established today. However, one of the problems, unless those interfaces are enhanced, if they're using their current retail model, there is a restriction on how many accounts you could put on the same billing account or how many lines you could put on the same billing account. So, what we're finding ourselves in, often, is a situation in resale of having multiple billing accounts to get our bills, because there's a max. So, I think there's some enhancement work that needs to be done to the retail biller to expand that, so we get one bill for our usage. With respect to unbundled elements, I also agree that CABS is the method of choice for us to receive our bill for the elements and I think we only heard of one half of that unbundled element equation, though, and that's the bill to us for the use of the element. Where I think there's the major void is, as I mentioned in my opening remarks, is how do we get all the usage that we need from the unbundled elements, so that we can turn around and generate the bills that we have to generate as a CLEC operating in that area, specifically access, reciprocal compensation and user billing? I think that's a major void right now. MS. LAWSON: I would agree with what my panelist also said, as far as a void. Southwestern Bell has discussed looking at putting new, deploying new software in their switches that will provide the type of information that is being discussed. It's just a matter of timing to get funding for that software and then getting it deployed in the switch and identifying how the unbundled local switching product would be defined. I agree with moving there. And, with regard to the other comment, as far as number of bills, AT&T didn't mention Southwestern Bell, but I know that was very near and dear, based on some previous discussions we've had. We do agree that we need to look at the number of bills that we are issuing, because in a retail world, you do issue them to end users. When you get into a wholesale world, you need to look at summarizing those up and offering fewer number of bills. We have agreed to look at what type of options, depending on the type of data that CLECs would be willing to receive. In other words, you could get your bill at one point and get the subsequent billing data at a different point, so that it could be aggregated, so that your bill would be at one time during the month, but your billing data could be spread out throughout the month, so you could get it that way. MS. BERUBE: I think from our perspective, we are also looking to add more flexibility to our current systems. As I mentioned earlier, there are many systems involved in billing. They're large, they're complex, they've been developed over a long period of time. If we had the resources and the opportunity and could make it happen tomorrow, possibly we would replace everything we have with something better and greater. However, that's not the case, and especially for a company of our size. We certainly cannot afford to do so. So, we are continuing to look at building flexibility into the systems that will accommodate the new customer environment, and working with the customers on short term and long term solutions to get there. MR. FALCONE: I was simply going to say that I purposely didn't implicate Southwest Bell, because if you believe the newspaper articles that you're reading, I may be working for them soon. (Laughter.) MR. WELCH: I was going to comment on the last panel and I bit my tongue, but somehow, inadvertently, we had the Southwestern Bell and the AT&T people in the last panel sitting side by side and I wanted everybody to know that was completely inadvertent. (Laughter.) MR. GUDE: This one is directed towards you, Dennis. There's been a lot of talk about standardization in formats. What are the formats or standards you see industry moving towards or will continue to have, or will we continue to have multiple formats in the future? MR. PERKINS: Well, I hope we don't have multiple formats. There are a lot of standard out there today that exist. I mean, we've had mention of EMR formats, and I think that's a fairly standard format. But, the application of some of those standard formats are different between companies, which makes it difficult to program the different nuances of those into an existing system, when you're trying to do a national application. So, I believe there are formats out there that we can use. There are also systems that we can use to transmit data back and forth. We have NDM systems set up and CMDS systems set up to transmit data throughout the country, between the different telephone companies. So, I see that there are things out there, in the exchange of records, messages for telephone billing, but there are some other issues that have been mentioned with the unbundled loop elements, and those that haven't been. There are also areas of just this week, I was asked by Southwestern Bell to provide two official company numbers, one for resell, one for our facility based operations. And, by having two in each state that we do business, that will make it confusing, as to which one people should use to put the operations and the transactions for Brooks, and to identify those. So, we're trying to develop systems around existing legacy systems that will cause problems when we exchange data. MS. BERUBE: If I could, I'd like make a comment on that. Dennis, I agree with you that across the country, different companies have implemented the billing functionality somewhat differently. I think, however, that is going to be the nature of the beast on the going forward basis. Although the names of the products and services that we will offer to CLECs might be the same, the terms and conditions under which they're offered and the specific tariff requirements may be different, and that oftentimes drives the billing. So, to the extent that there might be a different term and condition or different pricing arrangements for certain services, the billing for those will be different from company to company, and I'm not sure how that can be avoided, quite honestly. MS. LAWSON: I might add to that, I know you mentioned earlier about the clearinghouse, some of those relationships like were mentioned with tariffs, also impact the independent companies that you're operating with and sharing records, so some of those types of relationships drive what type of record types get provided in the clearinghouses between the BOCs and the independents, so those can also impact. MR. GUDE: This is a question for Bob. In situations where the incumbent does not have sufficient billing information for exchange access, how do you propose to bill or how do you propose that they bill for exchange access when purchasing the unbundled local switching element? I think what I'm looking for is sort of a further explanation of the factor based approach that you mentioned earlier, and I would like the other panelists to comment on that approach, as well. MR. FALCONE: Before I go into the detail, which I certainly will, I want to stress that I believe the factor approach is an interim approach, subject to true up. So, the one thing that's important to note is that all the information is available. It's just that the billing systems that the incumbents have today never were required to cull out on a line by line basis which terminating access went to which line. It was just terminating access from an IXC and it got billed en masse. Now, there's a need to do that, and further downstream, the long term solution is to have further downstream systems, sort of do that line by line comparison and get the usage into the right pie. Until that happens, my proposal is the use of a terminating to originating ratio and how that would work is, you would, the incumbent elect knows that an end office level, the IXC, in aggregate, T to O ratio, is, they know the total originating usage for all IXCs on that end office. They know all the terminating usage and based on that, they can develop a ratio of whatever that is. That ratio would probably go out to five decimal places. You know, it might be .98763, but let's just say for argument's sake, it's .99, just to make it easy. So, that .99 means that for every hundred originating IXC calls in that end office, there is 99 terminating. So, now what would happen is, my total originating usage, me, as a CLEC, that 99 would be applied to my total originating access usage, and that's how we'd derive my total, a bucket of what I'm entitled to bill for terminating, cause under the assumption that my end users in that end office are mirroring the profile of that end office. So, if I originated 1,000 IXC minutes, my customers originated 1,000 IXC minutes, I would be able to bill terminating usage for 99 percent of that thousand. Then, how you would allocate that 99 percent amongst all the IXCs, because now I know how many minutes I'm entitled to, now I have to know who to bill them to, it would be a simple ratio of all the IXCs that operate on that switch, let's say there's five, what percent of their terminating traffic? So, if AT&T as an IXC terminates 50 percent of the traffic into that switch, I'm entitled to bill AT&T 50 percent of my bucket of terminating minutes, and if MCI was 30 percent, I'm entitled to bill MCI 30 percent and so on, so it would kind of be two ratios, one the T to O and then one based on the percent of IXCs operating in that switch for terminating traffic. MS. LAWSON: Southwestern Bell's current policy is that on resale lines, that the access is Southwestern Bell's revenue, so they therefore did not see a need to provide access records to the CLECs, because they have no need to receive them, since the revenue is Southwestern Bell's. However, if that policy does change and if we did lose it in arbitration, we had talked about the factoring. The situation that you get in with doing factors in the access world, when this was done is, you get billing disputes, because it's not actual information. So, I'm developing a factor based on something that I think happened, but it's not an actual occurrence. So, when you develop factors, you do set yourself up that it's not what actually happened and there can be, oh, I really don't think I had 50 percent or I don't think I had 80 percent, are you sure your switch recorded it? So, we would prefer, if we did look at giving access records at some point in the future, to have that available coming off the switch, to identify which CLECs' record that was, so that we wouldn't get into a factoring position. MR. GUDE: Just one follow up. That was your position on resale, but what about the unbundled switch from the unbundled platform? MS. LAWSON: It is the same, too. MR. GUDE: That it is SBC's position that SBC holds the -- MS. LAWSON: The access revenue, correct. MR. GUDE: SNET's position? MS. BERUBE: On resale, we agree with SBC. In terms of switching at this point, we don't have our full policy established. We don't have unbundled switching yet available. That is going to happen in third, fourth quarter this year, so we will roll out the whole product and at that point, make those decisions. MR. GUDE: Bob? MR. FALCONE: With respect to Beth's concern regarding, first of all, to her first concern, I don't agree with her at all on policy, but we won't even get into that. MS. LAWSON: We don't have to discuss that, right? (Laughter.) MR. FALCONE: Right, we won't go to that movie here. With respect to the second issue, I agree. As I said, there is a history here, and that history was kind of ugly. Factors do lead to billing disputes, no argument there. I think it's real important to stress this factor proposal is a short term, interim solution, because the data that's needed to give us the actual usage is there. It's just like, it's there, but you don't know how to extract it, and the proposal is that as soon as you develop the downstream system to extract that data, you go back and do it even on those records that we had factors, that we used factors for, and we true up those bills based on actual usage. So, Bell Atlantic, for example, has said to us that they are developing this extraction means and they will have it available by August. So, that's great, and perhaps we won't even be in business with unbundled switching in Bell Atlantic territory until then, so we won't have to use these factors with Bell Atlantic. But, to the extent that some other company can't develop what Bell Atlantic has developed in time for us to use the unbundled switch, all I'm proposing is these factors be used until such time as they do. MS. BERUBE: One thing that I may add to the extent that companies do not currently have available to them this data, and have to go to large expense to implement the recording capability for that data, we have a cost recovery issue, as well, and that obviously remains to be determined as to what that mechanism will be, but I would propose that those costs need to be recovered. MR. GUDE: Dennis? MR. PERKINS: On our access recordings, what we've been doing is working with a switch vendor to work a way to record those minutes that are switched, the terminating minutes. In certain cases where they're not, we're exchanging originating minute information with the local ILEC to, for looking at the access billings. But, we are working with the switch vendors to look at, can we record those terminating minutes. MR. GUDE: Bob? MR. FALCONE: To Mary's concern, the industry standard for recording terminating access in the switch requires that you record the originating number, the terminating number, the carrier ID, so, again, the point is, the information is there. As long as Southern New England Telephone or any incumbent LEC is following the industry standard for recording terminating access records, the information is there. The incumbent LEC never needed all that information to bill the IXCs, the access, because it was billed in aggregate, but now they do need it, so that they could separate out what piece of that a CLEC is entitled to, as opposed to they're entitled to. That's where there may be some cost recovery, is whatever needs to be developed to separate that out. MR. GUDE: To Dennis, could you explain how originating and terminating access is billed when you purchase an unbundled loop and number portability? MR. PERKINS: That has had several disputes around developing formulas to capture those minutes with the interim number of portability. We have worked with historical data, looking at the originating and terminating minutes, and used that as a factor, and tried to identify the minutes that are particularly associated with the interim number of portability type calls, and used that, in certain cases. In certain cases, we're still under negotiations on those terms, so we haven't come to a resolution on how to identify that access. But, we talked about in certain cases using our data or historical data to identify the types of calls that are coming through the switches. MR. GUDE: Would anybody else like to comment? MS. LAWSON: With our unbundled local switching right now our billing or our pricing is based on originating minutes, it is not based on terminating minutes, at all. Because as I mentioned earlier, we're looking at new software that will be deployed in the switch, so right now, the billing is based on originating minutes only for local switching. MS. BERUBE: Specific to number portability in our tariff, we use what SNET has for the past year measured for an average access minute, and we use that factor and that's specified in our tariffs. MR. GUDE: I think at this time we could open it up to questions from the audience. MR. WELCH: Please state your name and who you're with and direct your question. MR. MARLIN: Dave Marlin, LCI. Although I'd love to get into access charges, we haven't got enough time in the world. Directing it towards daily usage files and, well, specifically, daily usage files, right now, with probably the worst delivery we get is, I think 15 percent of the calls in any one daily usage file are three days late, another 30 percent is four days late, another 20 percent is five days late, etc. We probably don't get the usage for any one date until about seven days after that particular cut off. Let's say our billing cut offs the end of the month. We have to wait seven days to get 90 percent of the data from a BOC for that day, so we can start billing. We aren't dealing with you right now, but I wonder, what are your service levels for delivering daily usage to the CLECs? MS. BERUBE: I don't have exact figures, but our standard is 95 percent within 24 hours. MS. LAWSON: What our price currently is is whatever comes into our CRIS billing system, or it would be our CABS billing system in the, for Unbundled Network Elements. When that usage is brought into that night's cycle, it is passed to the usage extract feed and that is available in that nightly usage excerpt feed that is available between midnight and 1 a.m. So, as soon as our billing system has it, your usage extract feed has it, just past that. Now, the only reason there would be a delay is if we were receiving it, like an in-collect from someone else or an alternatively billed call. But, we wouldn't have it in our billing system, as well, either. So, as soon as our billing system gets it, it goes in that nightly feed. MS. BERUBE: Right, since these systems are basically processed in a batch load to the extent that a call was made, just about the time that the recordings were dumped off to the usage feeds, you wouldn't see that the next day, but generally, when we have -- same thing with Southwest Bell, when we have it, you get it. MR. MARLIN: Okay, and in terms of the monthly -- you do send CABS and CRIS files monthly? MS. LAWSON: The usage, right. MR. MARLIN: When do those get to the CLECs? MS. LAWSON: It's between the midnight and the 1 a.m., the usage extract feed for any usage that's billed on the CABS bill or the CRIS bill will be included in the daily feeds. MR. MARLIN: Our experience has been with other RBOCs that it's been a long time, and we -- there's nothing that angers a customer more than getting service charges and call charges two months later. MS. BERUBE: And, on usage, I would agree with you 100 percent, which is why we recommend daily usage feed, so that data is timely. To the extent that some CLECs don't have the capability to process that information, that's another issue. However, with non-recurring charges and monthly charges, as I mentioned earlier, the CLEC is in control of the services that it provides to its end users and knows what it needs to charge for those services. There need be no reliance on the monthly bill that the ILEC sends for the services. The CLEC purchases from the ILEC, in order to do end user billing for those services. MR. MARLIN: Let me understand, then. Then, you mean the CLEC has all of the USOC charges and other service charges that you would provide for the CLEC? MS. BERUBE: No, I'm sorry, I mean that the CLEC is the one who is actually providing the services to the customer, and I'm assuming the CLEC has filed tariffs in its appropriate territories that define what those services are. The CLEC can therefore bill the end user for those services, because it knows what it's providing to its customer, and that is really independent of the services that the CLEC purchases from the ILEC. MR. MARLIN: But, the CLEC normally purchases customer premise service from you and then resells to the customer? MS. BERUBE: You have tariffs, however, that specify what those rates are for your customer and the charges that you supply to them, so while there is a reconciliation that the CLEC might want to do between the charges that it receives from the ILEC and what it's billed its end user, certainly the CLEC has the capability to bill the end user based on the services that you provide and the tariffs that you file. MR. MARLIN: But, when do I find out how long you've been at the customer premise? MS. BERUBE: Excuse me? MR. MARLIN: When do I find out as a CLEC how long, how many hours, you've been on the customer premise site for a non-recurring charge? MS. BERUBE: Again, that depends on tariffs. If there are hourly rates or if there are flat rates, there might be some need there. I know in Connecticut, our tariffs are flat rates. MR. MARLIN: Okay, you're flat rating. MR. GUDE: I think we need to move on to the next question. Are there any other questions in the audience? MR. BLAINE: Thank you, I'm Larry Blaine, staff economist, Nevada PSC. We're having a, I think, somewhat unique circumstance in Nevada, where Nevada Bell relies on Pacific Bell for billing and other OSS functions. Obviously, this creates a potential jurisdictional problem for us in that a CLEC, a Nevada CLEC, may find itself in the situation where it has to negotiate with Pacific Bell for certain OSS functions. If that CLEC were then to seek arbitration before the Nevada Commission, since Pacific Bell is not a Nevada ILEC, time will tell. Fortunately, we have not been faced with that circumstance, but clearly, there may be a role for the FCC in that. I have a question, though, more of an economics question, in that, are there the economies in OSS function such that these systems ought to be developed at the holding company level rather than at the operations or operating company level? That's my question. MR. FALCONE: I could just answer based on what I know is happening and it varies by company. Some companies are having it done at what you're calling, Larry, the holding company level. Other companies, because of their Legacy systems and because the holding companies are -- I'll pick on Bell Atlantic -- if there's any Bell Atlantic people here, forgive me -- the holding company at Bell Atlantic was really a compilation of three smaller companies, New Jersey Bell, Bell P.A. and Diamond State. So, there's some Legacy systems there that, in effect, somehow prevents some companies necessarily of having a ubiquitous company-wide system. I don't know if that's answering your question. MS. LAWSON: From Southwestern Bell's perspective, with the five states that was in Southwestern Bell's telephone territory, that was the same. For Pacific and Nevada, those were two, and they did have different systems. So, as was alluded to, we have different Legacy systems. It makes it difficult because of the operating environment that you're in, could drive the type of OSSs to support those. MS. BERUBE: In SNET, our IT organization which maintains and administers the Legacy systems, is part of what we would consider the holding company. MR. GUDE: Any other questions? MS. BINGAMAN: I'm just curious what forum and how are you telling me -- the right to access charges -- on a network platform? MS. LAWSON: That's a policy decision that I don't get to make. MS. BINGAMAN: I just meant where? MS. LAWSON: In negotiations. MS. BINGAMAN: Before a convention, right now, do you know? MS. LAWSON: Not that I know. MS. BINGAMAN: You're not aware of a decision by a public body? MS. LAWSON: Not that I'm aware of. I'm not aware of some of the policy issues still in effect. They don't let me get involved in that, thank goodness. MS. MOORE: I'm Diane Moore from MCI. I have a question from Mary. I understand that you've chosen to use CRIS for resale billing, and at MCI, I particularly support CABS for that, but I understand there's a difference. Whenever companies are choosing CRIS, there is, as Beth pointed out, a mechanized 811 EDI standard for CRIS. When SNET mechanized their CRIS, they did not choose that standard, which therefore caused me extra development work and cost to receive your bill in automated fashion. Two questions for you. One is, do you know why you did not go with an established mechanized interface when you did mechanize your CRIS system, and the second question is, since your decision to go non-standard caused me excess work and extra cost. Can you help recover some of that cost? MS. BERUBE: I think I'll answer your first question first. (Laughter.) MS. BERUBE: Basically, because one or two of our customers had asked us for something mechanized, we used what we had readily available to get something out there right away, and that is the God's honest truth. Customers wanted something electronic, we had something that we provided on the end user side that was electronic in format, it fit the immediate need. In terms of the 811, that is one of the alternatives we're evaluating. Since we don't offer that today internally, we don't use it for end user billing today, it is a new development process for us, so that is something that, as one of our alternatives, that we might present to our CLECs when we have done a full evaluation, but it just wasn't available at the time. It's not something we had been doing. Had it been, I'm sure we would have offered it to you. MS. MOORE: So, if you changed back to 811, I'd have to do more development work to change that to 811. And, if you're not being consistent with the way Southwestern Bell and others have done the 811, then I'll have more development work to receive your mechanized on top of what I've done to receive it already? MS. BERUBE: I think that would be up to you whether or not you wanted to change. We wouldn't eliminate support for what we are currently providing. MS. STROMBOTNY: I'm Tracy Strombotny from LCI, and basically, what I want to use bills from LECs for is to validate that what was provisioned by the LEC is what I'm charging my customer for. Because there are manual interfaces in some places, sometimes we find that what gets turned up for the customer isn't exactly what it was before or exactly what we asked for. What I'm wondering is, do you all have any plans to provide some kind of a massive comparison system for the situation where what we're billing is not what you have provisioned, if things get truly, largely out of whack, where what I have asked you to order is not what got turned up. Do you have any plans to provide those systems to CLECs? MS. BERUBE: I think that's really part of an adjustment process, and we have an adjustment process that we've put in place. It is not fully mechanized at this point in time. I think it will take awhile before that process is fully mechanized, but certainly it is in our interest to make sure that what you've ordered is what's provisioned, and we would confirm on a service order completion for those services that have been ordered electronically, providing back the purchase order number and service order number that a service has been implemented, so that is our way of identifying that what you've requested has been provisioned. Then, that is further supported at the receipt of your monthly bill. So, to the extent that there is any discrepancy, we would expect that the adjustment process would apply. MS. STROMBOTNY: Just to follow up, does that mean that under -- that's USOC by USOC? MS. BERUBE: No, it's not. MS. STROMBOTNY: So, it's just this service order is complete and we can't compare service by service? Okay, thank you. MS. BERUBE: That's correct. MS. LAWSON: Are you looking for any type of validation back to what you're billing your end user, or are you just looking at what you ordered to what the ILEC would bill you? Because there has been some discussion that the CLEC would like be able to validate from their customer database the quantity of USOCs they have at a WTM level back to what I call auxiliary service information that could be provided with the billing detail. So, at some type of level of detail, of course, you would have timing differences there when you service order post it, that I've got 50,000 of USOC one. I've got 250,000 of USOC two, you know, at a high level. Then, if you want to go down at a WTN level. MS. STROMBOTNY: Yeah, I want to go down at a WTN level so I don't have a customer paying for a service that they're really not being provided, because it wasn't provisioned. So, I want to WTN, and by WTN compare those services and features by USOC, to make sure that I have accurately provisioned their order. MS. LAWSON: And, with the EDI 864, that gives you the auxiliary service information by USOC level of detail, with the WTN, and with the Bill Plus, with the CD-ROM version, that will include auxiliary service information at a USOC level by WTN for what Southwestern Bell provides. MS. STROMBOTNY: But, isn't the 864 a free format transaction? MS. LAWSON: No, it's got the USOC level and would show the quantity. Then we have an implementation guide that maps that type -- MS. STROMBOTNY: Can I get a copy of your implementation guide? MS. LAWSON: Yes. MS. STROMBOTNY: Thank you. MR. WELCH: Okay, I think we're about out of time and we need to wrap this up. I'd like to thank our panelists on this, Dennis Perkins, Bob Falcone, Mary Berube and Beth Lawson. Thank you very much. We'll take a short break and reconvene promptly at noon for our last panel. (Whereupon, a short recess was taken.) MR. WELCH: Okay, why don't we get started with our fifth and final panel of the forum, please? This panel will be on maintenance and repair. Before we actually get into that, I'd like to thank a few people who were instrumental in helping put this forum together. We had some fine help from our Office of Public Affairs, from the Public Service Division, and in particular, Martha Contee and Susan Szulman, who has been instrumental in keeping us on time, and we have hit all our deadlines. So, we thank them and also the folks working in our audio-visual department, tooling away back in the booth, have done a great job putting this production together, and it will result in a videotape, hopefully, that people will take home from Eros -- Blockbuster Video, excuse me. All these mergers, I have a hard time keeping up. We're going to now turn to maintenance and repair, and I harken back to the days of the local competition rulemaking here at the Commission, the 251 rulemaking back last summer, where we had this huge debate. One of my favorite issues that came before us was the maintenance and repair and how to handle this. There was a suggestion made that when the incumbents' repairman pulls up in the driveway at somebody's house, that they should whip out a little velcro badge and put it over the incumbents' logo and put the new entrants' logo and then take a panel and cover up the side of the truck, and put the new logo on. This is one of my favorites. The topic today, of course, is how that relates to OSS. So, let me introduce our panelists and then we'll have brief opening statements from the four of them. Going from right to left we have Gloria Calhoun. Gloria is with Bell South Corporation. She is the director of Bell South. Sitting next to Gloria is David Swan. David is from Bell Atlantic, where he is vice president of carrier services. Next to David is Bob Welborn, and I apologize, Bob. He is with Sprint Corporation and I think there's been a substitution here. He is a director. I apologize, Bob. Then, finally, we have next to Bob, Rod Cox, who is with Consolidated Communications, Inc. Bob is manager of market expansion and operations. So, we'll hear from each one of these four folks briefly, and why don't we start with Gloria? Gloria, please? PANEL III MS. CALHOUN: Thank you. Non-discriminatory access requires Bell South to make available information and functions in substantially the same time and manner as Bell South's access for its retail customers. Bell South has met this obligation for repair and maintenance by providing CLECs with access to the same system used by Bell South's repair attendants to handle trouble reports for residence and business exchange services. Bell South also offers CLECs an electronic bonding gateway for trouble reporting on local interconnection trunking and other design services. Bell South's retail repair attendants process local exchange trouble reports, using a system known as the Trouble Analysis Facilitation Interface, better known as TAFI. TAFI is a common presentation expert system that provides rapid, consistent and efficient automated trouble receipt, screening and problem resolution. It's an interactive system that prompts the repair attendant with questions and instructions while automatically interacting with other internal systems as appropriate. TAFI also provides the queuing of reports, enabling a repair attendant to work on several customer troubles simultaneously, and it also provides on line reference tools. TAFI is a user friendly interface that often enables trouble reports to be cleared remotely by the repair attendant handling the initial customer contact, often with the customer still on the line. With this system, any repair attendant can correctly handle a trouble report on any Bell South provided basic exchange service. TAFI provides electronic access to other Bell South systems that might be involved in resolving a trouble report, by automatically interacting with the correct Bell South system for a given situation, and TAFI also will execute the appropriate test or retrieve the appropriate data. For example, if a customer were to report that the customer's call forwarding feature was not working properly, the TAFI system would electronically verify that the feature was programmed in the switch serving the customer's line. Once the TAFI analysis of the trouble is complete, TAFI provides the repair attendant a recommendation of what is needed to correct the problem, and in some cases, actually implements the corrective action. In the above example, TAFI would correct the trouble by implementing a translation change in the switch to add the feature to the line. If the switch translations had been correct, the repair attendant could provide instructions on the proper use of the feature, using the TAFI help feature. Bell South has provided CLECs with non- discriminatory access to its TAFI system. The CLEC TAFI system contains all the functionality described above that's contained in the Bell South TAFI system, including the capability to view maintenance histories. In addition, by providing access to TAFI, Bell South is making available to CLECs the functionality inherent in the many systems with which TAFI connects. The only difference between the CLEC TAFI system and the Bell South TAFI system is a security step that occurs electronically and nearly instantaneously. This security screening step is required because the CLEC TAFI system will be used by repair attendants for multiple CLECs. Therefore, TAFI identifies each CLEC's repair attendants by company, and allows each CLEC's repair attendant to access only that customer's records. Once that validation check has been performed, the CLEC repair attendant has access to the full range of TAFI functionality that's available to Bell South's retail repair attendants for both business and residence exchange services. Other than the security check described above, TAFI functions identically for CLECs and for Bell South. TAFI has been used by three CLECs in the Bell South region, and Bell South is in discussion with nine other CLECs on the use of its TAFI system. That concludes my remarks. Thank you. MR. WELCH: Just for the record, could you spell that acronym, TAFI? MS. CALHOUN: It's T-A-F-I. MR. WELCH: Okay, next we'll hear from David Swan. I love these acronyms. David, if you're going to tell me that your system acronym is SALT, I'll buy you lunch today. MR. SWAN: I guess I won't get lunch today. Good afternoon. I'm going to address my comments to three areas related to the subject of CLEC access to operating supporting system repair and maintenance functions. They are the quality of the access we're providing to our CLEC customers. The standards we've adopted to insure that the service provided is on par with what we provide to our end user and access services customers, and finally, the types of interfaces we have already deployed to make sure that high quality and dependable OSS access repair and maintenance is given. First, Bell Atlantic is committed to providing equivalent access to our CLEC customers, and that is the same or nearly the same access that we provide to our current customers. Currently, our end user customers call a Bell Atlantic trouble administration call receipt center to report troubles. POTS customers are connected to a voice response unit for trouble analysis and call clearance direction, and to close out as many reports initially as possible. Our design services customers call our centers that handle these services. Our access services customers may also call Bell Atlantic with their trouble reports or use either of our two electronic means for trouble reporting and repair and maintenance administration. These two include electronic bonding open systems interconnect or our communications gateway that we refer to as ECG. For our CLEC customers, Bell Atlantic will provide the same repair and maintenance capabilities. CLECs may call their trouble reports to our regional CLEC maintenance case team, a dedicated regional center designed and staffed to support the CLEC repair maintenance administration. The CLECs may also choose to use one or both of our electronic means for trouble reporting, electronic bonding, OSI or ECG for both design services and POTS and this interface will be administered by the same regional CLEC maintenance case team. Both electronic bonding, OSI and ECG, provide direct access to the operating support system that administers the particular service. Almost for POTs type services and WFA, Work Force Administration for design services. Electronic bonding OSI allows a CLEC to create a trouble ticket, establish POTs appointments, change and receive status and close out information automatically. ECG provides the same automatic capability, except that it requires manual query from the CLEC for statusing. So, whether the CLEC calls or electronically sends a trouble report to Bell Atlantic, they will receive the same repair commitment. Regarding standards, Bell Atlantic has designed a repair maintenance process for our CLEC customers that is nearly identical to the process that is in place today for our own end user customers. There are no national standards at this point for CLEC POTS and design services trouble report processing. There is, however, a national standard for the electronic interphase for access services customers, trouble report administration and electronic bonding open systems interconnect, which Bell Atlantic provides. Bell Atlantic additionally has developed an alternative electronic gateway capability previously mentioned, ECG, to also support this process. The ECG process is more cost effective and requires only a dial up or direct dedicated connection. This leads to my final comments, the types of electronic interfaces that we have currently deployed. As previously mentioned, the only national standard for interface in this area is the T1M1 guidelines for electronic bonding for access services using OSI, which Bell Atlantic provides. In fact, Bell Atlantic was the first ILEC to connect in OSI application to both AT&T and MCI for trouble report administration for access services. Bell Atlantic has agreed to use nearly the same electronic bonding application for repair maintenance for AT&T for local service, and is ready to meet AT&T's requirements in this area. Bell Atlantic has offered the same capability to MCI and any other CLEC who is interested. In addition, Bell Atlantic has developed, as we mentioned, a 3270 screen immolation process, dedicated or ECG, which offers much the same functionality as electronic bonding OSI, but at a much more reasonable cost. ECG has been enhanced to fully support CLECs for most local services. Thank you very much for this opportunity to provide these comments regarding Bell Atlantic's efforts to provide CLEC access to its repair and maintenance OSS functions. MR. WELCH: Thank you, David. Next we'll hear from Bob Welborn at Sprint. MR. WELBORN: Good afternoon, it's a pleasure to be here and share a few thoughts on maintenance and repair. Before we start, though, I'm afraid Richard might have everybody at the ballpark, so I'd like to bring you back to reality. It's a rainy day, game's been canceled, you have to go to work. You're now in a repair bureau for the CLEC, and knowing your next call is going to be a customer in distress. Now we set the stage, let's go ahead and continue with the comments here. Repair and maintenance support systems is considered the most critical support element after service provisioning. End user customer problems require immediate action, especially if the customer has an out of service condition. Setting and satisfying customer expectations can only be accomplished through proper diagnosis of the problem, dependable appointment setting, timely dispatch, accurate and timely correction of the problem, and constant customer communications. There are three components of repair and maintenance. They are prevention, detection and correction. Many times, we only look at the correction side of this and not the other two elements that are essential. Real time Operational Support System integration between the ILEC and CLEC are essential in providing these capabilities, whether it be total service resale or unbundled elements. Electronic bonding platform is a solution that may satisfy integration requirements. EB is currently being implemented in the access environment, however, EB must be enhanced or provide capability that will assist in testing customer troubles. Key elements to keep in mind, the "Big C" customer is the end user in all cases. Customers want their problems solved in a timely manner and accurate manner. They want to speak with informed and empowered customer repair representatives, who will solve their problems. These expectations cannot be satisfied without seamless operational support systems that provide the information and scheduling capabilities. Unfortunately, CLECs' repair and maintenance performance will be no better than the performance of their weakest network provider. Currently, many ILECs have established GUIs, trouble handling that allow varying degrees of capabilities that differ markedly from ILEC to ILEC. MLT is an example of an essential tool that diagnoses trouble and can eliminate needless dispatches. Some ILECs have elected not to provide access to or provide only limited access to their MLT systems. Denying MLT access is an example of an area where an ILEC may have a service that differs from a CLEC. Sprint has been in the local market in California since the latter part of 1996 and has been purchasing service from PacBell and GTE on a resale basis. Communications of troubles have been through PacBell's LI Office GUI interface and manual telephone calls to GTE. Although Sprint currently has only a small number of local service resale customers, Sprint is experiencing an unacceptable level of inaccurate, incomplete and misplaced service requests. This has led to customer complaints, dissatisfaction, and in some cases, actual loss of the customer account to their previous carrier, who is the ILEC. Accuracy and timeliness of service provisioning has also impacted the repair experience, because customers have been inadvertently disconnected in the migration process. While GUI solutions move CLECs beyond the manual processing, they create nonstandard interfaces that add administrative and operational burdens. These proliferations of GUIs will continue to expand to likely unmanageable levels as Sprint enters new markets. In addition to the multiple interface dilemmas, there is no real time access to the incumbent support systems to enter the customer service request, directly access appointment schedules, initiate status reports and perform full MLT testing in parity with the level of service that the incumbent provides to its own customers. Interim electronic interfaces are not adequate, short term or long term solutions, but only a bandage to meet today's insignificant levels of demand. In addition to the need for real time interfaces, to insure accurate and timely handling of customer expectations, there's a need for the ILECs to self-report performance levels, to insure consistency of service delivery across all entities. Standard performance measurements need to benchmark the ILECs performance and their affiliates performance against individual and industry CLEC performances. Measures and calculation methodology have been proposed and the local competition user groups service quality measurement documents. In summary, it is essential that real time interfaces provide a seamless customer experience and provide efficient, timely and accurate information to the CLEC customer repair representatives, satisfying customer expectations, all based upon electronic system-system platform integration. Thank you very much. MR. WELCH: Thank you, Bob. Last we'll hear from Rod Cox at consolidated communications. Rod? MR. COX: Thank you, Richard, and since I'm the last panelist, I think it's only appropriate that I can close with the baseball theme. I would like to start out by saying that last year in May, Consolidated Communications felt like a minor league team playing in a major league stadium. The first six innings were errors, full of errors and a lot of delays. The innings seven, eight and nine, we started swinging and reduced the errors. Now, we're in the 12th inning, extra innings, by the way, and we're all tied up. You can take that literally, if you like, but we're still in the game. I am confident we're going to win the first game of many series of games to come. For all you start up LECs out there, CLECs, practice, continual improvement and keep swinging. We can win. It's going to be a long season. That's my game story. Now, I'd like to give you a little brief history of Consolidated Communications. Consolidated Communications started in 1894 as Illinois Consolidated Telephone Company. Today, Illinois Consolidated Telephone Company is the 26th largest local service provider and the largest privately held telephone company. Consolidated has grown as a fourth generation family owned company into a multiple facets of the telephone industry. Consolidated diversified by entering the IXC business in 1984 and then as a CLEC in 1996. Our 103 years experience in the telephone industry has proven invaluable. We were certified in the CLEC business in 1995 and began the facilities based unbundled loop offering in May of 1996. Our goal was to be the first in downstate Illinois to give to customers a choice in three chosen markets of Springfield, Decatur and Champaign-Urbana. The goal was accomplished, but not without tremendous pain and fast learning. My CLEC experience and my primary responsibilities for the last year have been to improve our internal processes, because some of those were broke, and improve the relationship with Ameritech, and to define and develop performance measurements that are, in my opinion, key to this business. I initiated the operational support systems, interfaced alternatives with Ameritech and personally have been excited and challenged by this effort and am honored to be here representing Consolidated Communications on this panel. What access should incumbent LECs provide for repair and maintenance? The best case, give us access to everything you've got. The issue is to us not so much what you provide, but what it will cost us. We would like to have trouble ticket information matching real time, both systems, real time opening and closing of tickets, with clocks matching, which is not always easy. On line escalation status and comment fields, test results with access times and forced to load schedules should also be available. It is very important to understand how duration is measured, and who authorizes the clock to stop. Receipt to clear in this business is a two part process. Clearing back to the CLEC is the second part that should not be taken lightly. Having the ability to communicate to your customer what the status of that condition is is very critical to our business. What standards are necessary for parity? Consolidated supports standards for the industry that will insure parity. The key is making these standards efficient and affordable for all. Adhering to standards developed just for large companies with complex needs will drive cost up and force smaller players like us to use GUIs or inquiry only type systems. Standards should be tiered with varying levels of business needs, and with the flexibility to add functionality as budgets exist or as budgets can handle it. What types of interfaces are we today using or proposing? Today, we are currently using a Trouble Administration GUI with Ameritech. We have just begun to use this process. It is a PC dial up software application that was provided by Ameritech. We are exploring other alternatives with them and with external consultants. As a final comment, Consolidated's experience in electronic bonding for operational support systems for maintenance repair are just beginning. We will continue to test simpler, less costly solutions. We will continue to work with Ameritech and other ILECs as we choose in pursuing these simpler solutions and we will openly share our success or shortcomings with other players in the CLEC arena. Electronic bonding of systems will only be as good as the linked processes that are in place and the commitment and the relationship between the ILEC and CLEC. Without that, we have nothing. Thank you. MR. WELCH: Thank you, Rod. Now we'll have some questions and hopefully we can generate some discussions back and forth among the panelists. Bob, if I could start off with you, please. Rod touched on this a little bit in his opening comments and I'd like to get your views on this, as well, from Sprint. This is a general question. What do you require from an incumbent in terms of access to repair and maintenance functions in order to effectively serve your customers? What would you like to see them provide to you? MR. WELBORN: I think that, as Rod had stated, we need to be able, one, to generate the trouble report on a mechanized basis. We need to know what an accurate appointment time is, so that we can talk intelligently to our customer and build the expectation of when the trouble is going to be repaired. We also need to test that line while the customer is, while we have them on line, so we can diagnose whether it's probable that the customer can be corrected more immediately and apply the right appointment interval, as well as we need the communications and the statusing on a continual basis on line, so that when the customer calls in or at such time that we deem it necessary to understand the status of a trouble report that is available to us on line, as well as we need the communications back to us once the trouble has been repaired. That's most important, so that we can communicate with the customer, close it out and insure that there's customer satisfaction. MR. WELCH: Bob, I think you mentioned you were talking about your experience in California, that you're reselling in California at the moment? MR. WELBORN: Yes. MR. WELCH: I imagine at some point, if you're not already, that you have plans for utilizing unbundled loops? MR. WELBORN: Yes, we do. We are not using unbundled loops in California. We are doing it in Bell South territory. MR. WELCH: Okay, this question goes to who has the responsibility for testing unbundled loops and should you as the new entrant have the option of testing them yourself or requesting that the incumbent do so for you and should the incumbents be required to give you access to their mechanized loop test systems? MR. WELBORN: In the unbundled environment, I think that there are several stages. One, when I purchased the loop, I expect that loop to be a working loop, and therefore, there is a desire for the incumbent to test that loop prior to giving it to me in the initial provisioning process. At the same time, when that loop is in need of repair, I need to have the diagnostic tools available, which would include any sort of mechanized testing capability. MR. WELCH: Would anyone else on the panel like to comment on that? Rod, do you have any thoughts? MR. COX: Yeah, we do our own testing. Unfortunately, testing is not always foolproof, and we've made the decision to, if in doubt, we dispatch our own people and confirm that it's dial tone to the NID. But, a lot of times, the test, you just can't tell. MR. WELCH: David or Gloria, do you have any thoughts on that? MS. CALHOUN: With an unbundled loop alone, I think that you have some issues about how you define an unbundled loop and some of the testing capability that is available on that loop that is associated with an integrated exchange service might not be present when the loop is separated from the switch. So, I don't think it's possible to make a categorical statement, but to your question, if I may generally talk about Unbundled Network Elements, Bell South's TAFI system that I described will also handle trouble reports for any Unbundled Network Element that can be identified with a telephone number. So, for example, an unbundled port can be reported through TAFI and appropriate status information can be obtained. A combination of a loop and port that can be identified with the telephone number will also be handled through TAFI, so it is possible for the Bell South system to provide an appropriate level of support for trouble reporting on Unbundled Network Elements, depending on how they're identified. Anything that's not identified with a telephone number generally is associated or identified by a circuit number, and those reports can be handled electronically through the electronic communications gateway or the electronic bonding arrangement that's available for design services. MR. SWAN: I would agree with Bob and Rod both from their response. Bob initially commented at the time that the unbundled loop is placed in service, there's some coordination required and some testing in connection with that to assure that the service is in order. When there is trouble, as Rod indicated, the initial testing should start with the CLEC, and to the extent that that testing suggests there's some difficulty from an ILEC standpoint, of course, we would become involved to support that. MR. WELCH: Gloria, if I could ask you to address this, we've heard a lot about parity over the last two days and how the incumbent will provide the same type of access that they provided themselves to the new entrants. Could you please describe a little bit how your company will insure that there is non-discriminatory access to your repair personnel and assets between your retail unit and your new entrants? Are you recording or evaluating your performance for retail business with what you provide your new entrants, and is that information made available? MS. CALHOUN: Well, there are two parts to your question, and the system part of it is that the system is identical and the system is oblivious to whether a request for repair is originating with a CLEC or with a retail customer. So, in terms of appointment times or handling the -- it's really immaterial how, from whom the trouble report is originating. But, in terms of, to get at the question of how you would measure that and how the trouble is actually handled, assuming that it requires a dispatch. Bell South has contractually agreed to contractual performance measurements. MR. WELCH: David, would you like to say how Bell Atlantic is handling that, as well? MR. SWAN: The process is basically parallel. There is, on a call from an end user, a check that we make initially to see if this in user, non-CLEC is the customer now of a reseller, for example, because some resellers have made it clear that should we receive that call directly, that we should refer it to the reseller. So, in that instance, there is some distinction in the way we handle the initial receipt of the call. But, once the call is received or the trouble is reported, it's just a trouble with the system at that point, and we would manage it and process it the same way. As with Bell South, we have agreed on some going forward reports on a comparative basis, to assure parity. We produced reports on a quarterly basis that would summarize the number of trouble reports, the average time to clear and some measure of average or total network availability, for an individual CLEC, and then for all of the CLECs for whom we're providing service. We also produced a summarization for the same metrics for Bell Atlantic retail customers in total, and then would include a similar analysis for our top three interexchange carriers, in this case AT&T, MCI and Sprint, again on a combined basis, to insure and to allow the CLEC to demonstrate that there's parity across that universe. MR. WELBORN: Richard, I'd like to interject something. I believe that once the trouble reports get into the systems, the prioritization is in concert with the ILECs. However, there are different methods, depending upon the different type of service, of entering trouble reports, such as in Bell South's area, some of our unbundled elements are handled on a telephone call basis. They're referred on a manual basis and then entered into the system. All of that process is on a manual type basis. So, you know, again, we need to take a look at what is mechanized, what is not mechanized, and realizing that there is a requirement to have everything mechanized so that it is handled the same all the way through the process. MR. WELCH: Gloria, go ahead. MS. CALHOUN: Again, I will say that Bell South is prepared to accept electronic trouble reports for any service or element that can be identified with either a telephone number or a circuit number. MR. WELCH: As sort of a follow up to this, if I could ask Gloria and David to comment on it, do the new entrants have the ability to receive automatic notification of repair completion for both Unbundled Network Elements and for resold services, as well as the ability to track the status of those repairs as they're going on? Is that something that your systems offer? MS. CALHOUN: Yes, for Bell South. MR. SWAN: And, yes, for Bell Atlantic. It's a little different depending on the electronic interface employed. With electronic bonding OSI, it's the statusing and the clearance is automatic, but with ECG, a gateway process, there is some requirement that the CLEC query the system to confirm the status update and the clearance time. However, for the clearance of the report, at any time it wants what is cleared through the gateway, they could introduce a direct status that would inform them that the trouble had been cleared. But, the actual information related or describing what caused the problem and how it was cleared, they'd have to access on a query basis. MR. WELCH: Bob and Rod, if I could ask each of you, is this something that you need and what has been your experience with this so far? MR. WELBORN: Richard, I'll take a stab at that. Yes, it is something that we need. It's something right now today in many cases there's no positive notification made when a trouble is clear. It's only whether or not you take the time to search through the system itself and gathered those statuses on your own. There is no proactiveness, and that differs from ILEC to ILEC. Some of them do notify you, such as they have the technician call your, the CLECs repair center, clear it out with the repair center. There are others that refuse to do that, and that it's totally on a passive basis. If you want to go in and see if the trouble was cleared, you can do so. MR. COX: I guess from our point of view now, we're pretty much a manual process with Ameritech, primarily calling back and forth and we have driven the issue pretty hard, especially out of service trouble, clear within 24 hours and those kind of things. We get a pretty good response back from them. The GUI that we're getting ready to test will provide that information. We'll be able to go in and see. The problem is, you have to have somebody going in there and scrolling for that information. We want some kind of flag back if we're going to use the GUI that says, you've got something in jeopardy here or it's getting close to the time when it should have been put into place or whatever or fixed. So, that is the problem with the GUI. An online system, you should have some kind of flag that would already come up and give you a red signal or something that's going on there. MR. WELCH: Okay, I think Kalpak has a question. MR. GUDE: This is directed towards both David and Gloria. If a service outage occurs for a CLECs end user, do you require CLEC authorization before a dispatch is made? MS. CALHOUN: I'm not sure I completely understand your question. MR. COX: I think what you're trying to get at, if there is an outage that you're aware of, is there authorization required by the CLEC before you will dispatch service people to address that problem? MR. GUDE: No, no, I'm talking for particular end users. MS. CALHOUN: So, you're saying, for example, if the CLEC end user were to call us directly, would we dispatch without contact of a CLEC? MR. GUDE: I'm saying, well, either in that case or the case that you become aware of it independently and you haven't been notified at that point? MS. CALHOUN: In the case of a CLECs end user calling us directly, we would ask the end user to contact their local service provider and any interaction we have with be with the CLEC, presumably through our electronic interfaces. If, I don't know the answer to your question, but if we became aware of a problem with a particular customer before a CLEC, my initial reaction is that we would probably work with a CLEC and not interact directly with their end user. MR. SWAN: In Bell Atlantic's case, I did much as Bell South's. If the CLEC user calls us direct and this is at the, again, the direction of the CLEC, we would refer the call to the CLEC. If the trouble, once provided to us, either verbally or through one of the electronic interfaces by the CLEC, results in a circumstance where a dispatch is necessary with the CLECs' concurrence, we would dispatch, and that concurrence could be given on a blanket basis for all of the troubles that would result in a dispatch on an individual basis, depending on the relationship that we've negotiated with the CLEC. MR. GUDE: Also, the other question is, have you trained or done other work with your repair personnel, to prepare them for their new roles as wholesale repairers? Is there sort of a different role for them? I think that's sort of a fundamental question for that? MS. CALHOUN: Well, I'm going to have to separate that question into the different types of folks who would be involved in repair. First of all, our Bell South repair attendants would not be, in most cases, dealing directly with a CLEC end user, because of what we just talked about. So, the folks who would actually become involved would be anybody who might need to be dispatched out and those people have been trained on their responsibilities, their obligation to provide non-discriminatory service, their obligation not to interfere in anyway with the CLECs business relationship with their customer. MR. SWAN: In Bell Atlantic's case, again, much as with Bell South, the -- if there is a need to dispatch, of course there would be a Bell Atlantic repair person at the sight of the CLEC end user. Of course, we spent some time with our repair folks to prepare them for that circumstance. We have also worked with the group of CLECs who are our customers, on leave behind material or collateral that may be necessary to show, confirm that we're there on behalf of, and although we're a Bell Atlantic employee, we're there on behalf of CLEC A, CLEC B. Of course, there's been some orientation and training of the repair folks for that eventuality. For the repair attendants, because of the need, as to receive a call from the end user, to recognize that not all of the calls that will come into the center in the wholesale arrangement will be from the Bell Atlantic end user, may, in fact, be from the CLEC end user. There has been some training and orientation required, even for the inside attendant. We had considered the velcro patch for the badge and for the trucks, but we went beyond that. MR. WELCH: Okay, i think now we have an opportunity if there's anybody in the audience who'd like to pose some questions to the panelist. Please identify yourself and direct your question to a particular panelist, if you would, please? MS. DALTON: Good afternoon, Nancy Dalton with AT&T. My question is for Mr. Swan. Mr. Swan, in your opening remarks, you reference the LMO system that's used in Bell Atlantic today for repair and maintenance capabilities for POTS services and WFA is used for your design services. If a CLEC is to create a POT service, purchasing an unbundled loop and switch port from Bell Atlantic, which of those systems will be used to provide the OSS capabilities for repair and maintenance? MR. SWAN: I may have to take -- I don't know the exact answer to that. I believe that the way that we've established with in our systems the components for the unbundled or platform service, that they would exist within the LMO system. MS. DALTON: I believe that was the case for Bell South, as well, with the TAFI capabilities, is that right? MS. CALHOUN: Yes, our TAFI system is being taught, if you will, to recognize that a recombination of unbundled elements that replicates a retail exchange service is, for all intents and purposes, a retail exchange service, or, excuse me, a resold exchange service for repair purposes. So, yes, it would appear as an exchange service and would be handled in LMOs. MS. DALTON: So, then, parities being treated from, looking at the view of like services being treated equally, POT services being treated equally amongst carriers? MS. CALHOUN: Yes. MS. DALTON: Okay, thank you. MR. SWAN: No, no, if I understand the direction of the question, the unbundled element is not directly comparable in terms of how it's put in place, how it's implemented, how it's provisioned and how it's maintained from a facilities standpoint directly to an exchange line, if you will. It's a series of unbundled elements which provide the same functionality and service as a local exchange line, but they're unbundled elements and that's the way that their provision and the way we maintain the facilities and the records. MS. CALHOUN: I would agree with that for Bell South. I would agree with that from the perspective of individual, unbundled elements, but for a recombination of unbundled elements, our TAFI system would translate that as an exchange line. MS. DALTON: I just want to make sure that I understand. If I am buying a series of elements and I'm buying them all from either of your companies and I'm purchasing them to create a POTS service, will I have the same capabilities for repair and maintenance as you each have with respect to servicing your POTS services? If I understood correctly, I'll have those capabilities through TAFI for POT services, just as Bell South provides to itself. I'm not sure, based upon the last clarification, if a CLEC would have those same POTS capabilities through LMOs, regardless of whether it's created the service through unbundled network elements or not? MR. SWAN: The distinction I was trying to make, and I apologize if I made it awkwardly, is that we view the platform again as a series of distinct, unbundled elements, which, though ordered separately, provisioned separately, provide in terms of service functionality, the same as basic local exchange service. Now, because they're ordered separately as separate Unbundled Network Elements, we provision them and maintain records and facilities on them as separate elements. They would occur within LMOs as those separate elements. The way that we would seek to complete trouble analysis and reporting may be more akin, if I could use that term, to the way we manage unbundled loops as opposed to regular POTS service. We're still working out those specific details. MS. DALTON: Thank you. MS. STROMBOTNY: I'm Tracy Strombotny with LCI. It sounds like from listening to people here that we're not alone in suffering disconnects during the provisioning process, and I'd like to know how Bell Atlantic and Bell South, how your trouble systems handle those disconnects, because in many cases, as the provisioning process is not complete, we're not the customer of record. And, so, we have a hard time getting those problems resolved, and yet our customer is out of service. So, I'd like to know how your systems handle that? MS. CALHOUN: First of all, let me make sure I understand your question. Are you talking about a customer whose exchange service is being changed to something that would involve an unbundled loop, or are you talking about a migration of a -- MS. STROMBOTNY: In assume as is resale situation. MS. CALHOUN: In assume as is resale situation? The way Bell South is provisioning an assume as is resale, the disconnect should not occur. MS. STROMBOTNY: I understand it shouldn't, but it does, so that's why I'm asking. We've encountered this problem with every ILEC that we've dealt with, Bell South included. MS. CALHOUN: Again, if it's a situation where you're assuming it as is and there's no work required, the way our processes are set up, that should not be happening. Now, if you have some other ordering scenario that's occurring that's causing that, I don't know. From a repair perspective, there is a time period following issuance of a service order, where it's a provisioning question versus a maintenance question. But, in general, there is a single point of contact set up. We have an access customer advocacy center is what it has historically been called, and there is a center assigned to support CLECs, and that would be a point of resolution, single point of resolution for troubles associated with either provisioning or repair. MS. STROMBOTNY: Is this the same, then, as would be experienced by a Bell South end customer? Is that the same group or the same service that would be provided when you were trying to assume a customer or get a customer turned up? MS. CALHOUN: In terms of whether it's considered provisioning or maintenance? MS. STROMBOTNY: Mm-hmm. MS. CALHOUN: Yes. MR. SWAN: From a Bell Atlantic standpoint on the question with the as is migration, again, no work required, no physical work required and no switchwork required, it's record exchange, and there would be no need for the service to be interrupted. In the resale migrations that we've completed to date, I'm not aware of any difficulty where we have inadvertently disconnected or disrupted any user service. MR. BRADBURY: Hi, Jay Bradbury with AT&T. Hi, Gloria. You and I have been talking about this subject since August of 1995. TAFI and EDI as they are today kind of bring each half a loaf to the table. You know, AT&T has a strong desire, just like Mr. Welborn discussed there for system integration. The EDI interfaces existent in Bell South today has the mapping there for the access circuits that are used, but if you send a local over on it, it doesn't automatically give you back anything, because it's not mapped. TAFI, on the other hand, is a human to machine interface. We talked some time ago and I've been talking with many people in Bell South about marrying those two up together, putting TAFI, if you would, behind the EDI interface, to get the advantage of the standards and all of the system's expertise that exists in TAFI. Has anything happened since last April on that? MS. CALHOUN: Bell South has provided non- discriminatory access to its TAFI system by making information and functions available to CLECs in substantially the same time and manner we have available for our retail customers. And, we've made that functionality available to AT&T in exactly the same way we have it available for ourselves. The trouble reporting gateway or the electronic bonding gateway has been available for use by our exchange carriers, such as AT&T, for the last couple of years, and when Bell South implemented that gateway, we agreed there were standards for an interface to what we call WFA, what Bell Atlantic calls WFA for design services and there were standards available for an interface to LMOs. And, our implementation agreement at that time was that we would only implement the WFA aspects of that, and we have agreed with AT&T that by December of 1997, we will go and build out the LMOs side of that electronic bonding interface, but we will do it in such a way that it meets the existing standards for the LMOs functionality in that interface. TAFI is something that, frankly, is far above and beyond what the current industry standards for trouble reporting in the access world provide for, and at this point, we have said that we have made full TAFI functionality available. We have agreed to build out the full functionality through the electronic bonding gateway that currently is supported by industry standards, and what we've not agreed to do is to replicate all of the TAFI functionality in the electronic bonding arrangement, because that would render it a non-standard interface. So, what we've done is agree to provide a totally standard interface, and to provide all of the functionality for TAFI as currently available that's sitting today, ready and waiting to be used. MR. SWAN: I can say without hesitation, that nothing has happened in Bell Atlantic on that issue. MR. WELCH: Any other questions from the audience? MR. CLUBFELD: Hank Clubfeld from SAIC. Gloria mentioned a security check, which I think is an excellent approach. I was wondering if the panel had a chance to read on the FCC's Web page, on the Office of Engineering Technology on Damrick the planning for operations support interfaces that looks at the functionality of a gateway, the need to address security, given the fact that these are sensitive operation systems that need petition to make certain that the CLEC is the right CLEC for that party, and that the bad guys don't get in looking like the CLEC. Would you care to comment on that, particularly with respect to the discussion for the particular OSSs that each of you are trying to get addressed? MS. CALHOUN: Well, I can say that Bell South has participated in the development of the document that you're talking about and that we have stayed abreast of it and consider it in our planning and development efforts. MR. SWAN: As has Bell Atlantic. In preparation for the panel periods, we spent some time in conversation with the Bell Atlantic representative from Bell Corp. on that effort. And, security has been a primary focus at each point in our electronic interfaces to OSS functions, both through the gateway and through -- although not to the, with the same approach, even with our electronic bonding initiative. We do that from a far wall standpoint, and then actually when we get to the target operating support system database, for further security checks at the individual data customer level. MR. WELCH: Well, I think that concludes this panel. I want to thank our panelists, Rod Cox, Bob Welborn, David Swan and Gloria Calhoun, for being with us. I'd like to thank all the panelists over the last two days who went out of their way to come and join us and offer their views. It helped the FCC understand the issues. I hoped it helped the people in the industry understand the issues, and I will spare you any more baseball metaphors and just say, we're done. Thank you. (Whereupon, at 1:00 p.m., the hearing was concluded.) // // // // // // // // // // // REPORTER'S CERTIFICATE FCC DOCKET NO.: N/A CASE TITLE: Common Carrier Bureau Operations Support Systems Forum HEARING DATE: May 29, 1997 LOCATION: Washington, D.C. I hereby certify that the proceedings and evidence are contained fully and accurately on the tapes and notes reported by me at the hearing in the above case before the Federal Communications Commission. Date: _05/29/97_ _____________________________ Official Reporter Heritage Reporting Corporation 1220 "L" Street, N.W. Washington, D.C. 20005 Peter Knight Shonerd TRANSCRIBER'S CERTIFICATE I hereby certify that the proceedings and evidence were fully and accurately transcribed from the tapes and notes provided by the above named reporter in the above case before the Federal Communications Commission. Date: _06/06/97_ ______________________________ Official Transcriber Heritage Reporting Corporation Diane Duke PROOFREADER'S CERTIFICATE I hereby certify that the transcript of the proceedings and evidence in the above referenced case that was held before the Federal Communications Commission was proofread on the date specified below. Date: _06/09/97_ ______________________________ Official Proofreader Heritage Reporting Corporation Don R. Jennings