Interconnect Gateways: Competitive Enabler or Barrier?

By Lisa Phifer
Core Competence, Inc.

The Telecommunications Act of 1996 requires competitive access to previously closed operations support systems (OSSs) used by incumbent local exchange carriers (ILECs)for pre-order inquiry, service ordering, provisioning, trouble administration, and billing transactions. For competitive local exchange carriers (CLECs) to conduct business, access to customer service records (CSRs) in ILEC databases and flow-through of local, access, and directory service requests (LSRs, ASRs, and DSRs) is essential.

In this business where responsiveness is a deal-maker or breaker, automated bridges between ILEC and CLEC operations systems -- Interconnect Gateways -- were required. But how could the FCC motivate incumbents to interconnect gracefully with the emerging competition?  By using the lure of new markets. 

Before ILECs can become inter-exchange carriers (IXCs), they not only must provide access to required OSS functions, but they must do so in an automated fashion, with a demonstrated level of performance that proves parity. That is, CLEC requests must be satisfied as quickly and reliably as in-house ILEC requests made of the same OSS.

In The Beginning
The interconnect challenge facing a regional CLEC is significant, but not insurmountable. To turn-up service on a new account, dozens of ILEC systems and databases must be accessed for Customer Account Record Exchange (CARE), Primary Interexchange Carrier (PIC) connection , Local Number Portability (LNP), emergency 911 support, line information data, and address validation for unbundled local loop length.

Many CLECs, particularly smaller ones, start with manual, paper-based interconnect: submitting inquiries and orders to the ILEC by fax and phone.  But manual transactions are relatively slow, labor-intensive, and lack a reliable, non-repudiable audit trail. Who hasn't had a fax get lost, an order form get stuck on someone's desk? Nonetheless, if the ILEC doesn't yet provide reliable automated interfaces, or the CLEC cannot afford to build its end of the interconnect gateway, both carriers may be stuck with manual processing -- at least initially.

While a regional CLEC may "only" have to deal with connecting to a single ILEC, a CLEC planning national deployment has a much broader challenge.

One Potato, Two Potato, Three Potato, Four…
Although the FCC placed a stake in the ground by enumerating required OSS functions -- pre-order, order, provisioning, maintenance, and billing -- there is no universal agreement on precisely how these functions are provided, or even on the data elements they require. As interconnect gateways mature, industry guidelines such as those defined by the Telecommunications Industry Forum (TCIF) and Order and Billing Forum (OBF) help.

But today, each ILEC employs a unique set of operations systems and databases.  And each ILEC, scrambling to enter the same new markets coveted by other ILECs, has taken its own approach to enabling OSS interconnect. 

If this is a problem when dealing with a single incumbent, national CLECs face a much bigger problem. CLECs therefore face a much bigger problem: They must accommodate unique interfaces for each ILEC in their serving area.  And in doing so, CLECs must deal with complex differences, ranging from protocols and data formats to product codes and business rules. One ILEC may use Electronic Data Interchange (EDI)  for service order entry, but a legacy file transfer interface for billing, while another ILEC may support only web-based queries, and yet another offers no automation at all.

How can a CLEC overcome these interconnect challenges efficiently and cost-effectively?

Interconnect Gateway Platforms Can Help
Just as equipment suppliers replaced device-specific supervisory systems with generic element managers, built upon network management development platforms, so too can CLECs leverage the emerging crop of interconnect development platforms.

Development platforms provide the "glue" needed to connect CLEC and ILEC operations systems. Like multilingual interpreters, interconnect gateway platforms accept many messaging protocols: EDI, FTP, HTML, S/MIME and SMTP (secure email), CORBA, even legacy ASCII messages. They can extract the content conveyed by each transport and map between data formats, and perhaps already know the formats employed by common ILEC systems and databases. 

These platforms are "programmed" with workflows and business rules, enabling semantic and syntactic request validation and contextually-appropriate transaction routing.  And these platforms provide the infrastructure required to support any mission-critical trading interface: transaction time-stamping, confirmation, and storage.  Transaction logs, audit trails, and appropriate security measures for authentication, message integrity, data privacy, and non-repudiation of transactions. The ability to run on reliable, scalable computing platforms.

Or at least that's the objective. Interconnect gateway platforms, like any other kind of product, differ from one vendor to the next. Some are tailored for use by the telecommunications industry, while others are designed for business-to-business trading in general.  Commercially available platforms include those in the attached chart.

Among the products included on the chart, for example, Northpoint Communications and HarvardNet both chose NightFire's SupplierExpress to automate flow-through service order processing with Bell Atlantic North.  Focal Communications uses Mantiss CLECWare to automate unbundled loop order processing with Ameritech. Sprint uses GEIS / Telcordia ExchangeLink to support local service request transactions with BellSouth and three other trading partners. 

But Interconnection Still Isn't Easy
Bell Atlantic developed its CLEC service order processing interface using Netscape's ECXpert platform. The demonstrated ability of this system to function properly at least 93% of the time was a lynchpin behind the FCC's December ruling which granted Bell Atlantic permission to enter the IXC market in New York. Unfortunately for the CLECs who must rely on Bell Atlantic's ECXpert system to coordinate cut-over on local exchange service orders, operability and performance have degraded since the FCC ruling.

Simply put, this ECXpert-based system has not operated reliably under heavy load, with problems ranging from slow response time to dropped service order acknowledgements. A trouble ticket posted on Bell's Atlantic's wholesaler site February 10 declared "Multiple CLECs reporting no access to the Bell Atlantic network via the Internet." 

Responding to allegations that the ILEC had failed to provide timely delivery on "tens of thousands of CLEC orders," the New York Public Service Commission gave Bell Atlantic one week to rectify the problem. Bell Atlantic immediately installed larger, faster Sun servers and temporarily relocated engineers from adjacent states to rework the system. But affected CLECs are understandably impatient, and argue that the FCC should establish service level agreements and impose penalties when performance falls below required levels.

Parting Thoughts
CLEC and ILEC operations support systems are inextricably bound together, whether by paper handoff or EDI "electronic bonding". Interconnect gateway automation is growing as early adopters seek to improve operational efficiency, and thus competitiveness and profitability. Technological advancements in both interconnect platform and approach offer near-term challenges and long-term promise. In a future column, we'll take a closer look at what successful interconnection requires and one recent innovation: the clearinghouse approach.

Lisa Phifer is vice president of Core Competence, a network consulting firm located in Chester Springs, PA.  She has been involved in OSS development for nearly a decade.