Volume VII, Issue 2, Fall 2000 FROM THE BACK OFFICE TO THE FRONT LINES OSS: Potential Land Mines on the Front Lines   by Mark A. Keffer(*) Cite As: Mark A. Keffer, From the Back Office to the Front Lines OSS: Potential Land Mines on the Front Lines, 7 RICH. J.L. & TECH. 24 (Symposium 2000), athttp://www.richmond.edu/jolt/v7i2/keffer.html. TABLE OF CONTENTS I. THE INCUMBENT LOCAL EXCHANGE CARRIERS ARE OFFERING ACCESS TO THEIR OPERATIONSSUPPORT SYSTEMS BECAUSE THE LAW SAYS THEY HAVE TO, NOT BECAUSE THEY WANT TO A. Federal Statutory & Regulatory Requirements Mandating Non-Discriminatory Access to OSS B. The FCC's Two-Step Process for Evaluating OSS II. THIS OSS STUFF IS NOT EASY A. Pre-Ordering B. Ordering and Provisioning C. Maintenance and Repair D. Billing III. SO HOW DOES A REGULATOR GET THE ILECS TO PERFORM? A. Testing, Monitoring, Measurements, and Penalties 1. Testing 2. Performance Standards 3. Penalties and Remedies 4. Performance Monitoring IV. HOW ARE THINGS GOING SO FAR? IT DEPENDS ON WHOM YOU ASK . . . V. CONCLUSION: THE VIRGINIA COMMISSION IS ON THE RIGHT PATH   {1}The Telecommunications Act of 1996 struck a bargain that allowed Bell Atlantic and the other Regional Bell Operating Companies ("RBOCs") to gain entry into the long distance business by opening their monopoly local exchange markets to meaningful competition. A key aspect of the market-opening process is that the RBOCs, as well as generally all Incumbent Local Exchange Carriers ("ILECs") are required to provide new Competitive Local Exchange Carriers ("CLECs") access to the Operations Support Systems ("OSS"). The incumbents use OSS to serve their customers at quality levels equal to what the incumbent provides to itself. {2}This paper is intended to provide a general overview of what access to "OSS: really means, what is involved in making it happen, progress thus far, and how regulators can ensure adequate OSS access going forward." I. THE INCUMBENT LOCAL EXCHANGE CARRIERS ARE OFFERING ACCESS TO THEIR OPERATIONS SUPPORT SYSTEMS BECAUSE THE LAW SAYS THEY HAVE TO, NOT BECAUSE THEY WANT TO {3}To the RBOCs, OSS access is the castor oil they must stomach to get the long distance market capabilities they want. Absent the lure of the long distance market, no RBOC would willingly give its competitors access to the electronic systems and databases the RBOC uses to serve its customers. {4}Those systems have reduced telecommunications unit costs substantially. The RBOCs and other incumbent LECs are able to offer high quality service at a low cost by populating, processing, fulfilling, and servicing customer orders through the use of electronically interconnected computers, systems, and databases. {5}For the new entrants to obtain parity with the incumbent when using its services or network elements to provide local service, the new entrants need parity access to the incumbent's OSS. Recognizing this, Congress mandated that ILECs offer new carriers nondiscriminatory access to the ILECs' OSS. The FCC has spent the last four years working to implement that mandate. A. Federal Statutory & Regulatory Requirements Mandating Non-Discriminatory Access to OSS {6}The Telecommunications Act of 1996 obligates ILECs to provide CLECs with both the interconnection with the local exchange carrier's network, as well as unbundled access to the ILEC's network elements under terms and conditions that are just, reasonable and nondiscriminatory. [1] The FCC first gave life to this provision in its massive August 8, 1996, Local Competition Order,[2] where it is stated: Much of the information maintained by these systems is critical to the ability of other carriers to compete with incumbent LECs using unbundled network elements or resold services. Without access to review, inter alia, available telephone numbers, service interval information, and maintenance histories, competing carriers would operate at a significant disadvantage with respect to the incumbent. Other information, such as the facilities and services assigned to a particular customer, is necessary to a competing carrier's ability to provision and offer competing services to incumbent LEC customers. Finally, if competing carriers are unable to perform the functions of pre-ordering, ordering, provisioning, maintenance and repair, and billing for network elements and resale services in substantially the same time and manner that an incumbent can for itself, competing carriers will be severely disadvantaged, if not precluded altogether, from fairly competing. Thus providing nondiscriminatory access to these support systems functions, which would include access to the information such systems contain, is vital to creating opportunities for meaningful competition.[3] The FCC has maintained this view of OSS access, most recently affirming it in its December 1999 decision to allow Bell Atlantic - New York into the long distance market. [4] {7}In a line of prior decisions rejecting RBOC requests to enter long distance, the FCC had defined what it means for ILECs to provide CLECs with nondiscriminatory access to their OSS. [5] In those orders, culminating with the recent New York order, the FCC has consistently stated that new entrants must have access to the functions performed by the incumbent's OSS. These functions include populating and placing orders for network elements or resale services, installing service to their customers, maintaining and repairing network facilities, and billing customers. [6] The FCC has been constant in its view that, absent nondiscriminatory access to the ILEC's OSS, a competing carrier "will be severely disadvantaged, if not precluded altogether, from fairly cooperating" in the local exchange market. [7] {8}As a result of these decisions, the meaning of "nondiscriminatory access" is important to RBOCs requesting access to new markets. An ILEC "must provide access that sufficiently supports each of the three modes of competitive entry envisioned by the 1996 Act - competitor-owned facilities, unbundled network elements, and resale." [8] In addition, "for OSS functions that are analogous to those that an ILEC provides to itself, its customers or its affiliates, the ILEC must offer requesting carriers access that is equivalent in terms of quality, accuracy, and timeliness." [9] The ILEC must provide access that permits competing carriers to perform these functions in "substantially the same time and manner" as the ILEC: [10] For example, we [the FCC] would not deem an incumbent LEC to be providing nondiscriminatory access to OSS if limitations on the processing of information between the interface and the back office systems prevented a competitor from performing a specific function in substantially the same time and manner as the incumbent performs that function for itself. [11] {9}For OSS functions with no retail analog, the FCC has held that "the BOC must offer access 'sufficient to allow an efficient competitor a meaningful opportunity to compete.'" [12] Here the FCC considers "whether appropriate standards for measuring OSS performance have been adopted by the relevant state commission or agreed upon by the BOC in an interconnection agreement or during the implementation of such an agreement." [13] Assuming that there are such performance standards, the FCC then evaluates whether the BOC's performance is sufficient to allow "an efficient competitor a meaningful opportunity to compete." [14] {10}A simple example helps illustrate the need for OSS parity. Today, customers ordering new telephone service typically can obtain the telephone number they will be assigned during the initial call with the ILEC customer service representative. Similarly, ILEC customers generally can schedule a repair appointment in the same conversation in which they report a service problem. Nondiscriminatory OSS access means that CLECs engaged in resale or UNE competition must have the same ability to interface with the ILEC systems in "real time," so that their customers can get the information just as quickly. B. The FCC's Two-Step Process for Evaluating OSS {11}The FCC uses a two-step approach to evaluate OSS nondiscrimination. First, the FCC determines, for each of the five broad categories of OSS functions (pre-ordering, ordering, provisioning, maintenance and repair, and billing) "whether the BOC has deployed the necessary systems and personnel to provide sufficient access to each of the necessary OSS functions and whether the BOC is adequately assisting competing carriers to understand how to implement and use all the OSS functions available to them." [15] Second, the FCC assesses "whether the OSS functions that the BOC has deployed are operationally ready, as a practical matter." [16] {12}Under the first inquiry, the ILEC must demonstrate development of sufficient electronic and manual interfaces to allow competing carriers equivalent access to all of the necessary OSS functions. [17] The ILEC must give CLECs the specifications needed to design or modify their systems to enable CLECs to communicate with the ILEC's systems and any relevant interfaces. [18] The ILEC must also disclose to CLECs any internal business rules and other formatting information necessary to ensure that carriers' requests and orders are processed efficiently. [19] Finally, an ILEC's OSS must be designed to accommodate both current demand and projected demand for competing carriers' access to OSS function. [20] {13}If those conditions are met, the FCC next examines "performance measurements and other evidence of commercial readiness to ascertain whether the BOC's OSS is handling current demand and will be able to handle reasonably foreseeable demand volumes." [21] It is important here to emphasize the FCC's belief that "actual commercial usage" provides the best evidence as to whether OSS functions are operationally ready. [22] Without commercial usage information, the FCC would be forced to rely on test results in assessing the commercial readiness of an ILEC's OSS. [23] As experience has shown, however, testing alone may not be sufficient to measure actual OSS readiness. II. THIS OSS STUFF IS NOT EASY {14}If the law seems complicated, the actual implementation is even more tangled. The term Operations Support Systems has risen to a term of telecommunications art, used to describe the systems, procedures, methods, requirements, and level of service that incumbent carriers use to establish and maintain services to their CLEC wholesale customers. The range of activities swept under the "OSS" moniker is both expansive and deep. {15}The term OSS covers a multitude of functions the ILEC is required to make available: pre-ordering, ordering, provisioning, maintenance and repair, and billing. Each of these functions is an essential part of the process of providing local exchange services to a customer. Each carrier, whether an ILEC or a CLEC, has systems and procedures in place that support these functions. {16}If customers are to order service from the CLEC and have it timely provisioned and properly maintained and billed, the OSS of the ILEC and the OSS of the CLEC must be able to "talk" to each other with respect to each of these basic functions. The trick - and it is not easy - is to develop and deploy automated interfaces that offer fast, reliable, and seamless communication between the ILEC and the CLEC under all reasonably foreseeable commercial circumstances. This assures that neither the ILEC nor the CLEC drops the ball and causes customer inconvenience, or worse, actual service outages. If that communication is flawed for whatever reason, then the service and the CLEC suffers because customers will blame the CLEC, even if the problem is at the ILEC end of the relationship. A. Pre-Ordering {17}Before placing an order for a service, a CLEC must have access to certain pre-ordering information so that it can actually place an order that is responsive to customers' demands. That information consists of the customer's name, address, telephone number(s), services provided (for example, vertical features such as Call Waiting), and the pre-subscribed interexchange carrier for both interLATA and intraLATA calling. Also, the CLEC must be able to determine what features, functions and long distance carriers are available, to select and reserve telephone numbers, to validate addresses and existing directory listing(s), and to establish a due date for the fulfillment of the customer's order. Finally, the CLEC must be able to check the status of the order at any time. {18}The OSS interface to the multiple Bell Atlantic systems that support these functions can be either an essentially manual web-based graphical user interface ("web-GUI") or an automated application-to-application Electronic Data Interchange ("EDI"). The transaction first goes to a Bell Atlantic "gateway" system (Bell Atlantic-South has four different ones for the pre-ordering functions, depending upon which functions are involved) that then interacts with the appropriate back-end OSS to provide the necessary information and functionality. Here again, to meet the requirements of the Act, the pre-ordering process for CLEC representatives must be at parity with what is available to the Bell Atlantic representatives. B. Ordering and Provisioning {19}To place an order, the CLEC submits a Local Service Request ("LSR") or an Access Service Request ("ASR") to Bell Atlantic either through a web-GUI or an EDI interface. If the order flows through without manual intervention (by no means a given), as AT&T and other CLECs have learned, it is processed by a system Bell Atlantic calls the "Request Broker." It checks the completeness, formatting, and validity of certain information, and rejects the LSRs or ASRs with errors back to the CLEC. If the LSR/ASR passes, it is forwarded to other systems that perform further checks, generate a service order to provision the request, and return a confirmation to the CLEC over the same interface used to submit the LSR/ASR. The provisioning process requires the coordination of multiple tasks involving multiple Bell Atlantic back-end provisioning systems. If an LSR/ASR does not flow through, it is sent to a Telecom Industry Services Operation Center ("TISOC") such as the one in Silver Spring, Maryland, for manual processing. The Bell Atlantic ordering and provisioning OSS are also supposed to provide the CLEC with notice that the order has been completed and allow the CLEC to check the status of a pending order electronically. C. Maintenance and Repair {20}CLEC access to the Bell Atlantic maintenance and repair systems is currently available only through a web-GUI interface. For a high volume CLEC, this type of access is slow, difficult to administer, and expensive. Hopefully, Bell Atlantic will soon be able to implement an acceptable application-to-application interface (so-called "electronic bonding") that will facilitate volume transactions. The CLEC's point of contact for maintenance and repair inquiries and requests is a Bell Atlantic system called the Repair Trouble Administration System ("RETAS"). This system sends trouble inquiries and requests for service to various back-end systems that perform testing and analysis and track maintenance and repair activities. RETAS also return responses to the CLEC requests. D. Billing {21}The CLEC requires usage billing information to properly and accurately bill its customers. Bell Atlantic provides this information using existing systems to deliver a daily usage file either electronically or on tape. The principle Bell Atlantic systems supporting the billing functions are the Customer Record Information System ("CRIS") and the Carrier Access Billing System ("CABS"). CRIS provides billing for retail and resale services as well as some UNEs, such as unbundled loops. CABS provides billing for transport and other wholesale functions, as well as other UNEs such as interoffice facilities and collocation. {22}The ILEC's OSS must support each of the various services and functions CLECs may want to order. Some CLECs may function as resellers of the ILECs' existing retail services. Some will want to purchase one or more Unbundled Network Elements ("UNEs"), such as the local loop, or switching, or some other functionality. Some will want a full combination of UNEs (the so-called UNE-Platform) that will enable the CLEC to provide service using the same network elements that are in place for a customer today. Other CLECs may want enhanced extended links (EELs) that combine the local loop with transport facilities that enable a CLEC to serve customers over a broad geographic area using a centrally located switch. Still other CLECs will want to engage in line sharing, where they provide data services on the higher frequency portion of the local loop while the ILEC or another CLEC provides voice service on the lower frequency portion. Given the market's natural tendency to innovate and differentiate, it is highly probable that CLECs will brew their own interesting service mixes using the ILEC's various piece-parts coupled with some of their own. The ILEC's OSS must be up to the task. {23}An additional OSS complexity is that CLECs will want to submit their orders in various ways. Some may be content to place manual orders (e.g., by faxing the order to the ILEC). Some may be content to place orders through the equivalent of an e-mail ordering system, similar to what consumers use to purchase products via the internet. In OSS parlance, this type of ordering is through the Web Graphical User Interface, or Web GUI. Other CLECs, and certainly the larger ones, will submit orders through application-to-application links they establish with the ILEC. Under this approach, the CLEC's ordering systems are linked into the ILEC system so that orders and information flow electronically back and forth between the two carriers without need for human intervention. {24}Adequate OSS also requires that the CLECs understand what is required of them to interface with the ILEC. This in itself is a multi-faced and complex proposition. To begin with, the ILEC needs to establish systems, processes and other operational elements that will enable the CLECs to establish and maintain business relationships with the ILECs. Has the ILEC published information sufficiently detailed to enable a CLEC to understand what is required to do business with the ILEC? Does the ILEC provide adequate support personnel to handle CLEC inquiries and problems? Has the ILEC implemented adequate change management procedures so that updates to its systems and processes are communicated to the CLEC community effectively and then implemented in an orderly, logical, business-friendly manner? Does the ILEC offer adequate training to the CLECs on ILEC systems and procedures? Each of these must be present for a CLEC to implement a relationship with the ILEC. III. SO HOW DOES A REGULATOR GET THE ILECS TO PERFORM? A. Testing, Monitoring, Measurements, and Penalties {25}OSS provisioning is an unnatural act. Absent other incentives, no firm would want to provide its competitors with the same access to its systems and customer information that it provides to itself. If left unchecked, an ILEC will find ways to discriminate in favor of its own services. This means, simply, that it is left to the regulators to ensure that ILECs step up to their OSS obligations. The tools at the regulators' disposal are familiar ones: (1) testing to ensure that systems work as intended; (2) performance standards that identify expected levels of ILEC OSS performance; (3) ongoing monitoring of OSS performance; and (4) penalties for nonperformance. Each of these areas has been, and will continue to be, the topic of considerable regulatory debate. 1. Testing {26}It is now clear that an ILEC's OSS cannot be deemed compliant with the Telecommunications Act until the ILEC passes an independent third party test. In states where Bell Atlantic serves, all such tests are being performed by KPMG Peat Marwick. The extent of this testing is as broad as the OSS obligations themselves and extends to every aspect of Bell Atlantic's OSS development and performance. {27}The draft "Master Test Plan" currently under review in Virginia, for example, includes nineteen separate tests of the procedures and processes Bell Atlantic uses to implement its OSS, and ten separate tests of the manner in which Bell Atlantic handles OSS transactions. For "pre-order" functions, the test will examine whether the CLECs are able to access Bell Atlantic's systems in order to (a) Obtain Customer Service Records; (b) validate the customer's address; (c) reserve and release telephone numbers; (d) perform directory listing inquiries; (e) inquire about feature and service availability; (f) determine if the customer's loop qualifies for ISDN; (g) determine if the customer loop is xDSL capable; (h) determine whether Bell Atlantic can meet the requested customer service use data; (i) inquire about the status of the customer installation; and (j) inquire about the status of service orders. {28}With regard to a typical UNE-P order, KPMG will test Bell Atlantic's systems to determine whether Bell Atlantic's OSS can (1) migrate a customer from Bell Atlantic "as is;" (2) implement feature changes for an existing customer; (3) migrate an existing customer and, at the same time, implement changes in the customer's service package; (4) process an order for a new customer; (5) change a customer's telephone number; (6) change a customer's directory listing; (7) add lines to a customer's existing service arrangement; (8) suspend and restore a customer's service; (9) disconnect a customer's service; (10) process a customer's move to a different location; (11) convert a line to ISDN; (12) move a customer from the CLEC to Bell Atlantic; and (13) convert a customer arrangement from a resale arrangement to a UNE-P arrangement. {29}In general terms, the transaction testing will occur in two phases. First, KPMG tests whether Bell Atlantic's systems are able to process the transaction. If Bell Atlantic passes, KPMG will next test whether Bell Atlantic is able to process the transaction at expected commercial volumes and, importantly, at peak (or "stress") volumes, which would be up to 250% of normal volumes. {30}This is only a broad overview of the scope and types of testing required to examine Bell Atlantic's OSS. The full test parameters extend to all aspects of Bell Atlantic's OSS functions. The KPMG draft Master Test Plan for Virginia is well over 100 pages and still is not quite complete in AT&T's view. {31}The OSS testing is occurring in a highly dynamic environment. New regulatory decisions keep changing the types and scope of services Bell Atlantic and the other ILECs must make available to competitors. These new services must be added to the ILECs' OSS and, if not already included in an OSS test, must also be added to the OSS test scenarios. {32}Furthermore, the systems that ILECs are using to provide OSS are themselves subject to update and modification, either because (hopefully) better systems become available, or because the old systems prove to be inadequate to the task. As those changes occur, it is equally important that the new systems be subjected to thorough testing as well. This is not always a trivial, or popular, matter. If, for example, a state commission is well down the road to testing a system or process when a new one is implemented, the state may be reluctant to retreat and undertake the additional work required to incorporate the new systems/processes in the test. It is hard to imagine, however, any instance where it would be appropriate to test systems/processes that a state knows will not be put to commercial use (or will be used only sparingly for a short duration) if the state is serious about conducting a full-fledged OSS test. 2. Performance Standards {33}In order for OSSs to be functional in the commercial environment, CLECs must be able to access the ILECs OSS in the same manner - at parity - as the ILEC itself. Disparity in OSS access between the CLECs and the ILEC's retail operations means that the ILEC has not met the requirements of the Act to provide nondiscriminatory access to UNEs, interconnection and resold services to wholesale customers. {34}The service quality metrics identify the data on OSS access that needs to be collected and quantified in order to determine whether parity of access is achieved. The purpose of performance measurements and standards is to provide the objective, empirical evidence necessary to permit the SCC and the CLECs to determine: (1) whether the ILEC is providing parity of access to its services according to the Act; and (2) whether the ILEC's performance is nondiscriminatory. 3. Penalties and Remedies {35}The purpose of an effective remedies plan is to provide a meaningful deterrent to anti-competitive behavior by the RBOC. The "carrot" of entering the long distance market is a powerful incentive, but once the RBOC is in the long distance market it will have equally strong incentives to backslide on OSS performance. Such discriminatory behavior would have a devastating impact on competitors and competitions. Only a remedies plan with teeth will provide the necessary deterrent to anti-competitive behavior. {36}For a remedies plan to be effective, it must: * Provide direct and unambiguous consequences for discriminatory performance by the ILEC; * Provide dollar remedies that are self-executing and immediate; * Be rooted in an established, comprehensive and verified performance measurement system; * Have specific non-monetary consequences for chronic violations or backsliding (e.g., provision for the new LD customers in the event that the ILEC's performance reaches a predetermined threshold level of discrimination on certain key performance measurements). 4. Performance Monitoring {37}Generally, regulators will monitor ILEC OSS performance in two ways. First, they will receive, review, and, hopefully, probe the performance quality reports generated by the ILECs to ensure that the ILEC is reporting accurately and that the report meets the regulator's requirements. Second, the regulator will be asked to resolve CLEC complaints alleging poor OSS performance. It is vital to the development of competition that these CLEC complaints be resolved quickly. CLECs, particularly the small ones, simply cannot afford to engage in protracted regulatory battles over whether an ILEC is processing its orders as it should. IV. HOW ARE THINGS GOING SO FAR? IT DEPENDS ON WHOM YOU ASK . . . {38}To date, the only experience with volume OSS transactions comes from New York. There, in late 1999, the P.C. and FCC found the performance of Bell Atlantic's OSS adequate to allow Bell Atlantic to enter the long distance market. {39}This move was a bit premature. Almost immediately it became all too apparent that Bell Atlantic-New York's OSS could not keep up with CLEC commercial demand. In December and January, AT&T had more than 25,000 of its UNE-P orders lost in Bell Atlantic-New York's systems. AT&T had to open trouble tickets with Bell Atlantic for over 40% of the orders AT&T placed in January. Even one dissatisfied customer is one too many. AT&T had tens of thousands. Moreover, AT&T was not alone. Other carriers faced similar problems. {40}At this point, Bell Atlantic claims to have resolved the issue, but not before the New York P.C. directed Bell Atlantic to credit ten million dollars ($10,000,000) to its CLEC customers and the FCC noted that Bell Atlantic would be making a three million dollar ($3,000,000) "contribution" to the United States Treasury. But as one CLEC representative noted, no amount of Bell Atlantic refunds can repair CLEC's damaged relationship with customers whose orders were lost. {41}The New York experience offers three regulatory lessons. First, it is important to test an RBOC's OSS thoroughly with a military-style test conducted by an independent third party. Second, even a third party test may not uncover all shortcomings in an ILEC's OSS. It is vitally important that, on the heels of a successful third party test, a state commission establish a commercial availability period where New York type problems can be unearthed and, hopefully, resolved before CLECs begin full-scale operations. Third, it is equally important to implement strong performance measurements, backed by correspondingly strong penalties for nonperformance, to ensure that the ILEC has adequate incentives to meet its OSS obligations. V. CONCLUSION: THE VIRGINIA COMMISSION IS ON THE RIGHT PATH {42}The Virginia Commission is to be commended for its approach to OSS testing. It has retained KPMG to conduct a thorough, military-style test of Bell Atlantic - Virginia's OSS. It has appointed an administrator to oversee the testing process from start to finish. It has made clear that Bell Atlantic will not be given a "pass" until the Commission is satisfied that Bell Atlantic's OSS performs as advertised. {43}There are still plenty of land mines out there, but Virginia has not hit any so far. . . ENDNOTES [*] Mark A. Keffer is currently Chief Regulatory Counsel for AT&T's Atlantic Region, responsible for AT&T's legal representation before state public utility commissions in Virginia, West Virginia, Pennsylvania, Delaware, Maryland, and the District of Columbia. Mark joined AT&T in November, 1983. Prior to that he was a Staff Attorney with the West Virginia Public Service Commission following his January, 1980, graduation from the West Virginia University College of Law. Since coming to AT&T, Mark has held several positions of increasing responsibility in the regional Law and Government Affairs group, and was appointed to his current position in February, 1996. [1] . See Telecommunications Act of 1996, 47 U.S.C.  251(c)(2)(d) and (3) (2000). The full text of these statutory provisions is as follows: (2) INTERCONNECTION - The duty to provide, for the facilities and equipment of any requesting telecommunications carrier, interconnection with the local exchange carrier's network (d) on rates, terms, and conditions that are just, reasonable, and nondiscriminatory, in accordance with the terms and conditions of the agreement and the requirements of this section and section 252. (3) UNBUNDLED ACCESS - The duty to provide, to any requesting telecommunications carrier for the provision of a telecommunications service, nondiscriminatory access to network elements on an unbundled basis at any technically feasible point on rates, terms, and conditions that are just, reasonable, and nondiscriminatory in accordance with the terms and conditions of the agreement and the requirements of this section and section 252. An incumbent local exchange carrier shall provide such unbundled network elements in a manner that allows requesting carriers to combine such elements in order to provide such telecommunications service. Id. [2] . In re Implementation of the Local Competition Provisions of the Telecommunications Act of 1996; Interconnection between Local Exchange Carriers and Commercial Mobile Radio Service Providers, 11 F.C.C.R. 15499 (1996) [hereinafter FCC Local Competition Order]. [3] . Id. at 15763-64 (emphasis added). [4] . In re Application by Bell Atlantic New York for Authorization Under Section 271 of the Communications Act to Provide In-Region, InterLATA Service in the State of New York, 15 F.C.C.R. 3953, 3989 (1999) [hereinafter BA-NY 271 Approval Order]. [5] . See In re Application of BellSouth Telecommunications, Inc. and BellSouth Long Distance, Inc. for Provision of In-Region, InterLATA Services in Louisiana, 13 F.C.C.R. 20599 (1998) [hereinafter Second La. Order]; In re Application of BellSouth Corp. et. al. Pursuant to Section 271 of the Communications Act of 1934, as Amended to Provide In-Region, InterLATA Services, Inc. in South Carolina, 13 F.C.C.R. 539 (1997) [hereinafter S.C. Order]; In re Application of Ameritech Michigan Pursuant to Section 271 of the Communications Act of 1934, as Amended, to Provide In-Region, InterLATA Services in Michigan, 12 F.C.C.R. 20543 (1997) [hereinafter Ameritech Michigan Order]. See Press Release, Federal Communications Commission, Common Carrier; Federal Communications Commission Authorizes Bell Atlantic To Provide Long Distance Service in New York (Dec. 22, 1999), available at 1991 FCC LEXIS 5490. [6] . See Second La. Order, 13 F.C.C.R. 20599, 20653 91998); see also S.C. Order,13 F.C.C.R. 539, 547-48 (1997); Ameritech Michigan Order, 12 F.C.C.R. 20543, 20613 (1997). [7] . BA-NY 271 Approval Order, 15 F.C.C.R. at 3989, (citing S.C. Order, 13 F.C.C.R. 539 (1997)); see also Ameritech Michigan Order, 12 F.C.C.R. at 20613. [8] . BA-NY 271 Approval Order, 15 F.C.C.R. at 3989 (citing S.C. Order, 13 F.C.C.R. 539 (1997)); see also Ameritech Michigan Order, 12 F.C.C.R. at 20615, 20627. [9] . BA-NY 271 Approval Order, 15 F.C.C.R. at 3989; see also Ameritech Michigan Order, 12 F.C.C.R. at 20618-19. [10] . BA-NY 271 Approval Order, 15 F.C.C.R. at 3989. [11] . BA-NY 271 Approval Order, 15 F.C.C.R. 3953, 3991 n.206 (citing Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). [12] . Id. at 3991 (citing Second La. Order, 13 F.C.C.R.20599 (1998)). See also S.C. Order, 13 F.C.C.R. at 594; Ameritech Michigan Order, 12 F.C.C.R. at 20619. [13] . BA-NY 271 Approval Order, 15 F.C.C.R. at 3991. On this point, the FCC specifically found that, "[a]s a general proposition, specific performance standards adopted by a state commission in an arbitration decision would be more persuasive evidence of commercial reasonableness than a standard unilaterally adopted by the BOC outside of its interconnection agreement." Id. [14] . Id. [15] . Id. (citing Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). See alsoSecond La. Order, 13 F.C.C.R. at 20654; S.C. Order, 13 F.C.C.R. at 592-93. [16] . Id. (citing Second La. Order, 13 F.C.C.R. 20599 (1998), S.C. Order, 13 F.C.C.R. 539 (1997), Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). [17] . BA-NY 271 Approval Order, 15 F.C.C.R. 3953, 3992 (1999)(citing Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). The ILEC must demonstrate that it has developed electronic interfaces for activities which it performs electronically. Id. [18] . See id. at 3992; see also Second La. Order, 13 F.C.C.R. 20599, 20662 (1998); S.C. Order, 13 F.C.C.R. 539, 628 (1997); Ameritech Michigan Order, 12 F.C.C.R. 20543, 20617 (1997). [19] . See id. (citing Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). [20] . See id. (citing Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). While the FCC as not required the use of industry standards to meet CLEC needs, the FCC encourages it. See BA-NY 271 Approval Order, 15 F.C.C.R. 3953, 3993 (1999) (citing Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). [21] . See id. at 3993. See also S.C. Order, 13 F.C.C.R. 539, 593 (1997); Ameritech Michigan Order, 12 F.C.C.R. 20543, 20618 (1997). [22] . See id. (citing Second L.A. Order, 13 F.C.C.R. 20599 (1998), S.C. Order, 13 F.C.C.R. 539 (1997), Ameritech Michigan Order, 12 F.C.C.R. 20543 (1997)). [23] . See id. Return to this Issue's Index Return to The Journal's Home Page       © Copyright 2000 Richmond Journal of Law & Technology