VIII. Proposed Revisions to Existing ILEC Processes to Provide Seamless Transition for Migrating Customers (47 C.F.R. § 51.319(d)(2)(ii)(A)(2))

A. Mechanization of Manual Processes

Even if SBC and Verizon workforces were increased in an attempt to accommodate increased hot cut demand, their proposed hot cut process retains the largely manual tasks that currently exist. MCI and AT&T argue, however, that mechanization, or the minimization of human intervention, is critical to increasing reliability and scalability, decreasing provisioning intervals, and reducing resultant costs of the hot cut process.⁷⁰ MCI argues that, if done correctly, little or no manual intervention is required to move a customer from one carrier's service to another. The ILECs' processes for migrating UNE-P and ILEC retail customers from one carrier to another are highly mechanized,⁷¹ with a very short provisioning interval and a successful competitive platform.⁷² Thus, if a hot cut process is ever to be achieved that is anywhere near as seamless, accurate, timely and inexpensive as UNE-P or retail service provisioning, MCI argues, it must incorporate the highest degree of mechanization possible in existing manual processes.

MCI argues that SBC and Verizon must give CLECs access to the same OSS, databases and information that is available to the ILECs in order to produce a seamless, low-cost, and efficient hot cut process capable of handling the timely transfer of large volumes of mass market customers among carriers. MCI argues that SBC and Verizon must mechanize current OSS processes to support the dramatically increased volumes of hot cuts that will occur if CLECs lose access to UNE switching. With the current manual processing of hot cuts, three-way conferencing is required on the day of the cut between the CLEC, the ILEC frame technician, and the ILEC provisioning agent. The transfer of the customer's loop from one carrier's switch to another relies upon numerous mechanical OSS processes. CLECs' UNE access to OSS includes systems, databases, information (including loop qualification information) and personnel that the ILECs use to provide five OSS functions: pre-ordering, ordering, provisioning, maintenance and repair, and billing.⁷³

Further, MCI argues that SBC and Verizon must give CLECs access to loop plant information that could prevent the timely migration of a customer to the CLECs' switch (e.g., presence of IDLC) and must provide a robust system and process for managing the ordering and provisioning of very high volumes of hot cuts.

AT&T proposes that SBC be provided incentives to pursue network upgrades to enable it to provision loops electronically, known as "Electronic Loop Provisioning" (ELP). SBC witness Mitchell stated that SBC has not yet "delved into [the possibility of utilizing ELP] all that deeply because the FCC said that that would be something that we would implement if there were insufficient batch cut processes. And that hasn't been determined."⁷⁴ SBC is, however, participating with Telcordia on mechanized frames.⁷⁵

We recognize that ELP is not a currently feasible technology, and will not require that it be implemented as part of the currently pending batch cut proposal. However, SBC should continue to explore the feasibility of ELP as a means of making the hot cut process more efficient in the future. We expect SBC to keep the Commission and its staff apprised of progress toward the development of ELP technology.

The SBC panel testified that its OSS upgrades promised as part of the BHC are being independently developed by SBC for a July 24, 2004, release.⁷⁶ SBC argues that this timing is necessary due to the fact that OSS changes follow the 13-state change-management process. AT&T faults this approach, arguing that the CLECs have no way of determining whether the OSS upgrades will provide sufficient enhancements to implement the BHC process, and the Commission will have no opportunity to oversee or adjudicate the planned upgrades.

We agree that SBC should report to the Commission its progress in implementing the planned upgrades to its OSS. We direct the ALJ to schedule a workshop process for SBC to provide progress reports on its OSS upgrades, and to provide an opportunity for CLEC input into the adequacy of those upgrades in producing a "seamless" batch hot cut process.

Verizon's panel witnesses stated that additional OSS support for the new aspects of its proposed batch hot cut process was not yet completed, but was expected to be available "by the end of the nine month proceeding."⁷⁷ Yet, by the close of the record, Verizon had not yet provided any proposal as to such OSS revisions. The CLECs claimed that Verizon East's OSS have been more extensively detailed compared to Verizon West.⁷⁸ In response to an ALJ ruling, Verizon provided additional information concerning the Verizon West OSS. Verizon claims that while the western system is different, it is just as robust as the eastern system, and provides CLECs with a meaningful opportunity to compete.

Verizon concedes, however, that at present, CLEC orders to convert a UNE-P arrangement to UNE-L are processed manually, and do not "flow through"⁷⁹ Verizon West's OSS. Given the relatively small volumes involved at present, Verizon considers it more cost effective to continue processing such orders manually. Verizon states that if UNE-P is no longer available, issues relating to mass migrations of CLECs from UNE-P to UNE-L arrangements will be addressed as part of a "transition plan." ⁸⁰ We note, however, that this is the proceeding where the batch cut process was to be approved and implemented.

The lack of details concerning a plan to develop a flow-through ordering process for migrating UNE-P lines to UNE-L increases the risk that Verizon would not be equipped to handle the increased volumes of hot cuts with the elimination of UNE-P. AT&T witness Falcone testified that Verizon's flow-through rate for UNE loop orders received electronically (both UNE-P and UNE-L) ran from a low of 63.67% to 77.31% from June to October 2003. AT&T argues that this rate of flow-through is not sufficient to sustain commercial volumes in a UNE-L environment where loop migrations involve more complex activity.

Therefore, we find Verizon's batch cut proposal to be incomplete to the extent it contemplates some yet-to-instituted future proceeding as the place where implementation of a "transition plan" will actually be addressed. We cannot approve Verizon's proposed batch cut process without further explanation concerning how it contemplates such a transition plan being implemented. As part of the workshop process outlined above with respect to SBC, we likewise direct the ALJ to schedule a process for the development and implementation of a "transition process" for Verizon OSS upgrades to provide for flow through of its batch cut process.

B. 911 Database Coordination Issues Require Resolution

Another coordination issue in connection with hot cuts relates to the E-911 database which is used to identify emergency calling locations. When a customer migrates from one carrier's switch to another's (either ILEC or CLEC), the 911 database must be updated to reflect the new switching provider. If this change is not made correctly, the customer's 911 information in the "Automatic Line Identification" (ALI) database will not include the CLEC's ID or the customer's correct address if the customer has moved or the record required some other correction. Neither SBC nor Verizon has provided evidence that there is a process in place to seamlessly and accurately handle 911 database changes 100 percent of the time. Given the critical nature of 911 service, nothing less is acceptable for customer satisfaction and public health and safety. In order to approve the batch cut process, 911 database changes should be fully coordinated so that the 911 database can handle the volume of changes necessary in a UNE-L world, where every customer migration requires such a change. Otherwise, the Commission cannot ensure that customers will enjoy the seamless, timely and accurate migration process mandated by the TRO.

In a UNE-L environment, two orders are required for changes to the 911 ALI database.⁸¹ One order must go from the ILEC to the 911 provider to unlock the record in the ALI database.⁸² This allows the CLEC to overlay the existing record with the updated 911 record once the migration has been successfully processed. The second order must go through the CLEC's vendor (or the ILEC if the CLEC has contracted with them) to overlay the existing 911 record with the new record.⁸³ These orders must be coordinated so that the ILEC unlock order arrives before the CLEC "Migrate" order to newly populate the database.

While SBC has stated that it will send the "unlock" transaction to the NPAC when the lift and lay is complete and the order is completed, it has not provided sufficient details regarding this process and how the CLEC will be notified.⁸⁴ For business customers using UNE-L, at least, many ILECs do not send the "unlock" order until the CLECs migration order has actually closed in the ILEC billing system.⁸⁵ Since this will necessarily be sometime after the physical completion of the order, there could be a time lag where the 911 system has incorrect information on the network service provider.⁸⁶ The National Network Numbering Association (NENA) standard is to send the 911 order at the time of port.

This discrepancy between the ILEC and CLEC processes could cause a customer lead to serious problems. While the customer will be able to dial 911, the Public Safety Answering Position (PSAP) will only see the old customer record, which may or may not be accurate and will contain the wrong company ID for correction or trap and trace requests.⁸⁷ As the number of UNE-L orders increases and particularly during the bulk transition of customers from UNE-P to UNE-L, the problem will become more severe.⁸⁸ Further, the CLEC will be required to manually check the PSAP information for every hot cut order to determine if the update has been accepted and has passed the myriad of required edits.⁸⁹

We agree that ILEC systems should be revised so as to send the 911 record at the time of porting. This change would improve the timeliness of the 911 record process and help ensure that accurate customer information is in the 911 database. In order to avoid any problems with the critical emergency 911 services for customers during hot cut migrations, we shall require the ILECs to comport with the NENA guidelines and send the 911 order at the time the customer's telephone number is ported, oversee the development of a standard process to coordinate 911 database changes and ensure that the PSAP data base can handle the increased volume of unlock and lock requests that will arise in a UNE-L environment. We direct the ILECs to revise their processes to accommodate this revision.

C. Number Portability Coordination Issues Require Resolution

When a customer's loop is migrated from the ILEC switch to the CLEC switch, a transaction is sent to the NPAC which handles the necessary number porting to identify the "home switch" to which calls should be terminated for each UNE-L (and cable) customer.⁹⁰ In a hot cut from UNE-P to UNE-L, the ILEC would initiate this transaction by creating a "10 digit trigger" in the donor (losing) switch when the UNE-L order is created.⁹¹ The trigger will cause incoming calls to "dip" into the NPAC database to determine the switch that now houses the number. Upon notification that the cut has been completed, the CLEC sends a transaction to NPAC to claim the number. Until the CLEC claims the number in the NPAC database, the customer cannot receive incoming telephone calls.⁹² If the NPAC transaction is not completed successfully, the customer will not be able to receive calls, and the customer's voice mail will not operate, since calls will be misdirected to the incorrect home switch.⁹³ Thus, the NPAC process must be coordinated and successful.

When the customer changes carriers again, the losing carrier must "unlock" the existing record to allow the winning carrier to "replace" it with its destination code. Both churn and the addition of wireless local number portability will raise the number of transactions processed by the NPAC .⁹⁴ It is questionable whether the NPAC can handle the volumes of transactions that would occur in a dynamic UNE-L market. ⁹⁵

We shall adopt MCI's recommendation that the Commission immediately open a collaborative discussion between the ILEC, CLECs, and the current NPAC administrator, Neustar, to determine NPAC's actual capabilities and to develop metrics for the completion of number portability tasks.⁹⁶ Volume testing or scalability analysis will also be required to determine whether NPAC can actually handle the volumes of numbers that will be ported in a single day. Since a failure of the NPAC system will have a serious negative impact on customers, it is critical that the Commission not withdraw CLEC access to UNE switching until it is clear that a foolproof system is in place to handle the volumes of number porting that will arise in a UNE-L world.

D. Directory Listing Issues Require Resolution

When customers are served on UNE loops, the serving CLEC must send directory listing information to the ILEC for inclusion in both the printed and on-line directories of each company.⁹⁷ This step occurs as part of the UNE-L migration order, but is not required for UNE-P to UNE-P migrations. In order to carry out a directory listing change, the CLEC completes a directory listing form and sends it with its order to the ILEC for processing. While an "as is" (i.e., no change) directory listing can be ordered from the ILEC as part of the "first" retail to UNE-L migration (or UNE-P to UNE-L conversion), this process must be repeated with full information for each subsequent change.⁹⁸ This increases the likelihood of errors or deletions in the directory as it is "opened" to remove listings and "closed" to put the same listings back in.⁹⁹ During the state 271 proceedings, UNE-L carriers at the time presented evidence that directory listings being left out of the phone books, inserted into the incorrect locations in the phone books or containing incorrect customer information.¹⁰⁰ If CLECs were to lose access to UNE switching and be required to use only UNE-L to serve customers, the volume of directory changes to be processed would rise dramatically above the levels existing at the time of the problems identified in state 271 proceedings.¹⁰¹

We shall adopt MCI's recommendation that "migrate as is" (i.e., no change) functionality for directory listings be made available to CLEC-to-CLEC migrations as well as in ILEC-to-CLEC migrations to limit the number of times that this information must be added and deleted. Otherwise, the Commission cannot ensure that customers will enjoy the seamless, timely and accurate migration process mandated by the TRO.

E. Updating of LIDB and CNAM Databases as Part of Hot Cut Process

UNE-P customers use the Line Information Database (LIDB) and Caller Name (CNAM) databases to obtain information on caller identity and blocking options. These databases are provided by the ILEC, and no changes to these databases are required in a UNE-P to UNE-P migration, unless the customer chooses new blocking options. If no customer change is requested, the losing carrier merely deletes the customer's LIDB/CNAM information from its database and the acquiring carrier loads the telephone number's LIDB/CNAM information internally.¹⁰² However, for UNE-P to UNE-L migrations, both LIDB and CNAM data must be reloaded because the losing ILEC will delete the information from its LIDB and CNAM processes.

It is important for customer satisfaction for the LIDB and CNAM updates to be done properly. If the update is not loaded or incorrect, customer information will not be available for caller name display on caller ID, potentially leading to call blocking by the called party and improper rejection of 3^rd party billed calls.¹⁰³

The LIDB/CNAM data entry step is performed while the order is in order entry. CLECs must either create CNAM data from published sources (which results in a substandard database because not all necessary data is available publicly) or dip the ILEC systems to receive the data at a per dip charge.¹⁰⁴ In most jurisdictions, CLECs are not entitled to take a download of the entire database from the ILECs, though it would enable the CLEC to ensure that there is consistency of information and that callers are provided with the fully functional features that they require.¹⁰⁵

The ILECs have presented no evidence in this proceeding that they could seamlessly handle the volume of LIDB and CNAM databases arising if CLECs lose access to UNE switching. Therefore, we shall adopt the MCI proposal that both third-party vendors and the ILEC be required to demonstrate that their existing processes and systems are capable of handling sufficient volume to process every customer change quickly and flawlessly. As part of this process, we shall require that these processes be evaluated for error checking and reject handling recognizing that such issues have not arisen in the current predominantly UNE-P world.¹⁰⁶ Until all of these steps have been taken, we cannot conclude that the ILEC's proposed batch cut processes will meet the TRO requirements for a seamless transition to UNE-L

⁷⁰ Ex. 143 (Lichtenberg/Starkey 1/15 Reply), at 18.

⁷¹ Ex. 143 (Lichtenberg/Starkey 1/15 Reply), at 19.

⁷² Ex. 143 (Lichtenberg/Starkey 1/15 Reply), at 19.

⁷³ TRO, ¶¶ 561, 564.

⁷⁴ RT 58, 8962: 7-12

⁷⁵ RT 58; 8964:24-28 - 8965:1-8

⁷⁶ Ex.31, Joint Testimony, Cusolito et. al, ; also RT 53, 1/28/03, 8056:12-20

⁷⁷ Ex. 25; Verizon Panel Testimony; 12/15/03; 12:19-22

⁷⁸ "Verizon West" refers to areas served by the former GTE while Verizon East generally refers to areas served by the former Bell Atlantic

⁷⁹ The term "flow through" means that no manual processing is required.

⁸⁰ Ex. 25, Verizon Panel Testimony, 12/15/03; 23

⁸¹ The ILEC in most cases maintains the 911 Selective Router used for routing a 911 call to the appropriate Public Safety Answering Position (PSAP). The PSAP dips into the Automatic Line Identification (ALI) database when a 911 call is received to retrieve the address of the caller. The PSAP is the custodian of the data required to dispatch emergency personnel. The PSAP must have a record for each customer a facilities CLEC owns and must be able to contact that carrier.

⁸² Ex. 141 (Lichtenberg 12/15 Direct), at 45.

⁸³ Ex. 141 (Lichtenberg 12/15 Direct), at 45.

⁸⁴ Ex. 141 (Lichtenberg 12/15 Direct), at 45-46.

⁸⁵ Ex. 141 (Lichtenberg 12/15 Direct), at 45-46.

⁸⁶ Ex. 141 (Lichtenberg 12/15 Direct), at 45-46.

⁸⁷ Ex. 141 (Lichtenberg 12/15 Direct), at 45-46.

⁸⁸ Ex. 141 (Lichtenberg 12/15 Direct), at 45-46.

⁸⁹ Ex. 141 (Lichtenberg 12/15 Direct), at 45-46.

⁹⁰ Ex. 141 (Lichtenberg 12/15 Direct), at 47-49.

⁹¹ Ex. 141 (Lichtenberg 12/15 Direct), at 47-49.

⁹² Ex. 141 (Lichtenberg 12/15 Direct), at 47-49.

⁹³ Ex. 141 (Lichtenberg 12/15 Direct), at 47-49.

⁹⁴ Ex. 141 (Lichtenberg 12/15 Direct), at 47-49.

⁹⁵ Ex. 141 (Lichtenberg 12/15 Direct), at 47-49.

⁹⁶ Recently in New York, Verizon has indicated that it will now retain control over both of the NPAC orders in a UNE-L migration.

⁹⁷ Ex. 141 (Lichtenberg 12/15 Direct), at 49-50.

⁹⁸ Ex. 141 (Lichtenberg 12/15 Direct), at 49-50.

⁹⁹ Ex. 141 (Lichtenberg 12/15 Direct), at 49-50.

¹⁰⁰ Ex. 141 (Lichtenberg 12/15 Direct), at 49-50.

¹⁰¹ Ex. 141 (Lichtenberg 12/15 Direct), at 49-50.

¹⁰² MCI, as the acquiring carrier loads the data internally and at its LIDB/CNAM vendor, VeriSign.

¹⁰³ Ex. 141 (Lichtenberg 12/15 Direct), at 50-51.

¹⁰⁴ Ex. 141 (Lichtenberg 12/15 Direct), at 50-51.

¹⁰⁵ Ex. 141 (Lichtenberg 12/15 Direct), at 50-51.

¹⁰⁶ Ex. 141 (Lichtenberg 12/15 Direct), at 50-51.