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.

In comments on the PD, Verizon claimed that since the submission date for this proceeding, it subsequently completed work necessary to support flowthrough for all types of UNE-P to UNE-L migrations and batch hot cut orders. As a result, Verizon argues that the issue of OSS flowthrough is rendered moot. Yet, because Verizon's flowthrough enhancements were completed after the close of the record, there was no opportunity for opposing parties to review or express a position on Verizon's latest claims. Accordingly, we shall entertain parties' requests to convene a workshop on OSS flowthrough issues if they continue to believe that further issues remain concerning Verizon's OSS flowthrough implementation. Parties shall have 15 business days following the effective date of this order to file a motion requesting that a workshop be scheduled on OSS flowthrough implementation. In any such motion, the specific workshop issues to be addressed must be identified. If no such motions for a workshop are received within this period, Verizon's OSS flowthrough enhancements will be deemed satisfactory, and no workshops on this issue will be scheduled.

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% 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 of 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 will 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 unlock the 911 record at the time the customer's telephone number is ported. In comments on the PD, SBC claims that NENA standards preclude any requirement that ILECs unlock the customer's 911 record at the time the telephone number is ported. In comments on the PD, SBC claims that NENA standards preclude any requirement that ILECs unlock the customer's 911 record at the time the telephone number is ported. In comments on the PD, SBC claims that NENA standards preclude any requirement that ILECs unlock the customer's 911 record at the time the telephone number is ported. SBC claims that NENA Standard 22A.11 indicates that the 911 record should be unlocked when the service order is completed. Opposing parties, however, argue that NENA Standard 22.A.11 only sets forth a recommendation, but not a requirement that the unlock code be sent only upon completion of the order. We agree that the language in the NENA guidelines only serve as a recommendation, not a mandatory restriction. NENA standards do not prohibit the unlocking of the record at the time the customer's number is ported. We therefore require that as part of the hot cut migration process, the customer's 911 record be unlocked at the time that the number is ported. 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. ⁹⁸

In comments on the PD, NeuStar expresses confidence that it can handle the volume of number ports that would occur under any of the parties' estimates of the likely number of hot cuts resulting from withdrawal of UNE-P. Yet, because no record evidence was presented to confirm NeuStar's claims, we cannot rely on NeuStar's representation as a basis to foreclose any further inquiry into this issue. Accordingly, we conclude that further collaborative discussion among the parties is warranted to confirm the capabilities of the NPAC system to handle requisite hot cut volumes. We shall thus 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 consider the need to develop metrics for the completion of number portability tasks.⁹⁹ To the extent that NeuStar is correct in its assessment of NPAC capabilities to handle anticipated volumes of hot cuts, the duration of the workshop should be relatively brief, resulting in consensus and confirmation of NPAC capabilities. 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.

Verizon indicates that it has implemented a solution eliminating the rationale for AT&T's suggestion that CLECs be responsible for handling number porting. Thus, Verizon argues that it should be permitted to perform NPAC notification and that no change to Verizon's porting procedures are necessary. The workshop will provide the opportunity for parties to seek consensus on whether Verizon's claimed solution eliminates the need for CLECs to be responsible for handling number porting.

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.

In comments on the PD, SBC objected to extending the Directory Listing "as-is" functionality to CLEC-to-CLEC migrations. SBC argues that only the CLECs involved in the migration would have the correct and complete information required to properly update the end users' directory listing. Yet, the Joint Parties' reply comments on the PD dispute this claim, arguing that SBC retains directory listing information when a customer is migrated to UNE-L.

SBC claims that imposing the "as-is" requirement for such CLEC-to-CLEC migrations would increase the risk of directory listings errors because SBC would not know whether the current listing information is accurate or complete or whether the migration involved any changes to the telephone number configuration that might impact the listing information. Joint Parties suggest as a remedy to this concern that SBC be required to hold the "delete" order until the new change order is released. To the extent that parties believe that additional implementation issues require resolution in connection with directory listings for customers being migrated from UNE-P to UNE-L, they may raise those issues as part of the workshops being scheduled in the order to this decision.

In comments on the PD, Verizon states that it already provides CLECs the option of retaining and transferring "as is" customer directory listing and directory assistance information. To the extent that Verizon's assertion is correct, Verizon need only document its processes during the workshop, and demonstrate that the information flows through the Verizon systems correctly.

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

UNE-P customers use the Line Information Database (LIDB), including the Caller Name (CNAM) component,¹⁰⁵ to obtain information on caller identity and blocking options. This database is provided by the ILEC, and no changes to the database is 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, LIDB/CNAM data must be reloaded because the losing ILEC will delete the information from its LIDB/CNAM processes.

It is important for customer satisfaction for the LIDB/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 third 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 confirming whether they could seamlessly handle the volume of LIDB/CNAM database transactions 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 LIDB/CNAM processing for 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.

Verizon argues that any issues that may arise relating to LIDB/CNAM processing should be addressed through the OSS Interface Change Management process rather than through this proceeding. We conclude, however, that better coordination can be achieved by keeping the issue in this proceeding, so that batch cut approval can remain linked with confirmation that LIDB/CNAM compliance has been met, thereby assuring that seamless end-to-end batch hot cut processing is achieved.

SBC argues that the capacity of the LIDB is irrelevant to the Batch Cut Processes, and that the batch cut does not entail an update to SBC's LIDB, but that database will not be used once the cut is complete. SBC claims the batch cut only involves the deletion of the appropriate records. We note SBC's objections, but still conclude that LIDB/CNAM issues still need to be resolved in the workshop process ordered in this proceeding in order to assure a seamless end-to-end hot cut process.

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

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

⁷⁵ Id.

⁷⁶ 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.

⁸⁸ Id.

⁸⁹ Id.

⁹⁰ Id.

⁹¹ Id.

⁹² Id.

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

⁹⁴ Id.

⁹⁵ Id.

⁹⁶ Id.

⁹⁷ Id.

⁹⁸ Id.

⁹⁹ 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.

¹⁰¹ Id.

¹⁰² Id.

¹⁰³ Id.

¹⁰⁴ Id.

¹⁰⁵ The CNAM is an informational component of the LIDB.

¹⁰⁶ 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.

¹⁰⁸ Id.

¹⁰⁹ Id.

¹¹⁰ Id.