New competition in the local exchange market presents opportunities and challenges for incumbent local exchange companies (ILECs) and competitive local exchange companies (CLECs) who wish to enter the market. To meet regulatory requirements and maximize early market entry, methods for communication with multiple trading partners are an immediate priority. Difficulties have arisen because, with industry standards arriving so late in the day, most ILECs have developed their own proprietary interface.
While there is no golden gateway that can provide an instant cure, tools and techniques exist that make it possible to manage the ILEC-CLEC gateway with minimal expense and headaches.
A New Era
The Telecommunications Reform Act of 1996 will go down in history as the beginning of a dynamic and highly competitive local telephone market. Today, the entire nation is open to local exchange competition, and serious battles are heating up in most major markets. Yet, the fact remains that ILECs still serve some 99 percent of the residential local exchange market and much of the business market.
Entry into the local market is not a simple task. The Telecom Act specifies that ILECs have to provide an electronic interface to their operations support systems (OSS). The FCC mandates ILECs provide CLECs with equivalent electronic access to their OSS functions as they provide their internal users. In particular, CLECs must be able to obtain preordering information on potential customers, order local service for resale or as unbundled network elements, order directory listings, specify features and more. The ILECs have been hard-pressed to build the systems necessary to allow CLECs to gain secure, efficient access to their systems to complete these transactions.
While the ILECs were developing their own interface specifications, the Ordering and Billing Forum (OBF) took on the task of developing an industry standard. However, because these efforts were done in parallel, significant differences exist. Now, and for the foreseeable future, CLECs have to deal with a unique and evolving interface for each of their trading partners.
Multiple Regulatory Bodies
Further complications exist because each major ILEC deals with multiple regulatory bodies that impose their own unique requirements. For example, the public utilities commission (PUC) for one state may mandate that touchtone service be offered without charge, while another state may permit a charge for this service. To further muddy the water, regulations may be different for consumer and business users, and some states make even more complex distinctions among different classes of customers.
Historically, many ILECs have dealt with these issues by developing separate mainframe systems to handle different geographic areas or classes of customers. In many cases, these systems were created separately by what were then independent operating arms of the Bell network prior to its breakup in 1984. In the closed local service environment that has existed up to now, the operation of such parallel systems was not a major problem. In these systems, security often was limited to two types of internal users: those who had clearance to view all records and those who had no clearance. These users were highly trained and had years of experience in dealing with their systems' idiosyncrasies.
Now that OSS functions are being accessed by external users unfamiliar with their operation, the different requirements have become the responsibility of the gateway. This means that, in addition to being able to communicate with the many proprietary systems of each of its trading partners, the gateway also must be able to distinguish between--and communicate in a different dialect to--each of the multiple systems maintained by the ILECs. These differences, along with the normal maturing of the business, usually generate ripple effects on connected systems. The ripples often increase the gateway's complexity. For example, one ILEC's original interface specifications for placing a new order required the service address. In later revisions of that interface, the ILEC required both the service address and an exchange code of that telephone number. Rather than simplifying the interface, the rules became more complex, requiring the CLEC to maintain parallel copies of data.
Consider the complexities of a small business customer that wants to switch its local service to a CLEC and at the same time modify its business's hunting arrangement. The CLEC not only has to specify the details of the new hunting configuration, but it needs to list the specifications of the old (or current) hunting arrangement when it communicates to the ILEC. Many of the older customer information legacy systems used by the ILEC are mainframe-based and often were built with normalized data stores. The new information must be applied to the network switches, whose primary job is call routing, not customer database information management. The ILEC must locate those database fields and delete or update them before the new information can be applied. Modifying a customer's account and network configuration is akin more to replacing an engine in a car than to taping a new song on a cassette. The car's old engine must first be removed before the new engine can be installed.
A New Breed Arises
In response to heavy interface and security demands, a new breed of OSS has arisen in the last few years. Rather than a single, normally UNIX-based server, these systems consist of a network of computers, each providing specialized functionality. These computers can run UNIX, OS/2 or Windows NT operating systems, and each provides specialized capabilities at a far lower price-to-performance ratio than legacy systems while offering a higher level of redundancy to support mission-critical tasks. Yet, in nearly every case, the basic data processing tasks are still performed by the legacy systems, and their special requirements frequently bubble up to the gateway.
Dealing with a variety of local regulations and systems also provides other data processing-related challenges. For example, each state has different regulations concerning discontinuing a customer's service for nonpayment. Some states, for example, won't allow companies to remove a customer's service on a Friday. Not only does this affect the gateway, it also affects any systems built by the CLEC to manage its own customer databases. Gateways capable of communicating with multiple ILECs face even greater challenges. Consider the situation in which one ILEC calls a feature touchtone while another calls it touch service. A third has that service as part of a package. To place the order correctly, a CLEC's gateway must be capable of translating from the internal system's terminology to the dialect used by the appropriate ILEC.
Adding to the complexity is the range of communications approaches that are being used for ILEC-CLEC communications such as open systems interconnection (OSI), electronic data interchange (EDI) and network data mover (NDM). The OSI stack offers the ideal theoretical approach but can be very expensive: In some cases, the stack required for a CLEC to report trouble to an ILEC costs more than $1 million. For this reason, a majority of companies have embraced EDI, and one CLEC has adopted a stripped-down, less expensive version of OSI.
Because interfaces are different for different ILECs, CLECs planning to enter local service markets virtually are shooting at moving targets. In the past eight months, at least one ILEC has gone through four versions of its interface. Often, interface changes are implemented long before the new documentation is issued, and changes sometimes are discussed, agreed on and tested before implemented.
Fortunately, help is on the way. The OBF is trying to merge the best of the proprietary systems developed by each of the ILECs into a coherent standard. Meanwhile, interim solutions are being developed based on trading partner-specific interfaces. Competitors must anticipate which formats and transmission technologies they should support to minimize internal development and modification costs, achieve time-to-market goals and ensure flexibility in a very dynamic market.
Components of an Interconnection Solution
Preorder verification is an essential component of a successful reselling operation. In addition to gathering existing customer service record information, the system must be able to get real-time information from the ILEC concerning available services for resale in the customer's territory. The customer cannot wait 24 hours to find out if call waiting is offered. Validating a customer address, reserving a telephone number and negotiating a date of service also are critical CLEC functions that must occur prior to placing an order.
Often, ordering will not involve total service resale (TSR), in which the CLEC is buying the total solution (the loop, telephone number, switch, etc.) from the provider. Sometimes orders are for specific parts only. These unbundled network elements (UNE) orders allow the CLEC to purchase the parts of the network it needs, such as the loop, the port or the network element.
Testing also is very important in implementing an ILEC's interface. One system will funnel all orders into a directory, where they are manually examined. Another sends orders into a test system. The difference is important because a manual system takes longer and is dependent upon the level of experience of the person who examines the orders. It's also important that the test system has been updated to reflect the latest changes to the ILEC's interface.
CLECs also should find out the status of orders that are being processed when new versions of the interface are implemented. The CLEC should ask the ILEC if it will agree to support orders written in the old format that are in the pipeline when the changeover occurs. Ideally, the ILEC will support those old orders for a given period of time--commonly called a sunset period --after the new system goes live.
Clearly, it's essential that a CLEC developing an interface to enter a particular market maintain extremely close communication with the ILEC to make sure the interface it has just developed, at much time and expense, continues to work over time. It's also wise to enter into an implementation agreement that specifies the notification procedures required before an interface change can be made.
Right now, the perfect solution to these problems does not exist. While it theoretically would be possible to develop a system that would interface with all of the different systems run by the ILECs, the environment is changing so fast that such a system would be obsolete by the time it could be developed. But the market is evolving. ILECs are not about to abandon the proprietary systems they have developed at such a high cost, but they can be expected to move slowly toward emerging standards as their systems are upgraded. The emphasis right now is on finding a practical solution that can be cost effective and put to work immediately.
Value-Added Vendors
To find a practical solution, many companies are employing value-added vendors with experience in the development of client/server front-ends to systems and on CLEC gateways and user interfaces. The vendor already may have helped other ILECs connect to a CLEC, and this experience can save time and money. This experience may include not only a technical understanding of the ILECs system, but also knowledge of its unique and equally important business processes. A vendor with experience on both sides of the fence can provide a valuable influence on interface discussions between the ILEC and CLEC.
Knowledge about industry standards, business processes necessary to offer local service and ILEC methods and procedures are critical when interfaces are in a dynamic state of evolution. Finding a partner that can help establish joint implementation agreements and business rules, as well as develop the technical specifications, can ensure successful implementation of a mechanized gateway between CLEC and ILEC.
Conclusion
The Telecom Act has created substantial opportunities for competition and growth in local access markets. New alignments are being created among CLECs, ILECs, competitive access providers (CAPs), resellers and long distance carriers that never were imaginable in the past. To compete, a CLEC needs a reliable method of establishing intercompany data communication with its trading partners. Understanding the major issues involved and partnering with a technology firm that understands local market systems can get CLECs into operation in a minimum of time, at a relatively low cost and with minimal risk.
Tom Whymark is architecture director for Beechwood Data Systems Inc. Clark, N.J. For more information, call (732) 382-5400.
