-
OSS Interconnection
OSS Interconnection
Regulations
A critical portion of the Telecommunications Act of 1996 and its associated orders deals with OSS interconnection. In this context, interconnection refers to regulations requiring the regional Bell operating companies (RBOCs) to allow competitors limited access to their customer databases and various OSS functions, such as preordering, ordering, and provisioning. (Preordering is the process by which a competitive local exchange carrier [CLEC], with permission from the customer, requests data regarding that customer from an RBOC.) The Federal Communications Commission (FCC) will not permit RBOCs to enter the long-distance market until, among other things, they provide interconnection that state regulatory commissions and the FCC have deemed sufficient to enable competition. RBOCs and incumbent local-exchange carriers (ILECs) have built, or are in the process of building, interfaces that provide interconnection to CLECs. Interconnection is an extremely complex and time-intensive issue that the communications industry has been working several years to resolve. In the meantime, carriers often rely on manual means, such as phone calls and faxes, to exchange customer data and service orders. Manual processes are highly error-prone and slow-insufficient in a highly competitive environment.
Interconnection Challenges
The largest problem RBOCs face is facilitating access to information residing within their OSSs. Typically, the RBOC OSSs are standalone, proprietary mainframe systems that were never designed to share information with external systems or trading partners. The RBOCs have invested large sums of money in these systems and the data contained within them. As a result, it is necessary to develop applications designed to extract information from RBOC OSSs. RBOCs continue to work toward a solution that facilitates information sharing that meets government requirements for fair competition while retaining the integrity and proprietary design of RBOCs.
OSSs
RBOC legacy systems are not designed to partition customer data in other words, to store data for RBOC customers that have sought service with a CLEC, such as in a reseller arrangement. Additionally, external interfaces must be added to facilitate integration with external systems. Without such integration, next-generation functionality such as flow-through ordering and provisioning cannot be achieved. To accommodate next-generation interconnection, RBOC systems must also be able to respond to commands coming from an interconnection gateway in order to fulfil CLEC requests for customer data.
There are many conceptual and technological approaches to systems integration between RBOCs and CLECs. These approaches involve technologies such as middleware, transaction processors (TPs), workflow systems, and object engines. Middleware is a term commonly applied to integration technology, and it is often used interchangeably with TP. These technologies present common application programming interface (API) into which a system can be integrated to manage data translation and exchange among disparate systems. Workflow systems often work in conjunction with TPs, providing multiple, dynamic APIs and managing data flow and task sequencing, while the TP handles data conversion. Object engines use technologies such as the Object Management Groups (OMG's) common object request broker architecture (CORBA) or Microsoft’s distributed component object model (D’COM). Object engines abstract application interfaces into definable, flexible software objects that allow applications to communicate in a uniform manner.
While RBOCs work to make their systems accessible to CLECs, they must also develop interconnection interfaces and integrate them with their systems and business processes. Because there is no industry standard or consensus about how this should be accomplished, RBOCs often rely on technologies they already use for information exchange with large customers and interexchange carriers (IXCs). These technologies are not necessarily intended for interconnection but provide the most economical alternative for RBOCs because a large amount of the required application code is already in place. The most common protocol being used for interconnection includes various versions of electronic data interchange (EDI). EDI was originally designed to enable the exchange of business documents, but is now being used for ordering and pre-ordering.
Gateway/API FunctionsMany vendors have brought flexible gateway and/or API products to market, intended to help CLECs develop the interfaces necessary for interconnection with RBOC OSSs. The TeleManagement Forum, an industry organization devoted to the implementation of telecom standards such as the TMN, has led an initiative to develop guidelines for a common interconnection gateway platform (CIGP). The goal of the CIGP is to apply vendor-neutral, industry-common technologies to OSS interconnection in order to assist CLECs in developing interconnection interfaces. Most of the vendors that have developed gateway products have been involved in the CIGP initiative.
The primary function of gateways and APIs is to manage the interfaces between CLEC and RBOC OSSs. These interfaces handle data integrity and security between carriers as critical customer and service data is exchanged. One of the most important aspects of gateways and APIs is to perform error checking on service orders as they are passed between carriers. With manual processes, a CLEC often sends service orders to an ILEC or RBOC that end up lost in a pile of faxes for several days. When orders are reviewed, they are rejected if they are incomplete or inaccurate, and this can happen frequently. Incomplete and inaccurate orders are returned to the CLEC for reprocessing. This can add days and even weeks to the ordering process. Gateways and APIs can reduce these errors by reviewing all orders before submission to the ILEC and returning any incomplete or inaccurate orders for instant review.
Another critical function of gateways and APIs is to facilitate the preordering process. In this process, the CLEC secures permission from a potential customer to obtain customer data from the ILEC. This data consists of a customer profile, outlining all the service provided to the customer by the ILEC. This data is often transferred in the form of universal service order codes (USOC). There are thousands of codes, each of which is typically very cryptic. Manual processing is extremely time-intensive, requiring a CLEC customer representative to research a large catalogue to determine the services provided and to build sales quotes for similar offerings. Next-generation gateways can read USOC codes and match them to a CLECs product catalogue database to automatically generate product offerings and sales quotes, making the CLEC customer acquisition process far more efficient. Once this information is obtained, next-generation OSS solutions also provide product catalogue capabilities that enable customer service representatives to up sell additional related products and services to customers, often in the form of cost-effective service bundles, such as caller I.D., call waiting, and conference calling.
0 comment(s):